Performance Tuning

The caveat here is that this push directive is picked up by the OpenVPN 2.1 client only if it already has a line:

comp-lzo {yes|no|adaptive}

in the client configuration file. If this option is not present, the pushed directive is ignored and the connection actually fails to start.

Adaptive compression

When the following configuration directive is used, adaptive compression is enabled by default:

comp-lzo

When OpenVPN detects that a particular piece of data is not compressible it sends the data to the remote VPN endpoint without compressing it first. By specifying the following on both ends each packet is always compressed:

comp-lzo yes

Depending on the type of data that is transferred, the performance is slightly better.

Traffic shaping

In this recipe, we will use traffic shaping to limit the upload speed of an OpenVPN client. This can be used to throttle the bandwidth of a client to the server, or from client to client. Note that OpenVPN traffic shaping cannot be used to throttle the download speed of OpenVPN clients. Throttling download speeds can best be achieved using external traffic control tools, such as the 'tc' utility on Linux, which is part of the LARTC package.

Getting ready

We use the following network layout:

244

Chapter 9

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 client was running Windows XP SP3 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.ovpn from the

Chapter 2 recipe Using an ifconfig-pool block.

How to do it...

1.Append the following line to the basic-udp-server.conf file: push "shaper 100000"

This will throttle the upload speed of the VPN clients to 100,000 bytes per second (100 kbps). Save it as example9-5-server.conf.

2.Start the server:

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

3.Start the client:

4.Next, we start iperf on the server:

[server]$ iperf –s

5.When we run iperf on the Windows PC, the performance is close to 100 KB/s:

245

Performance Tuning

How it works...

When the OpenVPN client connects to the server, the server pushes out an option to shape outgoing traffic over the VPN tunnel to 100 KB/s. Whenever traffic is sent over the tunnel, the OpenVPN client itself limits the outgoing traffic to a maximum of 100 KB/s. The download speed is not affected by this, and note that the following directive cannot be used on the OpenVPN server itself:

shaper 100000

To throttle traffic leaving the server, more advanced traffic control tools such as tc for Linux should be used.

There's more...

OpenVPN 2.1 on Linux currently does not support traffic shaping very well. If this option is enabled in the Linux client, all network traffic over the tunnel is severely throttled to bytes per second. When OpenVPN 2.0 is used on the exact same Linux client the behaviour is as expected. This has been submitted as a bug but it is not known when it will be fixed.

Tuning UDP-based connections

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.

Getting ready

We use the following network layout:

246

Chapter 9

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. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The 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.

How to do it...

1.Append the following line to the basic-udp-server.conf file: fragment 1400

Save it as example9-6-server.conf.

2.Start the server:

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

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

Save it as example9-6-client.conf.

4.Start the client:

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

5.Next, we start iperf on the server:

[server]$ iperf –s

6.First, we measure the performance outside the tunnel:

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

[ 3] 0.0-10.1 sec 8.4 MBytes 803 kbits/sec

This actually measures the performance of data being sent TO the server. The ADSL network used in this recipe has a theoretical upload limit of 1024 kbps, which in practice results in an 800 kbps upload speed. Note that this result is nearly the same as found in the recipe Optimizing performance using 'iperf'.

7.Next, we measure the performance inside the tunnel:

[client]$ iperf –c 192.168.200.1

[ 3] 0.0-10.0 sec 8.2 MBytes 803 kbits/sec

With this network setup there is no measurable performance difference between traffic sent outside of the tunnel and traffic sent via the tunnel, even with or without fragmentation.

Fragmentation does have an effect on the ping round-trip times, however.

247

Performance Tuning

8.For various values of the fragment option, run the ping command from client to server:

[client]$ ping -c 10 192.168.200.1

The results are listed in the following table:

Fragmentation size	Ping result
Default (1500)	41 +/- 1 ms
1400	43 +/- 1 ms
400	47 +/- 1 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.

How it works...

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.

There's more...

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 such 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.

248