Easy general purpose traffic shaper config also suitable for gaming
After struggling to get this to work for some time I thought I would share a simple, good "general purpose" traffic shaper configuration that is also suitable for keeping ping times low and steady for gaming when your connection is being shared by people streaming video, downloading etc...
Some very complex configurations are possible with PFSense where different types of traffic are classified by firewall rules and put into different queues based on port numbers etc, and the wizard can generate these, however this can get very complex very quickly and to be honest, just isn't necessary most of the time.
Most of the benefit of traffic shaping from the point of view of gaming can be realised by doing two simple things:
Avoiding buffer bloat at your ISP by rate limiting your upstream and downstream traffic to about 90% of your peak Internet connection throughput. (and also enabling Codel on the upstream, see later)
Using some kind of stochastic fair queuing algorithm where different TCP/IP flows are automatically divided up into hashed queues and then serviced in a round robin fashion so that no one connection can saturate the available bandwidth at the expense of others. HFSC includes such an algorithm.
Even though applications that open lots of parallel connections can theoretically get more than their fair share I haven't found this to be a problem in practice.
First thing you'll need is an Alias which defines private IP addresses which we'll use in firewall rules for tagging later:
Here is the queue structure I've defined, based partly on what the wizard generates, partly on a couple of tutorials online and a lot of experimentation and testing: (ignore VLAN2)
Lets look at each section.
In WAN just set the interface speed of your ethernet interface, here 1Gbps:
In qInternet_Up set your ISP upstream bandwidth in Bandwidth and both m2 boxes. This figure may need tuning later.
Configure qACK_WAN_Up as shown:
Configure qDefault_WAN_Up as shown:
Configure LAN as shown, setting the bandwidth to that of your network interface, usually 1Gbps:
Configure qLink_LAN_Local as shown:
Configure qInternet_Down as shown, substituting your ISP downstream bandwidth in the three locations where I have 140Mbps, these may need tweaking later:
Configure qACK_LAN_Internet_Down as shown:
Configure qDefault_LAN_Internet_Down as shown:
On the LAN side we have one queue for non-Internet traffic which is coming directly from the router itself (for example a service running on the router) or routed from another VLAN etc, and separate queues for traffic originating from the internet. This means the downstream speed for Internet traffic can be throttled without throttling everything coming out of the LAN interface.
Next we will add two floating rules:
First rule one: (settings not shown are defaults)
Rule two: (settings not shown are defaults)
Two rules are needed here, one to match traffic initiated from the LAN (which is outgoing traffic from the point of view of a stateful firewall) and the other rule is needed for traffic initiated from the WAN side - this could only ever happen if you use port forwards, but if you do, you need both rules otherwise traffic coming in your port forwards would not be classified and would not be rate limited.
In the next post I'll talk about how to tune the bandwidth settings and test it to make sure it's actually working...
Next some tuning and testing.
First off, to compare results between traffic shaping being enabled or disabled you only need to uncheck one box for WAN and one for LAN to go back to no traffic shaping, without losing all your work to configure everything.
This makes it easy to do quick A/B testing to see what results you're getting.
To disable upstream traffic shaping simply untick Enable/Disable on the top level WAN entry:
Likewise to disable downstream traffic shaping do the same on the top level LAN entry:
The first thing to do for tuning/testing is to turn traffic shaping off as above and do some speed testing of your actual internet speed.
Speedtest.net works fairly well although I would recommend the desktop app version rather than running it in a browser, and you might have to try several speedtest.net servers until you find one that gives accurate results for your ISP.
Turn traffic shaping back on and change the upstream and downstream values to about half your measured speed so that it will make an obvious difference, then run a speedtest to confirm both upstream and downstream rates have dropped to near what you've set. (probably a bit lower)
While the test is running watch the Status -> Queues page to make sure that traffic is being categorised properly. (Do this with the rest of your network as idle as possible)
The downstream portion of the test should look like:
With the main downstream component of the traffic registering against qDefault_LAN_Internet_Down (and it's parent) and the upstream traffic going into qACK_WAN_Up which is a separate upstream queue for TCP ACKs.
During the upstream portion of the test it should look like this:
Upstream traffic should be going into qDefault_Wan_Up and it's parent, while downstream will show in qLink_LAN_Local. (Don't worry about that - yes the ACK's should really go into qACK_LAN_Internet_Down but I can't seem to get that to work and I'm not sure why - and in practice it doesn't matter. Perhaps someone can point out my mistake...)
As a further sanity check you could try doing a speedtest FROM the router itself, to make sure this is not classified as Internet traffic and runs at full speed. The easiest way to do this is to install and run the IPerf3 server on PFSense and connect to it from a PC on the LAN. A downstream speed test (for example iperf3 -c 192.168.0.1 -P 5 -R) should give a result that looks similar to this with all the traffic being classified under qLink_LAN_Local,:
This ensures non Internet traffic coming out the LAN interface of the router is not going to be throttled and competing for bandwidth with Internet traffic. Ignore the actual speed reported on Status->Queues, this doesn't seem to be accurate. Just go by the result reported by Iperf.
Now experiment with the upstream and downstream values in the queues until your speed tests are about 90% of what they are without traffic shaping in both directions. You might need to temporarily disable traffic from other devices in your house to get accurate measurements. Remember to change all three values on each page where applicable.
It's also not unusual that you might actually have to set the bandwidth settings to equal or slightly higher than your ISP's claimed bandwidth - this is because the speedtest results exclude packet overheads, showing payload performance, while the figures you're entering into the traffic shaper include TCP/IP packet overheads.
In my case my downstream bandwidth measured in speedtest is 137Mbps without shaping, but I actually have to use a figure of 140Mbps in the traffic shaper to drop it down to 123Mbps measured. Likewise my upstream bandwidth is 20Mbps but I have to set 20Mbps in traffic shaping settings to drop the measured speed to 18Mbps.
It's important that you do actually adjust these values to limit your connection speed to no more than 90% of what is actually available - this ensures that all the queuing is performed at your PFSense router and not at your ISP's router. If you set the speed too high so the throttling point is your ISP's router again you won't gain any benefit in latency control and fair queuing will also not work properly.
The next thing you'll want to do is see what effect the traffic shaping has on your ping times.
So disable traffic shaping again and start a continuous ping to a server as close as possible to you within your own ISP. Your ISP's main web server, SMTP servers, DNS servers are probably good choices. Make sure it's showing a low and steady ping.
Now watch the ping while you do a speed test. In my case my idle ping is about 20ms and goes up to about 40-50ms during the downstream test and spikes to about 100-150ms at the start of the upstream test, settling to about 50ms.
Turn traffic shaping back on and re-run the test. You should find that the increase in ping time is very modest - maybe 5-10ms at most and that it hardly varies between your connection being idle and being maxed out. If you still see it spiking up a bit you might need to drop to say 85% of your normal bandwidth.
In practice, I've been playing the Quake 1 remaster online while there are multiple other devices in the house playing streaming services with no noticeable change in gaming experience and almost no change in in-game reported pings, and this is all without any rules or queues specifically targeting games.
Addendum: Codel really does work for upstream, which is why I have it enabled in my config. With Codel my ping time rises from 20 to 25ms during the upstream test, without it (but upstream throttling still active) it rises to 50ms!