Chapter 9

OpenSSL cipher speed

OpenVPN uses OpenSSL to perform all cryptographic operations. This means that the performance of an OpenVPN client or server depends on how fast the incoming traffic can be decrypted and how fast the outgoing traffic can be encrypted. For a client with a single connection to the OpenVPN server, this is almost never an issue, but with an OpenVPN server with hundreds of clients, the cryptographic performance becomes very important.

In this recipe, we will show how to measure the performance of the OpenSSL cryptographic routines and how this measurement can be used to improve the performance of an OpenVPN server to which many clients connect.

Getting ready

This recipe is performed on a variety of computers:

A laptop with Intel Core2 Duo T9300 processor running at 2.5 GHz, running Fedora Linux 13 64bit

A server with Intel Xeon X5660 processor running at 2.8 GHz and with support for the AESNI instructions, running CentOS 5.5 64bit

An older desktop computer with an AMD XP 1800+ processor running at 1.5 GHz, running Windows 2000 SP4

The recipe can easily be performed on MacOS as well. Each computer had OpenVPN 2.1 installed, with the accompanying OpenSSL libraries. The X5660 server had a patched version of OpenSSL 1.0.0a installed to add support for the AESNI instructions found in this processor.

How to do it...

On each system, the following OpenSSL commands are run:

$ openssl speed -evp bf-cbc

$ openssl speed -evp aes-128-cbc $ openssl speed -evp aes-256-cbc

The first command tests the speed of the OpenVPN default BlowFish cryptographic cipher. The latter two test the performance of the 128 and 256-bit AES ciphers, which are very commonly used to secure websites. On the server with X5660 processor, the extra flag -engine aesni was used.

The results are displayed in the following table. All numbers in the tables are the bytes per second processed when encrypting a block of data. The size of the block of data is listed in the columns.

239

Performance Tuning

For the BlowFish cipher, the following results were recorded:

For the AES128 cipher, the following results were recorded:

How it works...

The output of the openssl speed command shows that the encryption and decryption performance is dependent on both the encryption key and the hardware used. Most OpenVPN packets are about 1500 bytes, so the column 1024 bytes is the most interesting column to look at.

The BlowFish cipher results are quite interesting if you take the processor speed into account: if you divide the BlowFish performance by the processor clock speed the numbers are very similar. This means that the BlowFish performance is bound purely by the processor clock speed. An older type processor running at a higher clock speed might actually outperform a newer processor with a slightly lower clock speed.

For the AES128 and AES256 ciphers, this is no longer true. Here the Core2 Duo and Xeon architectures are much faster than the older Pentium 4 and Athlon architectures. When the AESNI extensions found in the latest Intel processors are used, the performance jumps by a factor of 4. If an OpenVPN server is set up that must support many clients, then this cryptographic cipher is an excellent choice, provided that the server CPU supports

these extensions.

240

Chapter 9

There's more...

The choice of the cryptographic cipher on the performance of OpenVPN is minimal for a single client. Measurements done for this recipe indicate that the client CPU has a load of less than

8% when downloading a file at the highest speed over the VPN tunnel on a modern system.

However, on the older desktop, the choice of cryptographic cipher does become important: upload speed drops from 760 kbps to 720 kbps when the BlowFish cipher changes to the AES256 cipher. Especially, when older hardware or certain home router equipment

is used, this can quickly become a bottleneck. Most home wireless routers capable of running OpenVPN, for example, the wireless routers that support the DD-WRT or OpenWRT distributions, have a processor speed of about 250 MHz. This processor speed can quickly become the bottleneck if this router is also used as an OpenVPN server, especially, when multiple clients connect simultaneously.

See also

Chapter 7's recipe, Cipher mismatches, which explains in more detail how to troubleshoot cipher mismatches in the client and server configuration files.

Compression tests

OpenVPN has built-in support for LZO compression, if compiled properly. All Windows binaries have LZO compression available by default. In this recipe, we will show what the performance is of using LZO compression when transferring both easily compressible data (such as web pages) and non-compressible data (such as photographs or binaries).

Getting ready

We use the following network layout:

241

Performance Tuning

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Set up the client and server certificates using the first recipe from Chapter 2,

Client-server IP-only Networks. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The first client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing

at hand, as well as the client configuration file, basic-udp-client.conf, from the same recipe. The recipe was repeated with a second client running Windows XP SP3 and OpenVPN

2.1.1. For this client, keep the client configuration file, basic-udp-client.ovpn, from the

Chapter 2 recipe Using an ifconfig-pool block at hand.

How to do it...

1.Append the following line to the basic-udp-server.conf file: comp-lzo

Save it as example9-4-server.conf.

2.Start the server:

[root@server]# openvpn --config example9-4-server.conf

3.Similarly, for the client, add a line to the basic-udp-client.conf file: comp-lzo

Save it as example9-4-client.conf.

4.Start the client:

[root@client]# openvpn --config example9-4-client.conf

5.Next, we start iperf on the server:

[server]$ iperf –s

6.First, we measure the performance when transferring data outside of the tunnel:

[client]$ iperf –c <openvpn-server-ip>

This results in a throughput of about 50 Mbps over an 802.11n wireless network.

7.Next, non-compressible data:

[client]$ dd if=/dev/urandom bs=1024k count=60 of=random [client]$ iperf –c 192.168.200.1 –F random

[ 4] 0.0-10.0 sec 35.0 MBytes 29.3 Mbits/sec

In the first step, we create a 60MB file with random data. Then, we measure the iperf performance when transferring this file.

242

Chapter 9

8.And finally, compressible data (a file filled with zeroes):

[client]$ dd if=/dev/zeroes bs=1024k count=60 of=zeroes

[client]$ iperf –c 192.168.200.1 –F zeroes

[ 5] 0.0- 5.9 sec 58.6 MBytes 83.3 Mbits/sec

The performance of the VPN tunnel when transferring compressible data such as text files and web pages is shown.

9.The same measurement can be made using a Windows PC. Add the following line to the basic-udp-client.ovpn file:

comp-lzo

Save it as example9-4.ovpn.

10.Start the client.

The results of the iperf measurement are slightly different:

Outside the tunnel: 50 Mbps

Non-compressible data: 16 Mbps

Compressible data: 22 Mbps

Clearly, the OpenVPN configuration needs to be optimized, but that is outside the scope of this recipe. These results do show that for both Windows and Linux clients, there is a significant performance boost when the data that is sent over the tunnel is easily compressible.

How it works...

When compression is enabled, all packets that are sent over the tunnel are compressed before they are encrypted and transferred to the other side. Compression is done using the

LZO library, which is integrated into OpenVPN. This compression is done on-the-fly, which means that the compression ratios achieved are not as good as when compressing the data in advance. When transferring text pages, the performance gain is nevertheless significant.

There's more...

When using compression, there are a few caveats to be aware of.

Pushing compression options

With OpenVPN, it is possible to push compression options from the server to the client using the directive:

comp-lzo

push "comp-lzo"

243