In this recipe, we will analyze the performance of an OpenVPN setup using the tcpdump utility. It is also possible to use the Wireshark utility, which is available for Linux, Windows, and Mac OS X. While this recipe does not cover any new OpenVPN functionality, it is useful to show how such an analysis can be made.
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 example8-8-server.conf from the Tuning UDP-based connections recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration, example8-8-client.conf, from the same recipe.
- Start the server:
[root@server]# openvpn --config example8-8-server.conf - Next, start the client:
[root@client]# openvpn --config example8-8-client.conf - On the server, run
tcpdumpto watch for the incoming packets on the network interface (not the tunnel interface itself):[root@server]# tcpdump -nnl -i eth0 udp port 1194This instructs
tcpdumpto listen on the local network interface for all UDP traffic on port1194, which is the OpenVPN default. - From the client, ping the server's VPN IP address with two different sizes:
[client]$ ping -c 2 -s 1300 10.200.0.1 [client]$ ping -c 2 -s 1400 10.200.0.1
The following packets are seen in the tcpdump screen:
The first ICMP packets are sent unfragmented, as they are smaller than 1400 bytes. The second set of encrypted ICMP packets is larger than the fragment size (1400) and hence are split into two parts.
The OpenVPN configuration directive fragment 1400 causes all the encrypted packets that are larger than 1400 bytes to be fragmented. When watching the encrypted traffic, this can be verified by pinging the OpenVPN server. Note that packets which need to be fragmented are fragmented evenly: all packets have the same size.
Also, note that the following command causes the encrypted packet to be larger than 1400 bytes:
[client]$ ping -c 2 -s 1400 10.200.0.1
The encryption needed for the secure tunnel adds extra overhead to the packets that are transmitted. This is one of the root causes for a performance penalty when using VPN tunnels (not just OpenVPN) compared to non-encrypted traffic. In most networks, this overhead is not noticed, but it always exists.