Chapter 9

See also

The next recipe in this chapter, which explains how to tune TCP-based connections in a very similar manner.

Tuning TCP-based connections

In this recipe, we focus on some of the basic techniques for optimizing TCP-based VPN tunnels. In a TCP-based VPN setup, the connection between the VPN endpoints is a regular TCP connection. This has advantages and drawbacks. The main advantage is that it is often easier to set up a TCP connection than a UDP connection, mostly due to firewall restrictions. The main drawback of tunneling TCP traffic over a TCP-based tunnel is that there is chance of severe performance penalties, especially, when the network connection is poor. This performance penalty is caused by the tcp-over-tcp syndrome. The TCP protocol guarantees the ordered delivery of packets, thus if a packet is dropped along the way, the packet will be resent. Once the new packet is received, the packet order is restored. Until that time, all

packets after the lost packet are on hold. The problem with tunnelling TCP traffic over a TCP connection is that both layers want to guarantee ordered packet delivery. This can lead to a large amount of retransmits and hence to a large performance penalty.

When tuned correctly, however, an OpenVPN tunnel over a TCP connection can achieve the same performance as an OpenVPN tunnel over a UDP connection. In this recipe, we will show some techniques for tuning such a TCP-based OpenVPN connection.

Getting ready

We use the following network layout:

249

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 client was running Windows XP SP3 and OpenVPN 2.1.1.

How to do it...

1.Create the server configuration file:

proto tcp port 1194 dev tun

server 192.168.200.0 255.255.255.0

tls-auth /etc/openvpn/cookbook/ta.key 0

persist-key persist-tun keepalive 10 60

topology subnet

user nobody group nobody

daemon

log-append /var/log/openvpn.log

tcp-nodelay

Save it as example9-7-server.conf.

2.Start the server:

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

3.Next , create the client configuration file:

client proto tcp

remote openvpnserver.example.com port 1194

250

Chapter 9

dev tun nobind

tls-auth "c:/program files/openvpn/config/ta.key" 1

ns-cert-type server

Save it as example9-7.ovpn. 4. Start the client:

5.Next, start iperf on the server:

[server]$ iperf –s

6.Then, measure the performance of the tunnel:

[client]$ iperf –c 192.168.200.1

On this particular network, the following settings were tested:

As can be seen, the performance of running OpenVPN over TCP is almost identical to the performance of OpenVPN over UDP, when the --tcp-nodelay directive is used.

251

Performance Tuning

How it works...

When OpenVPN uses TCP as its underlying protocol, all packets are transferred over a regular TCP connection. By default, TCP connections make use of the Nagle algorithm, where smaller packets are held back and collected before they are sent. For an OpenVPN tunnel, this has an adverse effect on performance in most cases, hence it makes sense to disable the Nagle algorithm. By adding the --tcp-nodelay directive, we disable the Nagle algorithm and we see an immediate increase in performance.

There's more...

The two important parameters that can be tweaked for TCP-based connections are:

The --tcp-nodelay directive

The MTU size of the TUN/TAP-Win32 adapter via either the --tun-mtu or

--link-mtu directives

On Linux, the MTU size of the TUN (or TAP) adapter can be adjusted on-the-fly, but on Windows XP, this is not the case. OpenVPN must be configured to match the MTU size as specified on the server. Before the new MTU size is used, however, a registry change must be made and Windows must be rebooted for the new MTU size to take effect. This makes it much harder

to find the right MTU size for Window clients.

Starting with Windows Vista, it is now also possible to change the MTU setting on-the-fly, using the netsh command:

First, find the right sub-interface number:

[winclient]C:> netsh interface ipv4 show subinterfaces

Next, in order to change the MTU size of a sub-interface, use:

[winclient]C:> netsh interface ipv4 set subinterface "1" mtu=1400

Note that these commands must be run with elevated privileges.

If the MTU setting of the Windows TAP-Win32 adapter is larger than the MTU size configured by OpenVPN, the following message can appear in the OpenVPN 2.1 log file:

… read from TUN/TAP [State=AT?c Err=[c:\src\21\tap-win32\tapdrvr. c/2447] #O=4 Tx=[29510,0] Rx=[15309,0] IrpQ=[0,1,16] PktQ=[0,22,64] InjQ=[0,1,16]]: More data is available. (code=234)

For this particular network, all changes made to the MTU size (with the appropriate Windows reboot) did not have a positive effect on performance.

252