Kind of agree, I guess.

HFSC is not developed by the pfSense project, but the pfSense code could be tweaked to assign the linkshare m2 value to the HFSC bandwidth in all cases (and also make linkshare m2 a mandatory field)

Best way is with floating rules, action match, direction out, and filtering by destination port. Then use the rules to assign queues

Try this?

https://forum.pfsense.org/index.php/topic,62188.msg335842.html#msg335842

Edit, add:

As it happens, I finally gave this a try (albeit on a 2.1 system) last night, as my users had managed to offend me sufficiently (MPAA sharing violations - not only do they indicate that users have violated our policies and mean I need to find harsher controls to curb bad behavior, they also irritate the heck out of me…) and while I had some limited effect, I could not get any traffic into the proxy queue nor the http queue. It's all twisty little passages, all alike, in the dark and filled with Grues from a documentation standpoint. After no apparent effect from the linked method, I eventually tried using the layer 7 stuff to identify cache hits and misses and place them in queues, at (roughly) which point everything stopped working and I gave up and reverted to a saved configuration from before I started messing with the poorly documented Shaper. There has got to be a better way to do this, or better documentation of how to do this (that actually works).

The firewall is not connection-aware, it just filters packets.

Squid works for HTTP traffic only, but it is connection-aware. I vaguely remember that Squid has some limiting/throttling options, but I have no idea if that would useful for you.

I currently have no idea what's going on the "64 bit front".

An easy way to spot if my changes are included is to check if the DSCP list (in the WebGUI, Firewall - Rules - add new rule via teh plus sign - DiffServ Code Point - Advanced) contains the VA code point.

Not necessarily.  It still should be checked that ICMP's are hitting the appropriate shape bucket.

Squid is setup as a transparent proxy which I run HVAP (anti-virus).  I will need to point QoS to manage at the proxy instead.

New release should happen soon. See https://github.com/pfsense/pfsense/commit/93a79543999602a3b71e8376a6aa6ed46e79af4d

In the actual firewall rule, in the "Advanced features" section, just above the place where you select your Layer 7 container, is the place to select your "ACK queue" and "regular traffic queue".

Your welcome!!  yes using Alias's make it easier when setting up rules and things using IP's and ports.  just dont forget to back them up to your local machine so you have a copy of them and your whole PFSense config as well.

No. There isn't any long-term usage tracking that would work in that way. Not with a normal network anyhow. If it were Captive Portal-controlled and with access authenticated by RADIUS, with RADIUS set to track usage and deny access, that might work. I believe there are examples of this elsewhere here on the forum if you search a bit for terms like "captive portal radius bandwidth" you might turn up some relevant hits.

Maybe I shouldn't say this on these forums but have you had a look at Gargoyle (based on OpenWRT)?

It seems to be very good at the sort of quotas you're describing.

http://www.gargoyle-router.com/index.php

Gargoyle is Linux-based but, for future reference, pfSense is FreeBSD-based.  ;)

LAN Rule

LANRules.jpg
LANRules.jpg_thumb

"Non-floating" rules are just specialized "floating" rules in which the interface is pre-set and "quick" is used for all of the rules (this is done by pfSense for quick and easy every day per-interface rule creation). When pfSense is applying the rules, the rules from the floating table will be put before the non-floating rules.

@senser:

Outgoing traffic that was put into queue X of the WAN interface will result in related incoming traffic being put into queue X of the LAN interface (if it exists) and vice versa. Thats why I told you to give queues the same name on both interfaces.

Ah, learned something new. Wish this was in the guides. I watched a YouTube video about setting things up for optimum bandwidth usage, and the guy split all the queues by suffixing them with U or D depending on interface. I see now that this isn't the best way to do it. I'll go ahead and fix all my other queues accordingly… lol

Thanks again for everything.

Is there something funky with the queue bandwidth limitations? (Ie, set the bandwidth for an interface to 50 Mb) ?

I've been playing with downstream's queue options (my lan interface's queue options)  If I set it to 50Mb/s it hits around 37 Mbs. if I set it to 56 it gets around 47mbs. If I set it for 58 and 59 respectively ,It caps out further without killing my connection (latency etc) (best result so far is 51mbs)

If I set to 60.. it somehow spikes to 56+ mbs and i begin to have latency due to filling my pipe.  It's a bit curious how small increments prior to 60mbs settings didn't change it much, but setting it to 60 and the entire thing blows up. haha.