Bandwidth Limiter Not Working 23.05.01 for Policy Based Routing Firewall Rules
-
Hi All,
I wonder if you could shed some light on an issue.
Running Netgate 8200 with PF 23.05.01
Limiters for hosts on download side work fine, but the upload side does not work. This is a firewall with Policy Based routing enabled for multiple WAN interfaces. If I remove the Gateway and set it to default, the limiters work perfectly - however, this is not the desired outcome as I want the policy based gateway rules to stay in place. Its a common setup in the environment I am in where we have a set of users traversing 1 internet WAN interface and another set traversing a different WAN interface - hence the policy based routing. We have 5 different WAN interfaces - each used at specific times or under specific conditions - regardless - this should work, but it does not work. Only works when the gateway is set to default per rule.
All the firewall rules are on the "LAN" interface.
Will there be a fix for this ?
I look forward to your replies
Cheers
Rob
-
Hi All
Further to my post above - Just letting you know - you either have to run Community Edition 2.7 or wait for 23.09 for the above issue to be fixed. For Netgate appliances - thats a long time away
I may drop back to a very old version and see if that works on the appliance
Cheers
Rob
-
@ciscoguru I am also facing this same issue on CE 2.7
-
Unfortunately this Issue is long overdue. See 14039
For now all out firewalls (20+ devices) are stuck to 22.01 this is the last version where this worked.
Recently there was some movement in it and the redmine report was cherry picked by kprovost and fixed in the dev upstream. So hopefully next release will have it fixed.
-
@solarizde Thanks for that reply.
Do you know if 22.01 runs on the 8200 Netgate appliance ? I know that some versions dont work on netgate appliances.
I can't see why not, keen to test. Let me know if you can
Cheers
Rob
-
@ciscoguru Yes it works. I have one here.
-
-
@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.
