Feature #15813
closed
Include alternative TCP stack
0%
Description
After extensive research I found out why a Netgate XG1537 is unable to saturate a fiber WAN link. It turns out this is due to the old and much less performant TCP Stack of PfSense+ 24.03 compared to freeBSD 15. I purchased a Netgate XG1537 explicitly for it's hardware performance and software support of HAProxy and OpenVPN. It it used as edge router/firewall and was supposed to provide a reverse proxy service for two http(s) servers behind it.
The issue with the TCP stack is that it does not handle TCP packet reordering very well. So it incorrectly detects 2-3% packet los, fast retransmits a lot of packets and reduces throughput. This limits TCP upload to about 2-8MBit/s on a 400+MBit/s uplink (see screenshot). The solution to this problem is the Recent Acknowledgement algorithm for TCP (RACK TCP), which is the default in current Linux kernels and can also be activated in stock freeBSD 14+. Unfortunately the PfSense kernel does not come with alternative TCP stacks but only with the default one.
I ask you to include the RACK TCP Stack from stock freeBSD in the next PfSense release. Without it, TCP is pretty much unusable for any production service. Sure, PfSense is primarily a firewall, but your official documentation indicates support for HAProxy, OpenVPN and other services which (may) use TCP. These are all obsolete and cannot be used reliably. Without the support for high performance TCP (honestly I can't believe that's actually an issue in 2024), users will have to switch to another Operating System, which would be a shame. I for one would much prefer to stay with your software as it is pretty solid and reliable otherwise. But in my case, RHEL (and probably any other current Linux) gets solid 400-500MBit/s upload with ZERO retransmissions after establishing the connection out of the WAN (see screenshot).
With faster network connections the problem of TCP packet reordering will only occur more frequently - making the need for RACK TCP more urgent.
Files
| iperf Test on RHEL.png (2.36 MB) iperf Test on RHEL.png | iperf test on RHEL for comparison (routed through pfSense) | ||
| iperf Test on PfSense Anonymous.png (2.06 MB) iperf Test on PfSense Anonymous.png | iperf test on PfSense |
Related issues
Updated by Marcos M about 2 months ago
It's too late for 24.11, though we can look into it after this release.
Updated by Andreas Dekiert about 2 months ago
Ok, the release after that would still help a lot.
Updated by Marcos M 19 days ago
- Tracker changed from Bug to Feature
- Subject changed from TCP send performance break in in case of packet reordering to Include optional kernel modules
- Status changed from New to Duplicate
- Priority changed from Normal to Very Low
- Affected Version deleted (
All) - Affected Architecture deleted (
All)
Updated by Marcos M 19 days ago
- Is duplicate of Feature #12521: Add the BBR2, QUIC, RACK Congestion Control (CC) protocols added
Updated by Andreas Dekiert 17 days ago
So, what is the way forward? You marked this issue as a duplicate of another one which has not been addressed in more than three (!) years. The other issue also covers more than this one.
I do not even ask you to support the alternative RACK TCP Stack in the pfSense UI or to enable it by default. I merely ask to not remove it from the freeBSD kernel when compiling the pfSense+ kernel. It is included by default since freeBSD 14.1, yet it is unavailable in pfSense+ although it is based on freeBSD 15.
As it stands Netgate's Rack Appliances cannot be used for all of the advertised features in a professional environment.