English Forums > Hardware and Performance
OpenVPN slow throughput
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:
--- Quote from: mfedv on March 26, 2020, 09:26:22 pm ---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.
--- End quote ---
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?)
Navigation
[0] Message Index
[*] Previous page
Go to full version