Upgrade 2.2.2 -> 2.2.3 Local IPSEC traffic blocked as well



  • Hi folks,

    since upgrade local IPSEC traffic on ports UDP 500/4500 is being blocked although ports are open. DMZ to LAN and LAN to DMZ.

    Need to go with 2.2.2 until problem is solved.



  • I am having a similar issue where I have a device behind the pfSense box for L2TP VPN.  It was working on 2.2.2 but after the upgrade to 2.2.3 is has stopped.  My L2TP is using UDP ports 500, 4500 & 1701.  The VPN appliance has a 1:1 NAT with a public virtual IP on the pfSense box.  I am scratching my head because I don't see any logs messages on the VPN appliance of connection attempts.



  • There seems to be a severe issue with IPSEC in 2.2.3, since it is not even working from inside the network. If you cannot find any logentries it is hard to determin where the problem comes from. My recommendation stay with 2.2.2.


  • Galactic Empire Netgate

    Do you have AES-NI enabled? What IPsec encryption do you use in phase 2 ?



  • I am not even using any IP functionality on the pfSense box, just have IPSec ports open and passing from outside WAN and it does not work…..



  • Do you see actual blocks in the PFSense for this traffic?  Did you try enabling logging on the rules allowing the port traffic in to prove it is getting in?

    Did anything change with the 1:1 NAT or virtual IP?  I've seen a few posts here with some folks saying that their VIP's didn't come up in the config after the 2.2.3 upgrade/reboot and they had to rebuild them.  Maybe this happened in your config?



  • This is a Port related issue. Open Ports in Nat but no Traffic passed. So no phase 1 or 2. Just the ports. Port logging is enabled. No entries. It is just blocking each packet on the IPSec Port.

    i dont use virtual ips. just carp. the carp table looks correct. oubound nat is set to manual with carp interfaces being used as gateways.



  • Same here I enabled logging on my IPSec rules and I see no entries in the logs with source or dest IP's.



  • Man, that's really a strange issue because it is still just a NAT translation/port forward.

    Do other NAT trans/port forwards work? Does a port scan of your firewall WAN show those ports open and listening?



  • im not even routing from or to wan. its from dmz to lan and lan to dmz. all other ports work on the interface. its only for udp 500 and 4500 that dont work. when i try to send packets from dmz to lan, i get a timeout. the same test with 2.2.2 is working just fine.



  • if you filter in Diag>States for :500 do you see the traffic? If so, what does the state look like?



  • This is how my state table looks for port 500 so it is seeing the traffic but then is in a "no traffic" state?

    WAN udp 10.0.1.3:500 (24.x.x.x:500) <- 70.x.x.x:9477 NO_TRAFFIC:SINGLE
    LAN udp 70.x.x.x:9477 -> 10.0.1.3:500 SINGLE:NO_TRAFFIC

    This is the my correct mapping as the 24.x IP is an IP Alias and it is 1:1 to 10.0.1.3 inside.



  • on the master mine looks like:

    DMZ udp 172.31.1.209:500 <- 10.0.0.8:500 MULTIPLE:MULTIPLE
    LAN udp 10.0.0.8:500 -> 172.31.1.209:500 MULTIPLE:MULTIPLE
    DMZ udp 172.31.1.209:500 <- 10.0.0.7:500 MULTIPLE:MULTIPLE
    LAN udp 10.0.0.7:500 -> 172.31.1.209:500 MULTIPLE:MULTIPLE

    but no traffic. when i shut down the master the slave comes up and everything is working.



  • @rerouted:

    This is how my state table looks for port 500 so it is seeing the traffic but then is in a "no traffic" state?

    WAN udp 10.0.1.3:500 (24.x.x.x:500) <- 70.x.x.x:9477 NO_TRAFFIC:SINGLE
    LAN udp 70.x.x.x:9477 -> 10.0.1.3:500 SINGLE:NO_TRAFFIC

    That's correct. The NO_TRAFFIC means 10.0.1.3 isn't replying, or if it is replying, it's not being routed back to that system (like if its default gateway is something different).



  • @bahsig:

    on the master mine looks like:

    DMZ udp 172.31.1.209:500 <- 10.0.0.8:500 MULTIPLE:MULTIPLE
    LAN udp 10.0.0.8:500 -> 172.31.1.209:500 MULTIPLE:MULTIPLE
    DMZ udp 172.31.1.209:500 <- 10.0.0.7:500 MULTIPLE:MULTIPLE
    LAN udp 10.0.0.7:500 -> 172.31.1.209:500 MULTIPLE:MULTIPLE

    but no traffic. when i shut down the master the slave comes up and everything is working.

    You have bidirectional traffic in that case, the ISAKMP is fine from a network and firewall perspective. Filter on ESP and see if that's there.



  • ESP looks the same.

    DMZ esp 172.31.1.209 <- 10.0.0.7 MULTIPLE:MULTIPLE
    LAN esp 10.0.0.7 -> 172.31.1.209 MULTIPLE:MULTIPLE
    DMZ esp 172.31.1.209 <- 10.0.0.8 MULTIPLE:MULTIPLE
    LAN esp 10.0.0.8 -> 172.31.1.209 MULTIPLE:MULTIPLE

    I tried Upgrade and even fresh install with settings restore. No luck so far. When the master stays at 2.2.2 and the slave at 2.2.3 it is working even when i shutdown the master. As soon as I upgrade the master to 2.2.3 the traffic is blocked on both machines. :-\ Weird is that it somehow works for a short period of time (5 mins) after restart and then it stops all of a sudden.



  • Same here: an Alcatel OmniAccess Wireless LAN Switch (which provides VPN Tunnels for external VoIP desk phones) is configured for 1:1 NAT on my WAN interface and cannot be reached by external "Raptor" Clients after 2.2.3 Update.
    The build in IP sec is being used for a site to site connection to my home router and still working.

    Went back to 2.2.2 via slice change but would appreciate a workaround for future upgrades…



  • Did anyone try if pfSense 2.2.4 is working again?



  • @rtv:

    Did anyone try if pfSense 2.2.4 is working again?

    For circumstances where something broke between 2.2.2 and 2.2.3, the root cause here would have either been the AES-NI non-GCM mode issues, or maybe a less common ID type regression. All that's fixed in 2.2.4.

    Outside of that, it's probably one of the "I upgraded and it broke" that wasn't actually because of the upgrade at all, a few diff threads here along those lines where the root cause ended up being a misconfigured NAS, other LAN hosts with broken network configs, among other issues that didn't actually change from the upgrade.



  • Ok, I bit the bullet and tried to upgrade from 2.2.2 to 2.2.4: same result  :-\