Messing with queues - a slightly less messy approach
Queueing rules (rules that put packets into certain queues) can be confusing to brain damage levels because:
1. Every queue works on exactly one, single interface (outbound)
2. pfSense allows you to queue traffic in any rule, on any interface and in any direction
While 2. causes no malfunction it certainly allows for rules that make no sense (queueing wise). This is confusing for novice users (like me). Especially when dealing with multiple interfaces and when mixing floating and interface rules - trying to get all the traffic into the right queues can be quite a challenge!
So - let's NOT mess this up!
Instead of using the queueing option in firewall rules, I use tags - one tag per queue. This completely liberates me from having to think about 'does this actually match the traffic I think it does'? Because it will! Always! How?
(This is the cool part, get ready…)
I have one firewall rule for every tag. This rule works on a single interface, on outbound traffic only and - you guessed it - puts the packet into the desired queue, depending on the tag it matches.
And there you have it: Nice and easy queueing.
I use the tags "low", "medium" and "high", to tag low, medium and high priority traffic anywhere in my ruleset.
I have three queues on each of my WAN and LAN interfaces: qLow, qMed and qHigh (I also have super-high priority queue "qAck" on WAN and a default queue "qLink" on LAN).
I have three floating rules to put the tagged traffic (low, medium, high) into queues (qLow, qMed, qHigh). Like this:
Source: WAN address
Destination: not WAN subnet
Advanced > match by tag (eg, "high")
Advanced > Queue: (eg "qAck/qHigh")
What do you think guys?
Maybe the GUI could be improved using this approach. Less guessing for the user.
You tell pfSense a tag that belongs to a queue in the shaper setup (or just use the queue name as a tag). pfSense then takes care of creating queuing firewall rules - one for every tag/queue pair. The queue option in the GUI presents the queueing tags.
No, because none of this is necessary. Everything can already be done with the normal queue functionality. A user who doesn't understand how to create queues will screw it up anyway.