Limiter source mask now after NAT when using gateway groups - 2.8 change?
-
On the bug report the reporter claims it works correctly in 2.7.1 but doesn't show which version they thought was affected.
However the 2.7.2 release was specifically to address a regression in the route-to behaviour that would be used by this. So I could believe it was that.
But you are now also seeing the issue in 2.7.0 and 2.7.1?
-
@stephenw10 , In versions 2.7.x and 2.8, the problem with limiters on a WAN that isn't the default route occurs. The last version that worked correctly was 2.6.0.
The evidence and tests performed in each version are documented. Thank you very much and I hope you can validate from version 2.7.x onwards that the limiters no longer work in a WAN that is not the default .
thanks.
In 2.6.0 the limiter uses the private IP as source and destination, to control the BW for each IP
In 2.8 and 2.7.x the limiter uses the public IP as the source and the private IP as the destination, that is, for the upload it uses the public IP after applying NAT, this does not limit each connection from the LAN, it limits the entire bandwidth
-
@stephenw10 I'm happy to configure this is a virtual and step through versions to find out where the behavior change happens, if it helps. Sounds like @gemg83 has got it dialed down though.
-
Yup I just to replicate it here.
-
@stephenw10 Please tell us what other information you need. I still have the test firewall with snapshots in versions 2.6.0, 2.7.x, and 2.8.0. If I can help with more information, please count on me.
I think the test cases are well documented with all the evidence in this chain, but I'll be on the lookout if I can help with anything else. Thanks.
-
OK we replicated this and are digging...
-
I'm not sure if it's helpful or not to link these two - but I've also noticed that if sticky connections are enabled, the source tracking table remains empty. Which I think is described here:
https://forum.netgate.com/topic/197911/pfsense-2-8-0-sticky-connections-in-dual-wan-setup-not-maintaining-source-tracking
I felt it worth a mention as it relates to gateway groups and source IPs, but I don't know if they use the same mechanism underneath (the above post also appears to be linked to 2.8, where it appears this one was also present in 2.7.x).
-
I don't believe it is the same root cause. That is fixed in 2.8.1-beta. https://redmine.pfsense.org/issues/16282
-
I see https://redmine.pfsense.org/issues/15770 is fixed 15 days ago. Does anyone know how to fix it manually so we don't have to wait for pfsense 2.9.0 release?
-
@sandersui Not sure - it used to be that you could use the patches package to apply patches from the git, but I think that's now private. Might be looking in the wrong place though.
-
It's fixed here: https://github.com/pfsense/FreeBSD-src/commit/7ec06143964a949ebf6885ac120fdf839ad29eab
But that's a compile time patch. It can't be applied by System Patches at runtime.
-
@stephenw10 Cool, thanks.
I'd followed a few redmine tickets that referenced the gitlab and hadn't been able to relate that back to the public one.
Looking forward to it on 25.11 - I tend to do most of my traffic shaping in stacked limiters for multi-wan, especially where the speeds are mismatched.
-
@stephenw10 do you know if support can apply a patch for this on a 25.07.1 system if we buy a tac pro support contract? We're a bit stuck now because we can't use the limiters in our setting.
-
No support are in the same situation we are. It would require building a 25.07.2 release. It's fixed in 25.11 snapshots if you're able to test there. The first public beta is close.
