Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing
-
Ah, that's great to know. Yeah, it's not the same patch.
Ok, that should make it much easier to replicate now we have some idea what's triggering it.
Steve
-
Finally it can be said that the problem has been identified.
Stephenw10 of the Netgate development team has identified the cause of the problem.
The problem occurs when the Captive Portal is active and limiters are used. Practically due to a captive portal bug, even if this refers to a different interface, the limiters do not work correctly on all interfaces (including WAN ones, therefore the ports natted towards the internal segments and subject to limiters).
If you don't use the Captive Portal the limiters work without problems.Luca
-
Yes, exactly that. We are still looking to find a workaround if possible but it's not easy because of where the issue lies.
If anyone is still seeing problems with Limiters when they don't have the captive portal enabled on any interface we want to know about it.
Steve
-
I'm afraid it's not looking too good for a workaround that can be applied as a patch. The interaction between pf and ipfw is at a low level. We are still investigating though.
Steve
-
Steve, do you think a 2.6.1 and a 22.01p1 will be released pending 22.05 (I see it far away) ...
Luca
-
@stephenw10 said in Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing:
The interaction between pf and ipfw is at a low level
and if that is the issue, does that mean that any one who was using FreeBSD 12.3 and wanted to use Limiters ( dummy.net ?) would have an issue ?
Is this issue native to FreeBSD 12.3, or created when Netgate takes the FreeBSD 12.3 source and cooks its own derived version ?
Heck, I don't even know if the FreeBSD used is a patched one (with upstream corrections and / or Netgate's salt&pepper), and then build- or just the source "as is".Anyway, no answer needed, although appreciated. I know issues will get dealt with.
Thanks for the update.
-
@luca-de-andreis Impossible to say yet. We are still looking at it along with a number of other things.
@Gertjan We added code to allow the use of pf and ipfw at thew same time. Normally in FreeBSD you would never do that.
Steve
-
Ok, let me think about that.
With pfSense I was doing just that for the many years. Maybe pfSense is less FreeBSD as I thought it was.
Scary situation, though, as the captive portal is a 'must have' for my usage.
Limiters, on the other hand, should be part of the standard toolkit of what a router firewall has to offer. -
I want to add a +1 as a new pfsense user, I've encountered this issue. I started chasing faulty hardware initially with no luck, but when working back through my changes I found that disabling either captive portal or the floating rules assigning limiters solved the issues I was seeing.
In my case, connected clients would start a speedtest and the test would go from 500mbps to 0, and then all connectivity stopped. This affected all clients and not just the captive portal ones, so I'm reasonably confident I'm affected by this regression too.
-
+1 here, i've same problem.
After upgrading 2.5.2 to 2.6.0 all machine seems hung..... some ping from local to firewall passes for few seconds...I've removed all limiters but nothing solved.. this firewall config had 20+ openvpn servers. I'll think there is something in routes that causes this problem... anyway i reinstalled 2.5.2 and it's all ok.
-
Do you have the captive portal enabled on any interface? If not then you're not hitting the issue discussed here.
-
Hi we are facing similar issues:
pFsense with about 140 interfaces. On one of them captive Portal is enabled.
WAN PPPoE Connection 1G.
Limiters with basic configuration, Tail Drop, default scheduler.
With 2.5.2. everything worked fine, upgrade to 2.6.0 with very odd problems, ping drops, ipv6 partially working, after applying interfaces they were working for a short time.Disabling limiters seems to solve the problems.
-
I've not captive portal only limiters and VLANs and many OpenVPN servers.
-
@blackangel84 You should start a new thread then unless there is already another thread with similar symptoms. You are not hitting the issue being discussed here.
-
-
-
@stephenw10 said in Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing:
https://redmine.pfsense.org/issues/12834
Good afternoon.
I have the same problem. As a test we create a new VLAN, we create new limits and the same thing happens, it does not have a WAN connection.
We remove the limits and this VLAN has an internet connection. It is difficult to understand how they perform an update to a stable version having these flaws.
If someone could solve this problem, it would be good to tell us how. Since in my case, the VLANS are intended for public Wi-Fi and need to be limited.
Greetings.
-
Do you have a captive portal enabled?
If so you are probably hitting that. You can still use the Limiters defined via the captive portal though.
Steve
-
-
So, I am actually experiencing this problem on 2.6.0 with limiters, without Captive Portal enabled. We were using Captive Portal a week ago, but we just switched over to using just RADIUS MAC authentication. I actually upgraded to 2.6.0 in the middle of the migration (that was a really poor choice as now I can't revert) and had to disable Captive Portal earlier than anticipated. I had tried the Captive Portal patch while we were still using Captive Portal, but that caused so much lag that I instantly reverted and didn't have time to do any further testing. After finishing the migration, I tried setting up limiters and found that they couldn't work without the Captive Portal patch either. I installed the patch again, and I was able to limit the downstream bandwidth for individual users (for some reason I can't get upstream limiters to work, but that is probably just a poor configuration on my part). When I enable the limiters, I start dropping tons of packets as soon as the link comes under load from my host (even with a very small load like a video game).
-
Check if ipfw is still active. Try running
ipfw show
at the command line.
It should return an error. If if returns a list of ipfw rules then it's still active and Limiters cannot work correctly. If you have not rebooted since disabling the CP then do so.Steve
-
@stephenw10
'ipfw show' returns an error:
ipfw: retrieving config failed: Protocol not available
And I have definitely rebooted since disabling Captive Portal. That was certainly a good suggestion, though, as I have 100 users and try to reboot as seldom as possible. -
Hmm so how exactly do you have the Limiters configured?
I've not been able to replicate any issues as long as ipfw is not enabled.