Bug #8247
closed
When in bridge / transparent mode, pfSense blocks UDP/4500 & ESP traffic regardless of origin
0%
Description
I'm not sure what mechanism is in play, but this is a VPN-specific issue. Forum Post:
https://forum.pfsense.org/index.php?topic=142020.msg774573#msg774573
In short, if I initiate a VPN connection from within my inside network, behind pfSense in bridge mode, return traffic is actively denied by the IPv4 default deny rule. When I do a wireshark on each side of pfSense, the router side shows the traffic (UDP/4500 & UDP/ESP) being sent to pfSense, but on the inside, the traffic never makes it. pfSense indeed logs the blocked UDP traffic.
The assumption I'd make is if the traffic was generated from the inside network, that it would be tracked in the state table. For example in pfSense's state table, I can see UDP/53 open between my internal DNS server and OpenDNS on the internet. My DNS server gets replies, works fine. So, upon return traffic coming back from the original destination IP, same port, should be allowed back in by default.
As a workaround, I can add the VPN endpoint IP as a singular inside permit. It's easy to discover the endpoint IP (even if I have no access to the device creating a VPN tunnel, for example a Femtocell) by looking at blocked UDP/4500 in pfSense logs. I can add that IP or an alias to a standalone rule bound for the subnet in the inside network, and all works fine.
Given the nature of the origination of the traffic, I'm not sure why a rule like this would be needed in bridge mode.
The only way to "fix" this
Updated by Travis McMurry over 6 years ago
sorry about the trailing open-ended sentence. should have edited it out. :)
Updated by Travis McMurry over 6 years ago
In the days since I created this bug, I continue to observe pfSense filtering out inbound return UDP traffic unless explicitly permitted with source IPs and ports. It's more than just my original claim with VPN, that was just the first source. I see it blocking WS-Discovery, DHCPv6, IPv6 multicast broadcasts, and more.
My default outbound permit on the subnet is IPv4/IPv6, protocols (all), source (inside), destination (any). TCP traffic is fine, but return UDP traffic isn't - despite the state table reflecting the UDP session is open.
Updated by Travis McMurry about 6 years ago
Fast Forward to a new pfSense 2.4.3 installation in routed mode and the same behavior occurs:
- Only one rule in network: Permit IPv4/IPv6, Protocol All, source 10.10.40.0, destination any
- Only one NAT rule: Translate 10.10.40.0/24 across WAN interface (static port is checked, also tried unchecked; tried "Keep" & "Sloppy" States)
- Initiate Cisco AnyConnect VPN session from 10.10.40.15 to 208.231.72.44 (Xlate IP: 73.0.255.142)
- Outbound Traffic flow is permitted
- Inbound Traffic flow is denied: Interface: WAN Rule: Default deny rule IPv4 (1000000103) SRC: 208.231.72.44 Dst: 73.0.255.142 UDP
- Inbound Traffic flow is denied: Interface: WAN Rule: Default deny rule IPv4 (1000000103) SRC: 208.231.72.44:4500 Dst: 73.0.255.142:4500 UDP
It looks like what is happening is the initial request outbound is from my IP (random port) to destination IP, port 443 TCP. The AnyConnect endpoint responds with two UDP sessions as shown above. I believe pfSense is not expecting the far end to return with UDP instead of TCP, therefore is terminating the connection via default rule.
The workaround seems to be:
In System -> Advanced -> Firewall/NAT -> UNCHECK "Disable Firewall Scrub"
Once that is in place, AnyConnect was able to work without any changes to the AnyConnect Client with only one rule on the Work interface - any protocol any source/dest; with "keep" state & dynamic port.
Updated by Jim Pingle over 4 years ago
- Status changed from New to Not a Bug
I don't see a bug here, but quirky remote equipment that needs special rules to handle those quirks. Of course a firewall doesn't expect to see UDP in response to a TCP connection. That's not the firewall's fault.