problems with flexible limiters set using floating rules
-
1 . when you do your LAN rules, have you tried using gateway group? Your setup seems fine and it is indeed very strange that the packets are still being pushed to GW1 when it's down (you have the 'skip rules when gw down' checked!) but maybe gateway group would do some difference? If not than this 'skip rules (...)' setting is absolutely and totally useless.....*
doing this config return to use floating rules without any gateway fixed in LAN rules because I fixed the default gateway in routing config here
Moreover, 'skip rules when gw down' is not efficient on a gateway group adn it makes sense in fact ! ( see this it is very interessant https://forum.netgate.com/topic/133099/required-number-of-gateway-groups/2
for your point2 , you can acheive this with 2 groups with gateway tier inverted. But after, you have still the pb to affect the limiter ... like me :
- My version is the last as I know !
- My version is the last as I know !
-
@manu77 That is exactly my point. I absolutely have to use gateway groups and 'skip rules (...)' does not apply to them so this 'skip rules (...)' option will definitely never help me achieve a mulitWAN+flexible_limiter setup.
It also doesn't help you achieve a mainWAN/backupWAN+flexible_limiter setup either ;)
So basically we're back to nothing.... I still think floating rules for 'out' direction would be best but as I wrote on 14th of February, this doesn't work and I still stand by the opinion that it's a bug. -
Adam,
Sorry to break your dreams but catching packet with Floating on Wan Out is not possible !
It is not a bug .
You cannot get a packet only on outgoing direction ( except for a packet send by PF itself) because the packet is always handled by the ingoing interface and never by the Out interface. When the packet arrives , PF can decide what it will do with it . It is the unique moment for a router to take a decision and action regarding a packet.
When the packet leaves the int IN to its destination, it will pass through the int OUT for instance , but at this step it is too late for treatment. -
@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
