Upgrade 2.2.2 -> 2.2.3 Local IPSEC traffic blocked as well

nodau

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.

rerouted

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

jdp0418

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?

nodau

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.

cmb

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

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

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.

nodau

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.

cmb

@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).

cmb

@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.

nodau

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.

rtv

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…

rtv

Did anyone try if pfSense 2.2.4 is working again?

cmb

@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.

rtv

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