Upgrade 2.2.2 -> 2.2.3 Local IPSEC traffic blocked as well
-
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_TRAFFICThis 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:MULTIPLEbut no traffic. when i shut down the master the slave comes up and everything is working.
-
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_TRAFFICThat'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:MULTIPLEbut 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:MULTIPLEI 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 :-\