http://forum.pfsense.org/index.php/topic,11986.0.html

@TreeTopFlyer: Again, from my understanding, once the lower priority (downstream) traffic hits the pfSense box the packet is dropped (which would be correct), with no ACK back, and the packet is sent again thus flooding the downstream pipe again. If the sender is behaving appropriately, the sender would be naturally throttled just by the fact that it is waiting for the ACK.  Thus each packet that is dropped will delay the sender, and allow the higher priority packets to come through.

EDIT: Traffic should not be limited on the LAN interface as its going in the LAN interface and OUT the LAN interface, correct? It shouldnt match any of my rules as they are all set with WAN in and LAN out or vice versa. ~~Im wondering how to get around this. Would it be possible to have the default rules and then assign a new queue which has 1gbps (possibly make it parent), assign all traffic originating from lan subnet destined to lan subnet to a queue that has 1gbps bandwidth? so: LANTOTAL (1gbps) parent  – qwanRoot 218kbps      -- children WANTOTAL (1gbps) parent  -- qlanRoot 1306kbps      -- children~~

i got something similar. Whatever bandwidth queue you created, is too high and exceeds the sum of all the other queues, bring your queue down or adjust the other queue(s) to compensate for this new one.

I've read the qos sticky and it does mention borrowing. Does anyone know if the default traffic wizard enables borrowing?

Dunno what to tell ya. I spent a good part of the night figuring this out. What I have down on paper looks like it would work, however actually implimenting it in PFSense seems trivial. They made it more complicated than it should be.

Your right! There is no other way unless there is a 3rd party plugin that gives you that option. The only thing you can do from the Status>DHCP screen is set a static DHCP mapping or WOL Mapping. You will have to manually set the rule in the MAC filtering.

@nykollas: And for the LAN how can I make sure that they are not using manual IP addresses ? I am thinking to use static IP address for each user and create an aliass from their range, and have the firewall to pass the traffic with the bandwidth limit rules. And block everything else in case they are changing manualy their IPs. I hate those people also  :D you can use ipguard http://ipguard.deep.perm.ru/ By pkg_add -r ipguard it can bind ip address to mac and prevent (as much as it can) others from changing there ip's by adding mac-ip pair in file like this 00:11:22:33:44:55 192.168.1.2 00:44:55:66:77:88 192.168.1.6 actually idon't know why it hasn't been added to pfsense packages. if users can take any ip they want ,then all firewall configuration and traffic shaping is in vain.

if u set wan to opt and opt to wan then that will work only till a restart. try switching to 2.0

i too suffer from this issue, and i thought its just me… with aggressive apps, drops could sometimes reach 5 digits.. it doesnt matter if qlimit is specified or not, but it happens either way. would be good to hear feedback from a dev

a bit old thread, but the same question… so, dreamslacker, you say that this example u wrote would help in our case (yes i've got the same problem as sofakng)? thanks

I don't think it will be considered that way - I ran into the same issue with VOIP packets, where because they had ToS of low delay they got put on the ACK queue.

@danswartz: I thought the answered the same question somewhere else on this forum, but here goes: I am pretty sure that the shaper cannot prioritize stuff once it is inside the tunnel. Technically though it should be prioritizing it AT the tunnel, like a WAN connection does right? Inside the tunnel is not important so long as it does it before it hits it. Again just as the traffic shaper does this with a WAN connection to the Internet, it has no control of what the data does beyond the interface, i.e. out to the Internet and to the destination, but only up to that point. I can't see why it isn't doing this now, unless there is something that IPsec-PPTP-OpenVPN(?) prevents it? That's why I asked originally.