2.5.1-RC port-forwarding not working on WAN2
-
On what build?
What rule is passing the traffic in?
2 port forwarding rules. It was working just fine on 2.4.5.
If you follow the packet flow with tcpdump/packet captures, where does it go?
WAN1: (Working)
WAN2: (Not Working)
-
Are those captures on the LAN? If so, what shows up in a capture on WAN2?
The only known issue with port forwarding on multiple WANs was fixed in the build you are running. It works here on everything I have now.
It's possible there is another edge cases with multiple PPPoE WANs but my second WAN here is PPPoE and it works fine on the latest snapshot, but didn't work on earlier builds.
-
@jimp
Yah on LAN, the 2nd screenshot is WAN2 and the 1st screenshot is WAN1. -
Just upgraded pfSense from 2.5 to 2.5.1 and I have the same problem.
Two WANs, one LAN, port forwards works just fine on default WAN1, but stop working on secondary WAN2. If I change the default gateway to WAN2 port forwards on WAN2 start to work. If I change back to WAN1, port forwards on WAN2 stoped working.
On 2.5 port forwards worked just fine on WAN1 and on WAN2pfSense
2.5.1-RELEASE (amd64)
built on Mon Apr 12 07:50:14 EDT 2021 -
Same here!
Port Forwards was working at 2.4.5 and 2.5.0 but after upgrade to 2.5.1 stopped working.2.5.1-RELEASE (amd64)
built on Mon Apr 12 07:50:14 EDT 2021
FreeBSD 12.2-STABLE -
Same for me on two pfSense one cloud based and second on physical, just after the update to 2.5.1 the port forwarding suddenly stops and nothing changed in the settings, just update.
-
@gkovachev same resolution here, for now I adjust my gateway to WAN2 as default, but it is not an ideal case. WAN1 is shared internet and WAN2 dedicated internet for server now all my company use the WAN2 internet.
Waiting for solution for this issue.
-
-
Same Issue since upgrading to 2.5.1 Release.
Port Forwarding only works for interface if it's the current default gateway.
Problem only with incoming traffic. Possible that traffic is try to return via the default gateway, instead of the interface it came in on.Outgoing traffic on that interface, per rules, works regardless of current default gateway.
-
@lasocean
I was wrong.
I have some rules that route certain devices via WAN2 primarily.
Those devices are NOT getting connected to internet destinations when WAN is the default gateway.I had to Disable WAN2 to get them connecting via WAN.
Marking WAN2 Gateway as DOWN also helped, but there were still some issues.All this worked fine with 2.5.0
-
The question is now, downgrade to 2.5.0 or is there a patch/hotfix possible.
As far I understand this thread there is no workaround possible -at the moment-. -
i have same issue with 2.5.1
-
@edmond https://redmine.pfsense.org/issues/11805
-
Glad I found this discussion after some digging.
Same issue here. Why is this not listed in "known issues" yet!?
Seems discovered more than a week ago already. How long is suggested we wait before updating then?This is very crucial to fix because we need NAT on all our WANS (7!). This is the real nightmare situation I always wanted to avoid again by moving to pfsense. At least this does not affect the built-in OpenVPNs.
Rollback is currently impossible since nobody can access the device for the next weeks. I hope "urgent" means top priority here.
-
@lennok said in 2.5.1-RC port-forwarding not working on WAN2:
Glad I found this discussion after some digging.
Same issue here. Why is this not listed in "known issues" yet!?
Seems discovered more than a week ago already. How long is suggested we wait before updating then?
This is very crucial to fix because we need NAT on all our WANS (7!). This is the real nightmare situation I always wanted to avoid again by moving to pfsense. At least this does not affect the built-in OpenVPNs.
Rollback is currently impossible since nobody can access the device for the next weeks. I hope "urgent" means top priority here.Hopefully the answer is not: you have to pay for pfsense Plus +
It is not being critical or pointing. But it is delicate because it is something of the essence of the FIRWEWALL.
It's like an update fails the blocking rules and everything is ANY .... = (
-
This post is deleted! -
@jimp does this bug currently exist on the upstream kernel?
-
There is also another issue in 2.5.1.
If a rule is created with a specified gateway (not a failover or load-balanced gw) and that gateway goes down, data starts flowing through the default gateway. In 2.4.5 this wasn't the case.
If anyone is wondering Skip rules when gateway is down is unchecked. -
@coldfire7 No, that is and was the default behavior before.
-
@bob-dig but when I was using 2.4.5 if a GW went down I was getting timed out instead. :S