2.5.1-RC port-forwarding not working on WAN2
-
@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.
-
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
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
-
@coldfire7 I am sure about it, because I had to create a vpn killswitch for that, so...
