I wanted to thank both of you for your input on this, but seemingly can't.  Thanks, and sorry for the delay in it; I stopped looking after a week!  I'll work on the assumption that even the basic queues created by the wizard should be treated with suspicion for now.

There is a link right there on the L7 page to upload patterns. Patters are like those from the l7-filter project. http://l7-filter.sourceforge.net/protocols

It's best if you don't use the wizard and manually create the queues to fully understand how it works.

The queues on the LAN interfaces are independent of each other therefore you cannot traffic shape downstream without setting a hard speed limit on each LAN interface which totals less than your total downstream speed. To avoid capping the speeds on the LAN interfaces, one solution is to use a second pfSense box in transparent bridge mode to perform traffic shaping on the entire upstream & downstream WAN traffic.

If you have the MAC address of all the machines, I guess you can give them fixed IP addresses too? Then you should be able to create two "Alias" with the IP addresses of the two groups and create firewall rules according to your needs. With that in place you should be able to divide bandwidth between the two alias groups with the shaper.

I don't know if it's there or not, feel free to search on redmine I don't know if that will ever be possible, but you can put in a feature request ticket (target=future) for it.

I just need some clarification here: On topic: Should it be like this? IN/OUT Limiters: IN = Use "Source Address" if you're going to limit bandwidth per user. OUT = Use "Destination Address" if you're going to limit bandwidth for the whole users. Current I am using "Destination Address" Mask only for limiting bandwidth. Question: Do this method will work if I combined the two Mask? TIA!

Setting up Limiters or Queues is VERY tricky without perfect understanding of what every setting does. You've most likely configured it wrong.

manually create a queue via the web interface? or edit configuration files? which files so as not to spoil the configuration?

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.

I am just now starting to need QoS for a cluster with 4 different security zones where I need to find a solution without bridging.  I am still experimenting with Limiters to see if I can get by using them but I am afraid they might have big performance issues (based on reading the forum not from experience) and I know they don't have all the features that I want to use with the normal queues. I have been using 2.1 on a few non critical systems and I haven't dound anything that would make it better for this.  I think it might be a limitation of the QoS implementation on FreeBSD.

In order to shape download traffic you need rules on the LAN interface, no matter if the traffic is coming from WAN, OpenVPN or whatever. In this case, you need a rule on your LAN tab with source: LAN subnet and destination: your OpenVPN subnet (not the server public IP), and specify what queue you want that traffic in (you previously saw the traffic on qLink because it is was catched by the default rule that sends traffic to qLink)

That's why it is a good idea to have queues with the same names on both LAN and WAN ;)

Firewall rules are evaluated from top to bottom, so create another rule above the other ones that catches the traffic from that PC, and send it to the appropriate queue (one with more priority, or with more bandwith, or without limiters, depending on how you configured your shaper). Regards!

@jimp: FYI- the masking is incorrect on the example given by cheonne earlier in this thread. For the upload limiter, you want a source mask For the download limiter, you want a destination mask The same pair of limiters would be used for both LAN and WAN rules (LAN - In=Upload, Out=Download, WAN - In=Download, Out=Upload) thanks for the correction.. ;) i mislook his thread ttle "…per ip"

What is described here is a known bug in pfsense, provide more detail here: https://redmine.pfsense.org/issues/3096