Last Updated on August 8, 2022 by Thiago Crepaldi
As bufferbloat.net defines it, “Bufferbloat is the undesirable latency that comes from a router or other network equipment buffering too much data. It is a huge drag on Internet performance created, ironically, by previous attempts to make it work better. The one-sentence summary is “Bloated buffers lead to network-crippling latency spikes. The bad news is that bufferbloat is everywhere, in more devices and programs than you can shake a stick at. The good news is, bufferbloat is now, after 4 years of research, development and deployment, relatively easy to fix”.
Indeed, this is easily fixed on pfSense and I will show you how in the next sections.
Performing a health check on your Internet
Before jumping to the solution, let’s first make sure you are suffering from it. Make sure nobody is using internet (to don’t interfere with the testing). Visit http://www.dslreports.com/speedtest and click on your connection type (e.g. Gigabit/Fiber, Cable, DSL, Satellite, etc). The speed test/buffer bloat tests will start and should finish in a minute. Once it completes, if you get A or A+ grades on the BufflerBloat metric, you are probably good. If you get anything less, I recommend following the next steps to fix it. Take note of both download and upload speeds from this test as we will need it later.
Fixing the bloat
Now that you diagnosed the BufferBloat, let’s fix it. We will configure both download and upload bloats individually.
Fixing Download speed first
On your pfSense, go to Firewall >> Traffic Shaper >> Limiters, click on New limiter button and do as follows:
- Limiters
- Enable: checked
- Name: WAN_Down
- Bandwidth: Set this to 95% of download speed from your test. If the reported speed was higher than what your pay for, take 95% of the contracted download speed to be safe. Pay attention to the proper Bw type and set Schedule to None
- Mask: None
- Description: Fix bufferbloat for download
- Queue
- Queue Management Algorithm: CoDel
- Scheduler: FQ_CODEL
- Queue length: 1000
- ECN: checked
- Advanced
- Leave everything at their default values
Click Save to create the limiter. Now we need to add a queue to that limiter before applying this setting. On the same page, click on “WAN_Down” on the left table and then click on Add new queue button at the bottom of the page and do as follows:
- Limiters
- Enable: checked
- Name: WAN_Down_Queue
- Mask: None
- Description: Fix bufferbloat for download
- Queue
- Queue Management Algorithm: CoDel
- Queue length: empty
- ECN: checked
- Advanced
- Leave everything at their default values
Click Save and Apply changes to complete the process for the download bloat.
Fixing Upload speed
Repeat the steps above, but for upload this time. Go to Firewall >> Traffic Shaper >> Limiters, click on New limiter button and do as follows:
- Limiters
- Enable: checked
- Name: WAN_Up
- Bandwidth: Set this to 95% of upload speed from your test. If the reported speed was higher than what your pay for, take 95% of the contracted upload speed to be safe. Pay attention to the proper Bw type and set Schedule to None
- Mask: None
- Description: Fix bufferbloat for upload
- Queue
- Queue Management Algorithm: CoDel
- Scheduler: FQ_CODEL
- Queue length: 1000
- ECN: checked
- Advanced
- Leave everything at their default values
Click Save to create the limiter. Now we need to add a queue to that limiter before applying this setting. On the same page, click on “WAN_Up” on the left table and then click on Add new queue button at the bottom of the page and do as follows:
- Limiters
- Enable: checked
- Name: WAN_Up_Queue
- Mask: None
- Description: Fix bufferbloat for upload
- Queue
- Queue Management Algorithm: CoDel
- Queue length: empty
- ECN: checked
- Advanced
- Leave everything at their default values
Click Save and Apply changes to complete the process for the upload bloat.
Create firewall rule to deploy BufferBloat fix
Now that we have the settings fro BufferBloat in place, we need to deploy them by creating a floating firewall rule. Go to Firewall >> Rules >> Floating and click on Add to add a rule at the top of all others:
- Edit Firewall Rule
- Action: Pass
- Disabled: unchecked
- Quick: checked
- Interface: WAN
- Direction: Out
- Address family: IPv4
- Protocol: Any
- Source
- Any
- Destination
- Any
- Extra Options
- Leave everything on their default values
- Advanced
- Gateway: Selection your WAN gateway, probably something like WAN_DHCP.
- DO NOT SELECT ‘Default’
- In / Out pipe:
- Select WAN_Up_Queue for In (right dropdown)
- Select WAN_Down_Queue for Out (left dropdown) and;
- Gateway: Selection your WAN gateway, probably something like WAN_DHCP.
Click Save and Apply changes to put deploy the firewall rules
Verifying your bloat is gone
As before, make sure nobody is using your internet (to don’t interfere with the testing), visit http://www.dslreports.com/speedtest and click on your connection type (e.g. Gigabit/Fiber, Cable, DSL, Satellite, etc). If you did everything right, you should get a grade A or A+ for your BufferBloat!
That is it, folks. Happy streaming/gaming!
are you also using the traffic shaper wizards or do not use it and only use the Limiters?
I create a new Limiter manually, without the help of the Wizard. In fact, that is usually my choice as it is more precise as to understand what is being configured under the hood. Wizards can be too magic sometimes 😛
What if you use a commercial VPN? I’ve read in another guide that you shouldn’t use a floating rule in that case. It didn’t really clear up what else to use.
Thoughts?
Do you happen to have the original post? I do have a commercial VPN on my lab and everything is working fine with the bloat fix
Great fix – great description, Thiago – thank you!
Yet I stumbled upon an issue: on the very last step ‘Defining a floating firewall rule’ you specify an ‘out’ direction but when it comes to selecting the queues, pfSense tells us:
‘In / Out pipe
Choose the Out queue/Virtual interface only if In is also selected. The Out selection is applied to traffic leaving the interface where the rule is created, the In selection is applied to traffic coming into the chosen interface.
If creating a floating rule, if the direction is In then the same rules apply, if the direction is *Out* the selections are *reversed,* Out is for incoming and In is for outgoing.’
The original setup had left me with a download rate of 5 Mbit/s – when I changed the direction to ‘In’ everything was fine – but I had to choose 70% of available download bandwith for best results.
Cheers, Jan
I think your “In/Out Pipe” settings are reversed. Per the description for that setting in pfsense:
“If creating a floating rule, if the direction is In then the same rules apply, if the direction is Out the selections are reversed, Out is for incoming and In is for outgoing.”
The created rule uses the “Out” direction. It’s easily recognized when your download speed is clipped to your upload max 🙂
Hi, are you sure the down queue in and up queue out in the firewall rule is right?
I just tested your tutorial and I had to switch it else my download rate would go way down.
Also another tutorial on the net https://lawrencesystems.com/how-to-solve-pfsense-bufferbloat-with-a-codelq-fq_codel-limiter-in-2-4-4/ switches the up queue in the in side and the down queue in the out side.
Thanks for your instructions! A couple of notes that may help others:
1) pfSense 2.5.2 is requiring me to provide a bandwidth specification for queue creation. I wasn’t sure what to put there. Suggestions?
2) After applying the changes I found that my download speed (normally much larger then upload) dropped to match my upload speed. In the firewall rule I then reversed the queue order from what you wrote, so it’s like this:
In / Out pipe:
Select WAN_Up_Queue for In (left dropdown) and;
Select WAN_Down_Queue for Out (right dropdown)
This resolved the bandwidth hit.
Hey S, 1) for the queue creation, there is no bandwidht, but a bug on the pfSense. You have to click on “WAN_Down” on the left menu before clicking on the “Add new queue”. Then the correct dialog will appear 2) Yes, you are right. I have reversed the In / Out setting. I have a symmetric fiber and didn’t catch this earlier 🙂
Following up in case it helps someone:
(1) Turned out to be a GUI bug in pfSense. The key to avoid this is: after creating a limiter and clicking Save, do not immediately click Add New Queue. First, *click the limiter you just made in the upper left corner just above the “+ New Limiter” button*, then scroll to the bottom and click Add New Queue.
If you do this correctly, after it’s done the limiters should have the queues nested under them, like:
+WAN_Down
|—WAN_Down_Queue
+WAN_Up
|—WAN_Up_Queue
I figured it out by following the directions here (slides 5-11): https://www.slideshare.net/NetgateUSA/pfsense-244-short-topic-miscellany-pfsense-hangout-august-2018
One thing that needs to be fixed is in the last section, entitled “Create firewall rule to deploy BufferBloat fix”, under Edit Firewall Rule > “Direction: out” needs to be changed to” Direction: in”. Per, the instructions inside of the pfsense: “If creating a floating rule, if the direction is In then the same rules apply, if the direction is Out the selections are reversed, Out is for incoming and In is for outgoing.” (OR use the left dropdown for WAN_Up_Queue and the right for WAN_Down_Queue)
My connection is async – 300Mbps up / 50Mbps down. When I used “Direction: out” my download speed suddenly became limited to 95% of 50Mbps for downloads.
Other than that, great article. I truly appreciate the knowledge share.
Thank you all for reporting my typo on the In / Out setting for the queue creation. My WAN connection is a symmetric fiber and I never noticed the bad config
I have been using m0n0wall, Opensense, and pfSense from day one of each. With pfSense I use both CE and Plus depending on need. There are two problems with this so called fix, that could not work (I tried to make sure). 1; it will never do any thing if your bandwidth never reaches what you pay for, so the triggers are never activated. 2; it WILL NOT WORK WITH CACHE, so if you run web cache and/or web filters to speed things up, the cache is going to fight with the limiter from within the network. I think you should tell people about these downfalls.