You seem to be make some assumptions with what you're talking about and you're leaving out the details and reasoning. At an abstract level, many of us understand how the queues in PFSense work and it seem reasonable. The only reason it would not seem reasonable is because of an incorrect assumption on your part or something you think could be simplified, but you have not really made much of that clear. One thing that I do clearly see if you talk about upload and download. Technically, you can only shape egress traffic. Practically, you can shape download traffic, but it gets messy code-wise. It's easier just to shape data leaving. In this way, you have a separate queue for WAN and LAN so you can shape data leaving each interface.

I think qInternet and qLink is only needed if you have multiple LANs.

Can be easily done: Just make a limiter for every speed. And a queue in it. Then make a rule to put the traffic in the limiter. Select the queue name not the limiter it self. And yes you have to make separate limiters for up and download. Here is more info https://forum.pfsense.org/index.php?topic=63531.0 Nullity pointed out to me earlier :)

@drbobo: So too sum it up! A good way would be using a simple priority queuing scheduler. For the following q's: qAck qHigh - Special users qNormal - Normal users qLow - Guest users ( a lot of mobile phones and such) Each with Codes on for lowering the ping problems and such. Then add a limiter on all traffic, to not have downloaders saturating the link. Still think Fairq would be better then Priorty or CBR cause it keeps everything more dynamic. Or any opinions? I don't think that's optimal, but you can always try it and find out. Here's my favorite QoS tutorial: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/

Ok. Thank you.

https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/ This is the best write-up I've seen so far.

This isn't a traffic shaper issue. You might be able to do something like this with squid proxy & squidguard.  If I remember right, one of those two had a section where you could deny certain file types.  I don't remember if you could link it to a schedule or not.

Replace your AP with a AP that supports vlan you can start from tp-link AP that are very cheep in price  or use something like Xclaim.btw the switch has to support 802.1q  that a tplink 5 port desktop switch also can support it and it is really low priced

FYI- This is no longer a problem on 2.4.

From what I have been able to discern, and a quick test, you can use your floating rule set to the IPsec interface and select your queue like any other interface. The traffic will fall into the respective WAN interface and queue for the VPN connection. I tested with the following lab setup. PC1–pfGreenBay-WAN---pfInternert---WAN-pfMilwaukee--PC2               |                                                          |               |                                                          |         IPsecTunnel---------------------------------IPsecTunnel I placed all ICMP in my "VoIP" queue and watched the PPS count on the queues as I ping from PC1 to PC2 and saw the packets show in the VoIP queue. As for how to "match" the traffic, you can use the DiffServ flags (don't trust them to be there) or by IP/port numbers..... I just re-read you post. I see you are familiar with the DiffServ flags. as for the magic rules? I have no idea I don't work with the wizards much. I don't think I'm telling you anything new at this point but this may help clarify things for other noobs.

I've got it… In the Interfaces->LAN configuration page, I have configured the static IPv6 address. Once that address is removed from the configuration, traffic shaper interface works again. I don't know if this is a bug, or a feature. If traffic shaper does not work with IPv6, it would be good idea to leave the message in the GUI instead of the silent failure. Regards, Alex

That's my point, your limiter will bufferbloat you. Consider trying to limit bandwidth with download queues instead of the limiter.

@spcolyvas: Thanks Nullity, ICMP packets do go through the same limiter.  Eventually I'll be pumping video through these limiters to see how the video client and server adapts to the bandwidth constraints, latency, packet loss etc.  the client/server should do stuff like adjust the framerate, resolution etc.  The problem is that the behavior that pfsense is showing starting with 40ms latency and counting down to 6ms latency will really mix it up.  it may be a good test but I'd like to run other tests as well. For testing, use limiters, sure. Limiters, AFAIK, make no worst-case latency guarantees. but for actual deployment of video/audio services use HFSC, optionally with "CoDel Active Queue" enabled. I'd at least test your scenerio with HFSC to see your latency fluctuation is being caused by limiters or something else. I dunno. Without more details it's hard to even know where to begin. Maybe iperf is queueing packets in bursts… maybe... ? More tests are in order. :)

@KOM: On your floating rules, for each one change the interface to WAN, and set the Source from LAN net to any. okay, I have cheated a bit and only changed my qDNS entires, qDNS now is populated and it seems to work now as I try to browse the net and try to observe it (refer to attached image). and for what I notice, qDNS on the LAN side does not have any activity, is this okay? [image: pfTop.png] [image: pfTop.png_thumb]

KOM's solution is good, but here's another solution that uses the low queue instead of the default one. Floating match rules are executed in order. If you don't want all your IPs to be in the default queue, you might create two floating match rules. The first, sets everyone in the low queue, and the second one raises the queue for the IP you want.

I've wrote a quick tutorial from my multi WAN traffic shaper experience here: https://forum.pfsense.org/index.php?topic=120380 Any improvements are welcome ! And hey, thank you Harvy66 for your solution ! @Nullity: There's still some serious packet loss going on. You thought of maybe too much packets. Is there a rule of thumb for the packet number / bandwidth ?