This recipe is not really about OpenVPN but more about how to use the network performance measurement tool iperf in an OpenVPN setup. The iperf utility can be downloaded from http://sourceforge.net/projects/iperf/ for Linux, Windows, and MacOS.
In this recipe, we will run iperf outside of OpenVPN and over the VPN tunnel itself, after which the differences in performance will be explained.
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.
- Start the server:
[root@server]# openvpn --config basic-udp-server.conf - Next, start the client:
[root@client]# openvpn --config basic-udp-client.conf ... ... Initialization Sequence Completed
- Next, we start
iperfon the server:[server]$ iperf -s - First, we measure the performance outside the tunnel:
[client]$ iperf -l 1M -n 8M -c <openvpn-server-ip> [ 3] 0.0-15.2 sec 8 MBytes 4.1 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 Megabits per second (Mbps), which we are achieving in this test.
- Next, we measure the performance inside the tunnel:
[client]$ iperf -l 1M -n 8M -c 10.200.0.1 [ 3] 0.0-17.0 sec 8 MBytes 3.95 Mbits/sec
With this network setup, there is a small performance difference between traffic sent outside of the tunnel and traffic sent via the tunnel.
- A second test is done over a 802.11n wireless network:
[client]$ iperf -c <openvpn-server-ip> [ 4] 0.0-10.8 sec 7.88 MBytes 6.10 Mbits/sec
Versus:
[client]$ iperf -c 10.200.0.1 [ 5] 0.0-11.3 sec 5.25 MBytes 3.91 Mbits/sec
Here, there is a noticeable drop in performance, suggesting that the OpenVPN is not configured optimally. There was a lot of noise on this wireless network, which makes it difficult to optimize.
The iperf tool is very straightforward: it sets up a TCP connection (or UDP, if desired) and measures how fast it can send or receive data over this connection. Normally, traffic is tested in only one direction, although a dual test can be triggered using the -r flag.
Tuning network performance depends heavily on both the network latency and the available bandwidth, as is outlined in more detail here.
Both the client and the server iperf processes report the network throughput after a iperf -c session has ended. Practice shows that the numbers reported by the server used in this recipe were more accurate than the numbers reported by the client. On the cable network used when writing this recipe, the maximum upload speed is about 4 Mbps. The client sometimes reported speeds larger than 4.4 Mbps, whereas the server reported a more accurate 4.1 Mbps.
One of the main reasons for the lack of performance drop over the cable network versus the performance drop over the wireless network is due to network latency. On the cable network, the latency was very stable at about 11 ms. On the wireless network, the latency varied between 2 ms and 90 ms. Especially, this variation in latency can skew the iperf performance measurements, making it very hard to optimize the OpenVPN parameters.
Performance tests on Gigabit networks show that the VPN itself is becoming the bottleneck. A normal TCP connection would show a transfer rate of 900 Mbps, whereas a TCP connection via an untuned OpenVPN tunnel would not perform faster than about 320 Mbps. We will come back to this later in this chapter.