OpenVPN slow throughput

[proxykid]

I'm currently getting very low throughput on OpenVPN. ISP connection is 200/200 however over OpenVPN it goes down to 25/25 mbps aprox.

According to a lot of research online this GW server+CPU should be more than enough to achieve at least 100 mbps, but I would like to get as near as possible to the 200 mbps available bandwidth, if not possible well at least get closer to 100.

Server specs are:
OPNsense 19.7.8-amd64
FreeBSD 11.2-RELEASE-p16-HBSD
OpenSSL 1.0.2t 10 Sep 2019
CPU: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
RAM: 8GB
SSD: 256GB Samsung EVO


OpenVPN settings:
Encryption: AES-128-CBC
No Hardware Crypt acceleration
No compression

Custom server settings
fast-io;
sndbuf 0;
rcvbuf 0;
push "sndbuf 524288";
push "rcvbuf 524288";

Custom client settings
fast-io
fragment 0
mssfix 0
sndbuf 524288
rcvbuf 524288


Any suggestions?

[chemlud]

...try with faster procesor. openvpn runs single-core...

[proxykid]

Thank you for reply

I think cpu should be enough for 100.

Openssl tests for AES-128 and AES-256 EITHER CBC and Gcb throw about 130 mbps.

Cpu does have AES-NI support and single thread usage when transferring data at the apparent max speed of 25 mbps is ~25%, therefore I'm not even using 50% of a single core/thread.

[mfedv]

You have explicitly disabled mssfix. Can you check if openvpn encapsulated traffic gets fragmented? That should be avoided, as fragment reassembly is rather slow.

[proxykid]

You have explicitly disabled mssfix. Can you check if openvpn encapsulated traffic gets fragmented? That should be avoided, as fragment reassembly is rather slow.

I'm sorry but how would I check this? pcaps?

[mfedv]

If you use TCP as transport protocol, then please disregard; TCP will not have fragmentation

If you use UDP as transport protocol, then take a packet capture: Interfaces / Diagnostics / Packet Capture. Select UDP as protocol, select the peer ip address if you know it, but leave port number unset; follow-up fragments do not carry port numbers.

Start the capture and start a file transfer through OpenVPN.

If you see something like
    20:58:29.321685 IP a.b.c.d > u.v.w.x: ip-proto-17

then you have fragmentation issues. 17 is the protocol number for UDP, but no port numbers are displayed because they are missing in any but the initial fragment.

Depending on how big the reassembled packet is, you may also see "bad length x > y" for the initial fragment (where port numbers are shown).

If that is the case, start with something like "mssfix 1300". This is low enough you should not have UDP fragmentation. You can experiment with higher values and find the optimum value that still works without fragmentation. The exact value will also depend on the client's internet connection.

This only helps for TCP connections inside the tunnel, large UDP packets will still be fragmented.

[proxykid]

If you use TCP as transport protocol, then please disregard; TCP will not have fragmentation

If you use UDP as transport protocol, then take a packet capture: Interfaces / Diagnostics / Packet Capture. Select UDP as protocol, select the peer ip address if you know it, but leave port number unset; follow-up fragments do not carry port numbers.

Start the capture and start a file transfer through OpenVPN.

If you see something like
    20:58:29.321685 IP a.b.c.d > u.v.w.x: ip-proto-17

then you have fragmentation issues. 17 is the protocol number for UDP, but no port numbers are displayed because they are missing in any but the initial fragment.

Depending on how big the reassembled packet is, you may also see "bad length x > y" for the initial fragment (where port numbers are shown).

If that is the case, start with something like "mssfix 1300". This is low enough you should not have UDP fragmentation. You can experiment with higher values and find the optimum value that still works without fragmentation. The exact value will also depend on the client's internet connection.

This only helps for TCP connections inside the tunnel, large UDP packets will still be fragmented.

Its setup for UDP, did the test and so far packets are not showing up fragmentation, I'll do more tests for nothing so far.

I just upgraded from OpnSense 19.7 to 20.1.3, ran more tests, same behavious. I did howerver tested with 2 devices now simultaneously and same speed between both. Ran speedtest in my PC and my phone and both maintain the speed at 25-30 mbps even at the same time.

Still, made the changes suggested just in case like adding mssfix and no improvement, also changed from AES-128-CBC to  AES-128-GCM, added RDRAND crypto engine, made sure AESNI is enabled, and adaptive compression, slight improvement from avg 25 mbps to 30 mbps.

[mfedv]

just to check if encryption is the limiting factor: can you try with no encryption / no authentication ?
(what is your current Auth Digest Algorithm?)