I haven't test it yet, but I think it's okay and I hope it would help some other people. It was my first time with OpenBSD and pf so maybe there are some errors… Define the interface aliases wan_if="em0" # External WAN-facing interface lan_if="em1" # Internal LAN-facing interface Enable ALTQ on the external interface, assign the root queue and ultimate bandwidth limit Using CBQ scheduler et creating the queue altq on $wan_if cbq bandwidth 100Mb queue { A_out, B_out, C_out, D_out } Define interface queue with the bandwidht, scheduler and borrow option queue A_out bandwidth 65Mb cbq (default borrow red) queue B_out bandwidth 15Mb cbq (borrow red) queue B_out bandwidth 15Mb cbq (borrow red) queue D_out bandwidth 5Mb cbq (borrow red) Same on LAN altq on $lan_if cbq bandwidth 100Mb queue { A_in, B_in, C_in, D_in } queue A_in bandwidth 65Mb cbq (default borrow red) queue B_in bandwidth 15Mb cbq (borrow red) queue C_in bandwidth 15Mb cbq (borrow red) queue D_in bandwidth 5Mb cbq (borrow red) IP adresses A_IP = "192.168.1.1" B_IP = "192.168.1.2" C_IP = "192.168.1.3" D_IP = "192.168.1.4" and the queue on interface pass in on $wan_if all pass out on $wan_if to $A_IP queue A_out pass out on $wan_if to $B_IP queue B_out pass out on $wan_if to $C_IP queue C_out pass out on $wan_if to $D_IP queue D_out pass in on $lan_if all pass out on $lan_if to $A_IP queue A_in pass out on $lan_if to $B_IP queue B_in pass out on $lan_if to $C_IP queue C_in pass out on $lan_if to $D_IP queue D_in

The closest thing I have to a NAT rule is a 1:1 NAT forward using an WAN alias IP address, and an associated WAN rule to allows the port and address.  As I understand it, the floating rules are executed first, tagging the queue then the usual rules for the interface the packet is entering on run, stopping on a match.  Is this correct? Is it possible that the direction (source and destination) of floating rules are interpreted differently for ports defined as LAN vs WAN? Also, do firewall states effect floating rules, possibly adding a rule for the other direction/interface through the state table? The Definitive Guide to pfSense book is a great resource, but there have been a lot of changes (traffic shaping to be sure) that need updating in the book. Will an update to the book be available any time soon to cover the new traffic shaping in 2.0? Ethan…

Actually, when I was looking at it earlier, I did notice that shaper was working in one direction only. I wonder if the problem is because of LAN not having an IP. That should not really matter though.

One more weird observation:  After I apply any change at all to any of the traffic shaper queues, I get not packet loss on my UDP stream queue for about a minute, after which a 2% packet drop kicks in. Very strange! Ethan…

If you don't have quick option set, it would be last matching rule.

Never mind. Through further testing, I discovered that this issue only occurred when doing SMB file copies from a Win7 machine to a Samba server.  The issue was caused by the settings of SO_SNDBUF and SO_RCVBUF in Samba.  The recommended settings of 8192 cause a significant performance hit when transferring files over a VPN.  Changing the settings to 65536 cured the problem completely. Kevin

