Bandwidth Limiter Not Working 23.05.01 for Policy Based Routing Firewall Rules
-
@solarizde Do you know if we need TAC support to get the 22.01 release for the Pfsense Plus appliance or is there a public download for this software ?
I can't find it. Let me know if you can.
Thank you
R
-
@solarizde - Netgate just said they dont have any old firmware editions working for the 8200 but only for the 6100 . There is no old firmware for the 8200 that works
Do you know any different ?
Cheers
Rob
-
@ciscoguru Sorry my bad, just checked again. It is indeed a 6100 we have on 22.01, our new 8200 is on current one but oh man this means I need to deal with it too :(
Maybe the 6100 FW is working on 8200?Or if you are in contact with netgate support about it, do they offer a dev version for the 8200 including this fixed?
-
@solarizde Netgate dont have a fix for it. I am not sure why we can't run this on 6100 because its very similar in specification. I asked for dev version and they said no. Also they said we should use the floating rules to fix it but I never got that workaround to work.
Here is what they told me:
"Hello,
Unfortunately we don't have ETA when 23.09 will be released.
You can try to implement the workaround from Marcos' note.
https://redmine.pfsense.org/issues/14039#note-2
" -
@ciscoguru Im in the same boat - never got the floating workaround working relyable. Sometimes it worked sometimes not. Unfortunately this means for me currently no use for the 8200 at the moment :(
The Problem; it is not just a pfSense netgate related thing which is easy to apply. It is a flaw in the FreeBSD pf itself and need to be pushed there. So totally understandable for me why it is not just a "yeah hotfix tomorrow" thing. Good thing is, it already got commited in the FreeBSD repository.
-
@solarizde Wait, this is supposed to work? I'm quite new to pfSense, but right now I'm doing this by tagging the outgoing rule(s) and then matching that tag on a floating rule.
In the floating rule I set direction Out, of course In/Out for the pipe is inverted. I just specify any for source and destination, then specify the tag you put on your outgoing rule or the rule(s) you want to match. The tag will basically be your 'source' in this I suppose. Also specify the gateway you want to apply it to.
This has been working for me so far. I hope it helps you achieve what you want to set up.
-
@break1146 - The way you explained it here, makes perfect sense - The support team could not explain that - they just pointed us to a link that said it would be fixed in 23.09 on PFSENSE PLUS. I did a quick test, works perfectly. I looked at the CPU cycles and its negligible. So thank you for taking the time to post that. That is a firewall saving post!
-
@ciscoguru Happy to help :). It initially took me some head scratches as well as these type of features are the reason we've been exploring pfSense recently.
-
This is really lame. I can't get a floating rule to work.
-
@dlogan I can try to help explain it with some screenshots.
But first this:
The principle is this; you want to tag all the rules that have outgoing traffic over the gateway you want to limit. This can be a gateway group, because you will only apply the limiter to a specific gateway in your floating rules. You will only match the tag and the interface and gateway on your floating rule, the tag will be able to determine the traffic from your LAN. If you make a rule on your LAN that doesn't have a tag and you place it above the ones that do, this traffic will not be limited.Go to your LAN interface and determine what outgoing rules you have with traffic you want to have shaped. Make up a tag and fill it in for those rules.
Now go to the floating rules tab and make a new rule. I assume you have the limiter already set up for this example. Set the action to 'Match', select your WAN interface, set direction to 'Out' and protocol what you need, but that's probably 'Any'.
Leave Source and Destination to 'Any'.
Under Tagged, set your tag from the rule in the LAN section here to match it.
Specify your gateway and your limiters.
I hope this helps you set it up for yourself. I picture it in my head as catching the traffic mid-air, while on it's way to leave out the interface and the floating rule knows what traffic to catch based on the tag that you set.
Good luck! Feel free to ask any questions, I'll respond when I have some spare time.
-
@break1146 - thanks for these great instructions! In the case of a multi-wan environment shouldn't the source be WAN address of the interface the floating rule is applying to? For instance let's say there are WAN1 and WAN2. If the shaping (limiters) should be applied to tagged LAN traffic exiting WAN1, should the source be WAN1 address and gateway the WAN1 gateway, or can the source remain as any? Thanks in advance.
-
More specifically, I was curious on this because of the advice given here when setting up limiters:
https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html#create-floating-rule
Then again, here in the documentation for floating rules it mentions that outbound floating rules on WAN interface have the source as firewall after NAT:
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html#precautions-caveats
So would it be superfluous to do this (i.e. set the source as WAN address), or is it still needed in a multi-wan configuration?
Thanks again.
-
@tman222 I would only specify the gateway as the source really doesn't matter. Remember that you're matching the traffic and what my goal was with tagging the traffic is being able to create rules on the LAN that correspond to different limiter policies. If you apply the a floating rule with limiters setup with WAN1 specified as a gateway and a tag, only traffic going out of that gateway and with that tag will be affected. Traffic going out of WAN2 will go at full speed. Traffic not tagged will go at full speed. The reply-to and what not is already set to that WAN, that is your routing policy on the LAN. If your gateway group on the LAN decides to send your traffic to WAN2 because WAN1 is down, then it will not be limited anymore because it's not being matched. If you create a similar rule specifying the WAN2 gateway and the same tag, it will apply again. The tag is there to make it modular, specifically. You are just looking at what goes past and scream waaaait a second lol. So to summarize, no need to specify a source, no.
But all of that being said, I would suggest to just apply your limiters to the corresponding LAN rules. The point of this thread is that this didn't work anymore due to a bug and we needed a workaround. That has since been fixed. Applying it directly to the LAN rules is less work and you don't have to keep track of tags.
-
@break1146 - thanks for your response. I actually came to this thread after noticing that the limiters did not work correctly when applied to LAN rules when a gateway group is used as the default gateway on the rules. Essentially what I was seeing in that case, was that the upload was correctly limited, but the download was limited to only 50% of what the limiter had been set to. I tried out the approach you suggested (floating rules on WAN with tagged LAN traffic) and everything works as expected. Perhaps this is a bug that I should report? Or would you have any ideas as to why I'm only seeing download limited to 50% of limiter value when applied to LAN rules directly? Thanks again.
-
@tman222 I haven't made any new setups with limiters, but I remember trying it and seeing it work. The problem was already fixed at the time of writing earlier in CE if my memory is correct.
My test was quickly in between since it hasn't been a pressing issue for me anymore, so maybe I haven't tested it as well as I should have.
I'll see if I have a moment in the coming days to test it more thoroughly and I'll report back here.
For if it's relevant, I'll be testing with a 2100 and a 6100 (different architectures). -
Hi All
This has been resolved in 23.09.1
Cheers
Rob
-
@tman222 said in Bandwidth Limiter Not Working 23.05.01 for Policy Based Routing Firewall Rules:
@break1146 - thanks for your response. I actually came to this thread after noticing that the limiters did not work correctly when applied to LAN rules when a gateway group is used as the default gateway on the rules. Essentially what I was seeing in that case, was that the upload was correctly limited, but the download was limited to only 50% of what the limiter had been set to. I tried out the approach you suggested (floating rules on WAN with tagged LAN traffic) and everything works as expected. Perhaps this is a bug that I should report? Or would you have any ideas as to why I'm only seeing download limited to 50% of limiter value when applied to LAN rules directly? Thanks again.
Just to close the loop on this, it looks like the issue I was experiencing where the download was limited to only 50% of what the limiter had been set to has been resolved in 24.03:
