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.
- Append the following line to the
basic-udp-server.conffile:fragment 1400 - Save it as
example8-8-server.conf. - Start the server:
[root@server]# openvpn --config example8-8-server.conf - Similarly, for the client, add a line to the
basic-udp- client.conffile:fragment 1400 - Save it as
example8-8-client.conf. - Start the client:
[root@client]# openvpn --config example9-6-client.conf - Next, we start
iperfon the server:[server]$ iperf -s - First, we measure the performance outside the tunnel:
[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.
- Next, we measure the performance inside the tunnel:
[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
pinground-trip times, however. - For various values of the
fragmentoption, run thepingcommand 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.