problems with flexible limiters set using floating rules
-
@manu77 If that is the case, if there is no treatment on the egress interface (no buckets there, no option to drop selectively based on pre-NATed source IP etc.) then this would expain why limiters on out_floating_rules behave like they are drunk (although they should not work at all instead of leaving 0,2Mbit/s like in my tests) ... Either way, if you ever find out how to make a proper QOS/limiters in a multiWAN PFS environment, please post it here - to me this is one of the two things that I lack in PFS (the other being parallel IPSEC tunnels to the same remote network range) but for sure it's the most important one....
-
I have this problem as well, with my multi-wan setup, but only with one of the wan's. WanUp and WanDown limiters works perfectly, Wan2 limiters have the problem described here - download works fine, but upload is limited to about 0.2 Mb. If the above description is accurate, how come the first Wan limiters works fine? I even think the Wan2 limiters worked at first, but stopped working when I was playing with it...but I might be wrong about that. Maybe those never worked.
-
@eriknuds I can't say for sure if the first WAN limiter worked fine in my setup. I just don't remember... You have clearly encountered the exact same issue because you ran into the 0,2Mbit/s problem.
-
@AdamL said in problems with flexible limiters set using floating rules:
I found a workaround, i.e. I've set up floating rules (direction = in; attached to LAN interfaces; GW = GW1 for one rule and GW2 for the other rule) for those flexible limiters and this works fine.
However, this doesn't change the fact that in case of 'out' floating rules on WAN interfaces, the 'up' limiter does not work - still looks like a bug to me.You do know that the limiter up/down direction reverses on an out floating rule right?
-
You can also mark the connections made by hosts on LAN based on their inside address and match that mark as it leaves WAN using an outbound floating rule that sets a limiter there.
-
@Derelict said in problems with flexible limiters set using floating rules:
@AdamL said in problems with flexible limiters set using floating rules:
I found a workaround, i.e. I've set up floating rules (direction = in; attached to LAN interfaces; GW = GW1 for one rule and GW2 for the other rule) for those flexible limiters and this works fine.
However, this doesn't change the fact that in case of 'out' floating rules on WAN interfaces, the 'up' limiter does not work - still looks like a bug to me.You do know that the limiter in/out direction reverses on an out floating rule right?
Sure. When I say up or down I mean the actual direction from the 'user's perspective'.
-
@Derelict said in problems with flexible limiters set using floating rules:
You can also mark the connections made by hosts on LAN based on their inside address and match that mark as it leaves WAN using an outbound floating rule that sets a limiter there.
That is an interesting thought. So you mean staying with the concept of outbound floating rules with limiters but matching them not only to the WAN interface but also to some 'marks' set by LAN rules?
-
If that will solve the problem.
-
@Derelict I will definitely test this out. Thanks!
-
I now tested with PIE and FQ_PIE, and I tested with limits above what the line can normally do (it's a WISP conection - both are actually...) and it doesn't happen anymore. I have the same firewall rules. Yes I know to reverse the queues for in/out wan rules, and I have the same setup for the other wan rules which worked all the time and I haven't changed the rules now that they work with PIE/FQ_PIE...really weird because yesterday I tried other settings than PIE and codel and none worked...I also did a state reset between the tests, not just making new connections, but it didn't fix the issue yesterday.
-
@eriknuds And what about flexible limiter? Honestly Qos(queuing) is not so important to me. Flexible limiter is...
-
Yes, it's set up as flixible now with masks on the queues and not the limiter, and it seems to work fine...
-
@eriknuds
HelloVery interessant . But I don't see exactly your configuration.
Could you please send us screenshots for :
1 -Rules in LAN ( list view) and marking options in Rules you chose -> I m curious to see how you say to PF to mark the packet properply with two different possible gateway
2 - Rules in Floating ( list view) and options in Rule for matching traffic -> I'm also curious to know how you match packet with 'out' direction on this step
3 - Options chosen at this step bellow
thanks a lot
-
FW Rules:
The gateway is the gateway group (Loadbalance) in all the rules. To test each wan connection separately I just select another Tier in the gateway group so only one gateway is used.
I only have the 4 floating match rules related to Limiters/queues. None for the LAN interface.
Not sure if I have done everything right, but it seems to isolate the traffic and not disturb other hosts even though I exhaust the line with speed checking...and the isolation is really all I need. AQM etc is not a requirement. My wan connections are pretty symmetric, though not very high bandwith, WISP connections. But I would really like triple isolation like in CAKE. It really sucks that OpenWRT have had CAKE functionality for so long and pfsense seem to be no closer to getting it.
-
@eriknuds
Thanks to take time for showing us your conf. I will test it and tell you .
I've a lab here with 6 firewalls to emulate multiwan. so we will see. -
-
Hello All,
I confirm this configuration works and works well. Each time the gateway changes, the Pipe is well affected too with 10 secondes of floating bandwitdth ( no traffic )
Now I must go further to see how to add specific traffic in a specific queue and described from WAN ! because the floating rules for this test are set up as you post , I mean from * to *nice day
-
@manu77 ,
I have selected the appropriate wan interface in each rule (in-rule and out-rule for each wan interface) - in the WanIn/Out rules I have selected only the wan interface, and in the corresponding wan2 rules I have selected only the wan2 interface.
Good luck with any further testing:-)
-
T tumbleweedcity referenced this topic on
