Both the bandwidth and borrow elements were missing from CBQ queues. Those have now been restored and should appear in the next snapshot.

https://forum.pfsense.org/index.php?topic=79589.0

Same difference. In a simplified sense, queues don't care what traffic goes through them. Of course there are exceptions, but they're agnostic about the traffic.

@deagle: I would like to classify streaming, then make sure each tenant gets a fair amount bandwidth while giving regular browsing priority. I'm open to suggestions if you have some. Interesting thing to know about networks, assuming not super slow like below 10Mb. At any given time, there are only dozen or so flows of packets in the buffer, and nearly all of the packets are from the single digit heaviest of data flows. This rule of thumb applies from a 133Mb link serving 500k active flows, to 10Gb links also handling 500k flows. This means a few things are happening When a tail-drop buffer is full, the smaller flows get hurt the most because they lose the most packets percentage wise. A select few flows monopolize the network and it's hard for any other TCP flows to get in edge wise CoDel and FairQ break this up. In the case of Codel, it's primarily head-drop and is a time based buffer. This means a few things There's almost always room in the buffer, allowing small flows to make it in instead of getting tail-dropped CoDel is most likely to drop a large packet from a fat flow Unless you have a really low bandwidth link that is completely overwhelmed, CoDel will help maximize bandwidth, minimize latency, minimize loss, and redistribute bandwidth by dropping packets from the fatest of flows freeing up bandwidth for other flows to move in. I recommend trying this approach first. fq_Codel and eventually Cake will be much better at this. fq_Codel already works wonders, but Cake has a lot more features, but it's also taking longer than expected because of performance regression caused by so many features added. Unfortunately PFSense only has Codel right now, but that alone is the 80/20 rule.

@Berend: It also looks like the "Kill States" button isn't work either anymore. The in direction and translated destinations wasn't working. https://redmine.pfsense.org/issues/6530 https://redmine.pfsense.org/issues/6531

You can easily accomplish your goal with HFSC traffic-shaping queues. 1 queue per tenant, then set the link-share & upper-limit values to the appropriate values. If you need to group certain tenants you can create a parent queue with the appropriate tenant queues as child queues. Forget about limiters.

If it's a specific IP address, you could just use priority queue and create a firewall rule that assigns all traffic going to that destination to be placed in your high priority queue. Priority queues can cause issues in some cases. I prefer to use HFSC. Then you just assign a minimum amount of bandwidth, and it will guarantee that all of that traffic will get at least that amount of bandwidth.

Thanks Nullity and Harvy66 for reply. You are right, I want fair usage of bandwidth. As of now I have setup equal share and it is working. What about Penalty Box? Will that work? Can you please guide me for setting up users' own queue? Just some link will work. Thanks.

Making CBQ child bandwidth % changes by config.xml will accept anything I want. Via the GUI I get errors if I change the parent bandwidth value.  Currently running ver 2.3.1_1 and the GUI still doesn't show child bandwidth values in the Shaper by Interface. So apparently not fixed with the last patch. Does anyone in an escalated position read these issues and are inclined to fix them?  Because XLM shaper restores function, it seems this may entirely be a GUI issue.  Since the GUI doesn't have the % field for entry the XML shows a valueless entry of <bandwidth></bandwidth>rather than say <bandwidth>50</bandwidth>.

If you know the IP and port of your corp website, you can use HFSC (or your fav traffic shaper), and carve out some guaranteed bandwidth for your corp website.

A simple forum search will get you several posts on some complete traffic shaping configs.

Hello Harvy66, Thanks for your reply. However, I'm not sure I understood what you meant by "you can't share bandwidth between interfaces…". Am I doing that here? What I don't understand are: why my floating rule, as described in my original post, is not matching the OpenVPN traffic at all (it would be great to get this one working), why, once or twice, I found the OpenVPN tunnel connection states bound to the lo0 interface. Any idea on the above two queries?

1. The WAN knows nothing about the packets inside of the VPN tunnel. All it knows is the tunnel traffic goes into the VPN queue. As long as that queue has enough bandwidth assigned, all is well. 2. The WAN knows nothing about the packets inside of the VPN tunnel. It won't be able to differentiate traffic for the different queues inside the tunnel.

thank you…although I was expecting another answer...a more positive one  :(

Hi, thanks Nullity and Harvy66…. this worked. It's not as practical like the limiter but it works too.

Thanks for the clarification Derelict.

Yes I know I have to apply/reload the firewall rules.  I actually had to reboot the entire box in order to get things working properly again.  Not sure if it's a bug or something. LoboTiger

https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order The tl;dr version of user-defined rule processing is: Rules defined on the floating tab are processed first Rules defined on interface group tabs (Including OpenVPN) are processed Rules defined on interface tabs (WAN, LAN, OPTx, etc) are processed last And remember, PFSense doesn't look at "packets", it only looks at the first packet. All subsequent packets for a flow are not evaluated.