SoftEther server throughput
Posted: Fri Apr 24, 2026 6:45 am
Hello,
we are running SoftEther VPN Server 4.44.9807 in VMware virtual machine with Linux Debian 13. We have a single virtual hub named VPN. This hub is bridged directly into eth1 interface. eth1 interface is in dedicated VLAN and this VLAN is routed by our core switch/router, so not by server itself. Our majority clients are Windows clients with SSTP. And because of an extensive CPU usage and high load of virtual machine we limited downlink/uplink in virtual hub admin options to 24/24 Mbps per client. It works quite good.
But now, thanks to infrastructure innovation, we have a spare old hardware server with Intel Xeon CPUs E5-2680 v2 @ 2.80GHz, 40 cores total, 250 GB DDR3 RAM. And I'm testing the throughput on it. Network setting on server is following:
- 2x 10 Gb trunk interfaces into the core router
- above it 1x bond0 interface with fast LACP
- above it vlan1 with public IP vlan.example.com and vlan2 in dedicated VLAN in our network
The 1st attempt was the same setup as with VMware virtual machine, but without bitrate limits. VPN hub bridged directly into vlan2@bond0 interface. It worked but throughput of SSTP was bad. Upload ~30 Mbps, download ~4 Mbps. So I googled and found https://serverfault.com/questions/83264 ... ad-is-high
The 2nd attempt is much better. VPN hub is bridged into tap0 interface and I've created bridge br0 with vlan2@bond0 + tap0. The throughput of SSTP shot up immediately to 50/50 Mbps. When I use SoftEther VPN Client, I can hit throughput 180/180 Mbps (when connected via 200/200 Mbps provider).
And I have a so many questions:
a) Why is the download so poor when the virtual hub is bridged directly into vlan2@bond0 interface? Are there any kernel/interface options which can improve it?
b) Are there generally any kernel/interface/server parameters that are recommended to be tuned for better performance?
c) Is there a really ~triple SSTP protocol overload which causes such lower throughput? Or it's due to the old server CPU?
Thank you very much for reading this far :)
we are running SoftEther VPN Server 4.44.9807 in VMware virtual machine with Linux Debian 13. We have a single virtual hub named VPN. This hub is bridged directly into eth1 interface. eth1 interface is in dedicated VLAN and this VLAN is routed by our core switch/router, so not by server itself. Our majority clients are Windows clients with SSTP. And because of an extensive CPU usage and high load of virtual machine we limited downlink/uplink in virtual hub admin options to 24/24 Mbps per client. It works quite good.
But now, thanks to infrastructure innovation, we have a spare old hardware server with Intel Xeon CPUs E5-2680 v2 @ 2.80GHz, 40 cores total, 250 GB DDR3 RAM. And I'm testing the throughput on it. Network setting on server is following:
- 2x 10 Gb trunk interfaces into the core router
- above it 1x bond0 interface with fast LACP
- above it vlan1 with public IP vlan.example.com and vlan2 in dedicated VLAN in our network
The 1st attempt was the same setup as with VMware virtual machine, but without bitrate limits. VPN hub bridged directly into vlan2@bond0 interface. It worked but throughput of SSTP was bad. Upload ~30 Mbps, download ~4 Mbps. So I googled and found https://serverfault.com/questions/83264 ... ad-is-high
The 2nd attempt is much better. VPN hub is bridged into tap0 interface and I've created bridge br0 with vlan2@bond0 + tap0. The throughput of SSTP shot up immediately to 50/50 Mbps. When I use SoftEther VPN Client, I can hit throughput 180/180 Mbps (when connected via 200/200 Mbps provider).
And I have a so many questions:
a) Why is the download so poor when the virtual hub is bridged directly into vlan2@bond0 interface? Are there any kernel/interface options which can improve it?
b) Are there generally any kernel/interface/server parameters that are recommended to be tuned for better performance?
c) Is there a really ~triple SSTP protocol overload which causes such lower throughput? Or it's due to the old server CPU?
Thank you very much for reading this far :)