@SeventhSon: Nice one, using google drive myself, don't have very big files in there, so haven't noticed this behavior. Until recently I hadn't noticed it either. It only showed up when I dumped a couple of isos into it. I'm hoping they implement at least deltas, if not throttling. @SeventhSon: One thing I would do, is move it to a floating rule, instead of LAN. I did make the rule floating but it's not clear in that post; I'll add a note to clarify. I have the floating rule assigned to LAN since I didn't care about queuing incoming on those connections (I'm assuming those are the upload-only connections judging by the domains). I did consider making a different rule (or altering this one) to handle incoming downloads, but I haven't had a chance to sort out which domains/IPs I need to filter against and test that yet.

I am far from being an expert and offer this only as something to try since nobody else replied. I have a couple IP phones and have DHCP give them a static IP based on their MAC address so they never change. Then I created an alias called VOIP-Phones that contain their IP addresses. In screenshot_4 enter the alias in the area you left blank. Regarding bandwidth. G.729 uses about 20-30k/Call. G.711 uses about 70-80k/call. Devices tend to default to G.711. Let me know if that helps.

I am using traffic shaper to limit bandwidth. I have overall bandwidth and specific ones for p2p traffic. No worries though, there is a limiter also.

This information is taken from this link…Please reference for further information: http://calomel.org/pf_hfsc.html realtime: the amount of bandwidth that is guaranteed to the queue no matter what any other queue needs. Realtime can be set from 0% to 80% of total connection bandwidth. Lets say you want to make sure that your web server gets 25KB/sec of bandwidth no matter what. Setting the realtime value will give the web server queue the bandwidth it needs even if other queues want to share its bandwidth. upperlimit: the amount of bandwidth the queue can never exceed. For example, say you want to setup a new mail server and you want to make sure that the server never takes up more than 50% of your available bandwidth. Or lets say you have a p2p user you need the limit. Using the upperlimit value will keep them from abusing the connection. linkshare (m2): this value has the exact same use as "bandwidth" above. If you decide to use both "bandwidth" and "linkshare" in the same rule, pf (OpenBSD) will override the bandwidth directive and use "linkshare m2". This may cause more confusion than it is worth especially if you have two different settings in each. For this reason we are not going to use linkshare in our rules. The only reason you may want to use linkshare instead of bandwidth is if you want to enable a nonlinear service curve. nonlinear service curve (NLSC or just SC): The directives realtime, upperlimit and linkshare can all take advantage of a NLSC. In our example below we will use this option on our "web" queue. The format for service curve specifications is (m1, d, m2). m2 controls the bandwidth assigned to the queue. m1 and d are optional and can be used to control the initial bandwidth assignment. For the first d milliseconds the queue gets the bandwidth given as m1, after wards the value given in m2.

it works : i configure "services -> proxy server -> traffic mgmt -> maximum download size" i set 300 kilobytes, i tray to downlod a file from a web site that have 417kB and the download is blocked  :D

When there’s no any free mbuf clusters available FreeBSD enters the zonelimit state and stops to answer to any network requests. You can see it as the zoneli state in the output of the top command. The state of used mbuf clusters can be checked with 'netstat -m' You can increase quantity of the mbufs clusters through the kern.ipc.nmbclusters parameter: sysctl kern.ipc.nmbclusters=65536

Many thanks for the help, time for me to play around a little.  If anyone does know where there is a write up on the V2 shaper it would be very helpful!

dreamslacker: Thank you for your great reply.  I have the new router in place and am finalizing my plan to shape the bandwidth properly but I'd like to run some things by you, and others, to create a bit of a brain-trust on this before I actually try it. I'm thinking of creating limiters as follows: VPNInLimiter -> 10 Mbps -> Mask:None -> Delay:0 -> LossRate:0 -> Queue:empty -> Bucket:empty VPNOutLimiter -> "all the same settings as above" GeneralInLimiter -> 5 Mbps -> Mask:None -> Delay:0 -> LossRate:0 -> Queue:empty -> Bucket:empty GeneralOutLimiter "all the same as settings above" So basically, I'd be providing the VPN a dedicated 10 Mbps and everything else would go to the GeneralXLimiter pipes.  I'd would then like to add standard shaping to the GeneralXLimiter pipes to ensure QoS is working properly within that 5 Mbps. I think what dreamslacker said would work by using the alias and firewall rules to assign the VPNs to the specified limiters.  Any thoughts out there on this?

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?