Be careful when classifying the ports for Steam.  The gameplay uses UDP ports, the downloader uses TCP. You are likely to want to prioritize the gameplay and not the patching/ download ports, so don't match both TCP and UDP when setting up your rules. I've used pfSense in a Cybercafe production environment before due to the traffic shaping capabilities (keep gamers infinitely happy while other users are happily streaming videos and chatting with loved ones back home) so it definitely would do what you need. The main problem you are going to face is the actual rules configuration and the queues setup.

@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