Bug #8247


When in bridge / transparent mode, pfSense blocks UDP/4500 & ESP traffic regardless of origin

Added by Travis McMurry over 3 years ago. Updated almost 2 years ago.

Not a Bug
Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


I'm not sure what mechanism is in play, but this is a VPN-specific issue. Forum Post:

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

Actions #1

Updated by Travis McMurry over 3 years ago

sorry about the trailing open-ended sentence. should have edited it out. :)

Actions #2

Updated by Travis McMurry over 3 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.

Actions #3

Updated by Travis McMurry over 3 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, destination any
  • Only one NAT rule: Translate across WAN interface (static port is checked, also tried unchecked; tried "Keep" & "Sloppy" States)
  • Initiate Cisco AnyConnect VPN session from to (Xlate IP:
  • Outbound Traffic flow is permitted
  • Inbound Traffic flow is denied: Interface: WAN Rule: Default deny rule IPv4 (1000000103) SRC: Dst: UDP
  • Inbound Traffic flow is denied: Interface: WAN Rule: Default deny rule IPv4 (1000000103) SRC: Dst: 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.

Actions #4

Updated by Jim Pingle almost 2 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.


Also available in: Atom PDF