Why does OpenVPN slow down?
The described problem is inherent only in the OpenVPN 2.3 branch, in 2.4 the buffer sizes do not change without the user's requirement.
From time to time, I encounter topics on forums where people connect several offices using OpenVPN and get low speed, much lower than the speed of the channel. Someone may have 20 Mbit / s with a channel of 100 Mbit / s on both sides, and someone barely receives 400 Kbit / s at 2 Mbit / s with ADSL / 3G and high ping. Often, such people are advised to increase the MTU on the VPN interface to extremely large values, like 48000, or to play with the mssfix parameter. This partially helps, but the speed inside the VPN is still very far from the link speed. Sometimes everyone blames the fact that OpenVPN is a userspace solution, and this is its normal speed, given all sorts of encryption and HMACs. Absurd!
One of the developers adds code that sets the default receive and send buffer to 64 KB, probably to somehow unify the buffer size between platforms and not depend on system settings. However, in Windows something broke, and specifying the size of the buffers on the socket leads to strange MTU problems on all adapters in the system. Finally, the following code gets into the release of OpenVPN 2.0-beta8:
What does this mean? Suppose you are connecting to a server in the USA from Russia via OpenVPN with standard socket buffers. You have a wide channel, say, 50 Mbit / s, but due to the distance, the ping is 100 ms. What do you think, what is the maximum speed you can achieve? 5.12 Mbps. You need a buffer of at least 640 KB in size to load your 50 Mbps channel.
OpenVPN via UDP will work somewhat faster due to its own packet forwarding implementation, but also far from ideal.
')
You need to add the following lines to both the server and client configuration files:
In this case, the buffer size will be set by the OS settings. For Linux and TCP, this value will change according to the values from net.ipv4.tcp_rmem and net.ipv4.tcp_wmem, and for UDP, the fixed value is net.core.rmem_default and net.core.wmem_default, divided by two.
If for some reason it is not possible to change the client configuration files, you should give sufficiently large buffer sizes from the server:
UDP is slightly different from TCP. It does not have an analogue of Window Scale, it does not require confirmation of the delivery of a packet at the transport level, but the low size of the receive buffer can slow it down if the buffer is clogged before OpenVPN has time to read it. If the speed inside the tunnel seems low to you even with the changes described above, then it may make sense either to increase the buffer size for the entire system, increasing net.core.rmem_default and net.core.wmem_default, or always specify a certain buffer size in the configuration file:
Sluggish bug on the bug tracker OpenVPN
From time to time, I encounter topics on forums where people connect several offices using OpenVPN and get low speed, much lower than the speed of the channel. Someone may have 20 Mbit / s with a channel of 100 Mbit / s on both sides, and someone barely receives 400 Kbit / s at 2 Mbit / s with ADSL / 3G and high ping. Often, such people are advised to increase the MTU on the VPN interface to extremely large values, like 48000, or to play with the mssfix parameter. This partially helps, but the speed inside the VPN is still very far from the link speed. Sometimes everyone blames the fact that OpenVPN is a userspace solution, and this is its normal speed, given all sorts of encryption and HMACs. Absurd!
A bit of history
In the courtyard of July 2004. Typical home Internet speed in developed countries is 256 Kbit / s-1 Mbit / s, in less developed ones - 56 Kbit / s. The Linux 2.6.7 kernel came out not so long ago, and 2.6.8, in which TCP Window Scale is enabled by default, will be released only in a month. The OpenVPN project has been developing for 3 years already, version 2.0 is being prepared for release.One of the developers adds code that sets the default receive and send buffer to 64 KB, probably to somehow unify the buffer size between platforms and not depend on system settings. However, in Windows something broke, and specifying the size of the buffers on the socket leads to strange MTU problems on all adapters in the system. Finally, the following code gets into the release of OpenVPN 2.0-beta8:
#ifndef WIN32 o->rcvbuf = 65536; o->sndbuf = 65536; #endif Some technical information
If you used OpenVPN, you know that it can work through both UDP and TCP. If a small buffer value is set on a TCP socket, in our case 64 KB, then the TCP window adjustment algorithm simply cannot go beyond that value.What does this mean? Suppose you are connecting to a server in the USA from Russia via OpenVPN with standard socket buffers. You have a wide channel, say, 50 Mbit / s, but due to the distance, the ping is 100 ms. What do you think, what is the maximum speed you can achieve? 5.12 Mbps. You need a buffer of at least 640 KB in size to load your 50 Mbps channel.
OpenVPN via UDP will work somewhat faster due to its own packet forwarding implementation, but also far from ideal.
')
What to do?
As you might have guessed, this buffer size is still used in the latest release of OpenVPN. How do we fix the situation? The most correct option is to prohibit OpenVPN from changing the buffer size of the socket.You need to add the following lines to both the server and client configuration files:
sndbuf 0 rcvbuf 0 In this case, the buffer size will be set by the OS settings. For Linux and TCP, this value will change according to the values from net.ipv4.tcp_rmem and net.ipv4.tcp_wmem, and for UDP, the fixed value is net.core.rmem_default and net.core.wmem_default, divided by two.
If for some reason it is not possible to change the client configuration files, you should give sufficiently large buffer sizes from the server:
sndbuf 0 rcvbuf 0 push "sndbuf 393216" push "rcvbuf 393216" UDP is slightly different from TCP. It does not have an analogue of Window Scale, it does not require confirmation of the delivery of a packet at the transport level, but the low size of the receive buffer can slow it down if the buffer is clogged before OpenVPN has time to read it. If the speed inside the tunnel seems low to you even with the changes described above, then it may make sense either to increase the buffer size for the entire system, increasing net.core.rmem_default and net.core.wmem_default, or always specify a certain buffer size in the configuration file:
sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216" But I have Windows!
If you have an OpenVPN server running on a Windows machine, and all clients connect only from under Windows, then congratulations — you don’t need to change anything, and everything should work quickly for you.Sluggish bug on the bug tracker OpenVPN
Source: https://habr.com/ru/post/246953/
All Articles