In this recipe, we focus on some of the basic techniques for optimizing UDP-based VPN tunnels. These techniques need to be applied with care, as there is no fool-proof method for optimizing OpenVPN performance. The actual performance gain varies with each network setup. Therefore, this recipe only shows some of the configuration directives that can be used for this optimization.
We use the following network layout:
Set up the client and server certificates using the Setting up the public and private keys recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.11. The client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the configuration file basic-udp-server.conf
from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.conf
.
basic-udp-server.conf
file:fragment 1400
example8-8-server.conf
.[root@server]# openvpn --config example8-8-server.conf
basic-udp- client.conf
file:fragment 1400
example8-8-client.conf
.[root@client]# openvpn --config example9-6-client.conf
iperf
on the server:[server]$ iperf -s
[client]$ iperf -c <openvpn-server-ip> [ 4] 0.0-16.7 sec 8.00 MBytes 4.03 Mbits/sec
This actually measures the performance of data being sent to the server. The cable network used in this recipe has a theoretical upload limit of 4 Mbps. Note that this result is nearly the same as found in the recipe Optimizing performance using iperf.
[client]$ iperf -c 10.200.0.1 [ 4] 0.0-18.3 sec 8.00 MBytes 3.66 Mbits/sec
A slight penalty is incurred due to the OpenVPN tunnel, but the results are nearly identical to the results found in the recipe Optimizing performance using iperf.
Fragmentation does have an effect on the ping
round-trip times, however.
fragment
option, run the ping
command from the client to server:[client]$ ping -c 10 10.200.0.1
The results are listed in the following table:
Fragmentation size |
Ping result |
Default (1500) |
9.4 +/- 1.0 ms |
1400 |
9.9 +/- 1.5 ms |
400 |
19.2 +/- 8 ms |
Thus, adding the fragment
option to the server configuration is not a viable option for this network setup. However, in other network setups, this might improve performance.
The OpenVPN configuration directive fragment 1400
causes all encrypted packets that are larger than 1400 bytes to be fragmented. If the network latency is low enough, this does not have a noticeable effect on performance, as the iperf
results. By lowering the fragmentation size, packets are split into more and more packets. This causes the round-trip time for larger packets to increase. If the network latency is already high, this will cause even more latency issues. Hence, the fragment
option and associated mssfix
option must be used with care.
The fragment
directive is often used in conjunction with the mssfix
directive:
mssfix [maximum-segment-size]
This directive announces to TCP sessions running over the tunnel that they should limit their send packet sizes so that after OpenVPN has encapsulated them; the resulting UDP packet size that OpenVPN sends to its peer will not exceed the maximum segment size. It is also used internally by OpenVPN to set the maximum segment size of outbound packets. If no maximum segment size is specified, the value from the fragment
directive is used.
Ideally, the mssfix
and fragment
directives are used together, where mssfix
will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (for example, from protocols other than TCP), the fragment
directive will internally fragment them.
3.144.117.167