December 28, 2014 at 23:38Why is OpenVPN slowing down?
The described problem is peculiar only to the OpenVPN 2.3 branch; in 2.4, buffer sizes do not change without the user's request.
From time to time, I come across topics on forums in which people connect several offices using OpenVPN and get a low speed, much lower than the channel speed. For some, it can be 20 Mbit / s with a channel of 100 Mbit / s on both sides, while someone can hardly get 400 Kbit / s for 2 Mbit / s ADSL / 3G and high ping. Often, such people are advised to increase the MTU on the VPN interface to extremely large values, such as 48000, or play with the mssfix parameter. This helps in part, but the speed inside the VPN is still very far from the channel. Sometimes everyone blames OpenVPN as 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 socket reception and sending buffer to 64 KB, probably in order to somehow unify the size of the buffer between platforms and not depend on system settings. However, something broke on Windows, and specifying the size of the buffers on the socket leads to strange MTU problems on all adapters in the system. Ultimately, the following code gets into OpenVPN 2.0-beta8 release:
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 maximum speed can you achieve? 5.12 Mbps. You need a buffer of at least 640 KB in size to load your 50 Mbps link.
OpenVPN over UDP will work somewhat faster due to its own implementation of packet forwarding, 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 determined 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 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 a sufficiently large buffer size from the server:
UDP is slightly different from TCP. It does not have an analogue of Window Scale, it does not require confirmation of packet delivery at the transport level, but a low receive buffer size can slow it down if the buffer gets clogged before OpenVPN manages to read it. If the speed inside the tunnel seems to you to be low even with the changes described above, then it may make sense to either increase the entire buffer size for the whole system by increasing net.core.rmem_default and net.core.wmem_default, or always specify a certain buffer size in the configuration file:
Sluggish bug on OpenVPN bug tracker
From time to time, I come across topics on forums in which people connect several offices using OpenVPN and get a low speed, much lower than the channel speed. For some, it can be 20 Mbit / s with a channel of 100 Mbit / s on both sides, while someone can hardly get 400 Kbit / s for 2 Mbit / s ADSL / 3G and high ping. Often, such people are advised to increase the MTU on the VPN interface to extremely large values, such as 48000, or play with the mssfix parameter. This helps in part, but the speed inside the VPN is still very far from the channel. Sometimes everyone blames OpenVPN as a userspace solution, and this is its normal speed, given all sorts of encryption and HMACs. Absurd!
A bit of history
Outside July 2004. Typical home Internet speeds in developed countries are 256 Kbps-1 Mbps, in less developed countries 56 Kbps. The Linux 2.6.7 kernel was released not so long ago, and 2.6.8, in which TCP Window Scale is enabled by default, will be released only after 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 socket reception and sending buffer to 64 KB, probably in order to somehow unify the size of the buffer between platforms and not depend on system settings. However, something broke on Windows, and specifying the size of the buffers on the socket leads to strange MTU problems on all adapters in the system. Ultimately, the following code gets into OpenVPN 2.0-beta8 release:
#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endifSome technical information
If you used OpenVPN, you know that it can work both through UDP and through TCP. If you set some small buffer value on the TCP socket, in our case 64 KB, then the TCP window tuning algorithm simply cannot go beyond this 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 maximum speed can you achieve? 5.12 Mbps. You need a buffer of at least 640 KB in size to load your 50 Mbps link.
OpenVPN over UDP will work somewhat faster due to its own implementation of packet forwarding, but also far from ideal.
What to do?
As you might have guessed, this buffer size is still used in the latest OpenVPN release. How do we fix the situation? The most correct option is to prevent OpenVPN from changing the size of buffers on the socket.You need to add the following lines to both the server and client configuration files:
sndbuf 0
rcvbuf 0In this case, the buffer size will be determined 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 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 a sufficiently large buffer size 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 packet delivery at the transport level, but a low receive buffer size can slow it down if the buffer gets clogged before OpenVPN manages to read it. If the speed inside the tunnel seems to you to be low even with the changes described above, then it may make sense to either increase the entire buffer size for the whole system by 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 Windows, then congratulations - you don’t need to change anything, everything should work quickly for you.Sluggish bug on OpenVPN bug tracker