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 
Updated by