One problem I see is all your devices are wireless, even if pfsense puts traffic in lower priority its already went over your shared wireless network. Not sure how well that would work. Wouldn't it be easier to just set your p2p (why anyone would do that over wireless in the first place?) to throttle down or just pause at night.  Pretty much any p2p client I have ever looked at has a scheduler built into it, so say after 5pm pause, then resume after bedtime. edit:  So here is part of the problem of running p2p over wireless.  Wireless is SHARED, only really 1 device talking at a time.  So with p2p there is traffic even when your not downloading or uploading anything.  Once you have joined a swarm or two, your going to be seeing traffic to your ip and port be it your actively running your p2p client even.  Now have you forwarded your ports on your firewall for p2p? So that unsolicited traffic gets sent to your p2p box right.  Well that is all traffic eating away at your shared wireless bandwidth.  Now it might not be a huge amount, but it is still traffic taking up "shared" bandwidth so I turned on logging for just a couple of seconds on my p2p forward on 43212 pass Jul 7 08:07:53 WAN 77.31.49.71:30700 192.168.1.8:42312 UDP pass Jul 7 08:07:43 WAN 87.16.223.199:63782 192.168.1.8:42312 UDP pass Jul 7 08:07:41 WAN 109.254.1.15:64355 192.168.1.8:42312 UDP pass Jul 7 08:07:41 WAN 201.76.108.87:33911 192.168.1.8:42312 UDP pass Jul 7 08:07:40 WAN 176.32.4.140:36355 192.168.1.8:42312 UDP pass Jul 7 08:07:37 WAN 193.151.106.142:1027 192.168.1.8:42312 UDP pass Jul 7 08:07:33 WAN 78.34.146.138:55016 192.168.1.8:42312 UDP pass Jul 7 08:07:33 WAN 95.96.26.78:27581 192.168.1.8:42312 UDP pass Jul 7 08:07:29 WAN 85.243.118.210:57270 192.168.1.8:42312 UDP pass Jul 7 08:07:29 WAN 77.85.164.13:23640 192.168.1.8:42312 UDP pass Jul 7 08:07:21 WAN 128.71.69.106:63151 192.168.1.8:42312 TCP:S pass Jul 7 08:07:19 WAN 41.99.20.19:13383 192.168.1.8:42312 UDP Why not run your p2p box on a wire, so that traffic does not eat up your shared bandwidth..  And then sure put it in a penalty box so it does not eat up your inet connection.  You have 10 that you mention devices all sharing "shared" bandwidth.  Are your devices all N, the Cells for example?  If not - they are sure not helping either - its shared bandwidth, putting slower speed devices ie B on G, B/G on N only slow it down. You have some box moving packets at G speeds - since its shared, you can not at same time have data moving at full N speeds, N is going to see something slower than if it was only N devices. So I wonder is it your isp connection that is saturated, or is more just wireless bandwidth issue?

any help would be much appreciated.

not to push you away from pfsense, i only mention this because its floating around in my head as well.  you might look at smoothwall.  it looks to be a more newb friendly interface.  i'm struggling with wrapping my mind around some of the technical stuff in pfsense and might demo smoothie myself.  i'm gonna give pfsense a shot first though and hopefully learn a little on the way.  just a though.

I have a somewhat similar problem.. although not at that high speeds. My isp gives me 50/50 atm, and disabling the limiter i get 49/46 (atleast on the isp bandwidth meter). I have set the limiter to 48/48, but when i do that, i get 44-46/36-38. Ofc the download limit should be around that i guess.. but why almost 10 mbps less on the upload with the limiter running? Would the purpose of the limiter be kinda waste if i put the speeds more than i actually have? (i would think so.. but just asking) Also tested this with 2.0.1 and 2.1 beta. Oh, and im running PriQ setup, as i find this the easiest to manage. C

I read the same articles, dont really get it fully.  To many ifs and buts on the tutorials I have seen I want a lets say kind of how-to.. know what I mean?

@dhatz: Does the remote host support ECN ? Read more http://en.wikipedia.org/wiki/Explicit_Congestion_Notification I contacted my ISP (Cox Business) and they indicated that ECN is only available on their fiber lines (not cable).  However I've not taken any measures to enabled ECN on my Windows 2008 R2 server which is the one doing the downloading.  Would there be any benefit to enabling on the WS2008R2 box via this command (from Wiki you linked me to): netsh interface tcp set global ecncapability=enabled Thanks again. EDIT 6/16/12 - appears once I reduced the total # of NNTP connections to my provider from 20 to 7, I am still able to achieve full download speed without queue drops.

Some questions: 1.) is the qLink (default) queue necessary for the LAN interface?  It's auto setup by the traffic shaping wizard. 2.) are "drops" in a queue something that should be expected?  should they be ignored?  or have you found there rarely to be "drops" listed beneath your status > queues?  On large file downloads at high speeds I see 5000, 7000+ although the resulting file is fine.