Chapter 7

…[openvpnserver] Peer Connection Initiated with server-ip:1194

…TUN/TAP device tap0 opened

…/sbin/ip link set dev tap0 up mtu 1500

…/sbin/ip addr add dev tap0 192.168.200.2/24 broadcast 192.168.200.255

…Initialization Sequence Completed

At this point, you can try pinging the server, but it will respond with an error:

[client]$ ping 192.168.200.1

PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data. From 192.168.200.2 icmp_seq=2 Destination Host Unreachable From 192.168.200.2 icmp_seq=3 Destination Host Unreachable From 192.168.200.2 icmp_seq=4 Destination Host Unreachable

How it works...

A TUN-style interface offers a point-to-point connection over which only TCP/IP traffic can be tunneled. A TAP-style interface offers the equivalent of an Ethernet interface that includes extra headers. This allows a user to tunnel other types of traffic over the interface. When the client and the server are misconfigured, the expected packet size is different:

… WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

This shows that each packet that is sent through a TAP-style interface is 32 bytes larger than the packets sent through a TUN-style interface.

By correcting the client configuration, this problem is resolved.

Compression mismatches

OpenVPN supports on-the-fly compression of the traffic that is sent over the VPN tunnel.

This can improve the performance over a slow network line, but it does add a little overhead.

When transferring uncompressible data (such as ZIP files), the performance actually decreases slightly.

If the compression is enabled on the server but not on the client, then the VPN connection will fail.

191

Troubleshooting OpenVPN: Configurations

Getting ready

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

How to do it...

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

Save it as example7-3-server.conf.

2.Start the server:

[root@server]# openvpn --config example7-3-server.conf

3.Next, start the client:

[root@client]# openvpn --config basic-udp-client.conf

The connection will initiate but when data is sent over the VPN connection, the following messages will appear:

Initialization Sequence Completed

…write to TUN/TAP : Invalid argument (code=22)

…write to TUN/TAP : Invalid argument (code=22)

How it works...

During the connection phase, no compression is used to transfer information between the client and the server. One of the parameters that is negotiated is the use of compression for the actual VPN payload. If there is a configuration mismatch between the client and the server, then both the sides will get confused by the traffic that the other side is sending.

With a network fully comprising OpenVPN 2.1 clients and an OpenVPN 2.1 server, this can be fixed for all the clients by just adding another line:

push "comp-lzo"

192

Chapter 7

There's more...

OpenVPN 2.0 did not have the ability to push compression directives to the clients. This means that an OpenVPN 2.0 server does not understand this directive, nor do OpenVPN 2.0 clients. So, if an OpenVPN 2.1 server pushes out this directive to an OpenVPN 2.0 client, the connection will fail.

Key mismatches

OpenVPN offers extra protection for its TLS control channel in the form of HMAC keys. These keys are exactly the same as the static "secret" keys used in Chapter 1, Point-to-Point

Networks, for point-to-point style networks. For multi-client style networks, this extra protection can be enabled using the tls-auth directive. If there is a mismatch between the client and the server related to this tls-auth key, then the VPN connection will fail to get initialized.

Getting ready

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

How to do it...

1.Start the server using the configuration file basic-udp-server.conf:

[root@server]# openvpn --config basic-udp-server.conf

2.Next, create the client configuration:

client proto udp

remote openvpnserver port 1194

dev tun nobind

ca /etc/openvpn/cookbook/ca.crt

193

Troubleshooting OpenVPN: Configurations

cert /etc/openvpn/cookbook/client1.crt key /etc/openvpn/cookbook/client1.key tls-auth /etc/openvpn/cookbook/ta.key

ns-cert-type server

Note the lack of the second parameter for tls-auth. Save it as example7-4-client.conf file.

3.Start the client:

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

The client log will show no errors, but the connection will not be established either. In the server log we'll find:

…Initialization Sequence Completed

…Authenticate/Decrypt packet error: packet HMAC authentication failed

…TLS Error: incoming packet authentication failed from clientip:54454

This shows that the client openvpnclient1 is connecting using the wrong tls-auth parameter and the connection is refused.

How it works...

At the very first phase of the connection initialization, the client and the server verify each other's HMAC keys. If an HMAC key is not configured correctly, then the initialization is aborted and the connection will fail to establish. As the OpenVPN server is not able to determine whether the client is simply misconfigured or whether a malicious client is trying to overload the server, the connection is simply dropped. This causes the client to keep listening for the traffic from the server, until it eventually times out.

In this recipe, the misconfiguration consisted of the missing parameter 1 behind:

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

The second parameter to the tls-auth directive is the direction of the key. Normally, the following convention is used:

0: from server to client

1: from client to server

This parameter causes OpenVPN to derive its HMAC keys from a different part of the ta.key file. If the client and server disagree on which parts the HMAC keys are derived from, the connection cannot be established. Similarly, when the client and server are deriving the HMAC keys from different ta.key files, the connection can also not be established.

194