On 08/06/18 11:47, Gena Makhomed wrote: > On 08.06.2018 12:13, David Sommerseth wrote: > >>> First test, between two servers without OpenVPN: >>> [ 4] 0.00-10.00 sec 120 MBytes 101 Mbits/sec sender >>> [ 4] 0.00-10.00 sec 117 MBytes 98.1 Mbits/sec receiver > >>> Second test, between OpenVPN interfaces: >>> [ 4] 0.00-10.00 sec 33.3 MBytes 27.9 Mbits/sec sender >>> [ 4] 0.00-10.00 sec 33.0 MBytes 27.7 Mbits/sec receiver > >>> As you can see, OpenVPN has very bad network throughput values, >>> compared to raw network values. > >> First of all, IIRC, the default iperf3 runs uses TCP. Your VPN tunnel runs >> over UDP (which normally is good). So you're comparing a little bit apples >> and oranges here. > > No, I compare oranges with oranges: how fast will work application > protocols if OpenVPN is used or OpenVPN not used for network layer.
Just to clarify my statement with comparing appels and oranges.
You needed to be sure that the raw link between client and server behaves
identical with TCP and UDP. Running raw TCP test between end points and
running encrypted and tunnelled TCP packets inside UDP packets over the same
link is considerably different.
> Application protocols are TCP-based, for example, FTP, HTTP. And I need
> good network throughput *for TCP-based protocols* when OpenVPN is used.
Right, and once the link layer between the client and server has been
validated, then we can look at what to do improve the tunnelled traffic.
>> Try running the same iperf3 test outside the VPN tunnel with --udp.
>> Does that give different results?
>
> Yes, I see Bandwidth 99.1 Mbits/sec and Bandwidth 99.0 Mbits/sec
> But I need to see the same excellent values for TCP protocol too.
Quick (hacky) fix is to try using OpenVPN with TCP. But the latency issues
with UDP packets mentioned elsewhere in this thread is part of the real
solution.
As Gert has said elsewhere too, we're discussing tunnel performance on links
with higher latencies on the openvpn-devel@ ML. We do not fully understand
why this happens yet.
> This is possible with OpenVPN at all?
Normally, yes, this should be doable, but the link between server and client
also need to play along.
> What can be tuned in OpenVPN or in operating system?
As mentioned try using --proto tcp. This is normally not optimal, but
sometimes works better than udp. In addition ...
Encryption adds some latency (--cipher). Packet authentication (--auth) is
another latency source. --tls-crypt/--tls-auth is yet another latency source.
Normally the added latency is not bad, but you seem to hit a sweet-spot
threshold which makes the throughput just drop to the floor.
Marty G. raises some interesting points. Check what kind of encryption
performance your servers provides on various ciphers ('openssl speed' gives
some hints). As well as his MTU point.
> What is the root cause of such very low network throughput values
> then TCP-based protocols are used on top of OpenVPN connections?
That is really hard to say. I don't have any good idea.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
