OpenVPN 2 Cookbook
100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network
- Set of recipes covering the whole range of tasks for working with OpenVPN
- The quickest way to solve your OpenVPN problems!
- Set up, configure, troubleshoot and tune OpenVPN
- Uncover advanced features of OpenVPN and even some undocumented options
Introduction
The topic of this article is troubleshooting OpenVPN. This article will focus on troubleshooting OpenVPN misconfigurations.
The recipes in this article will therefore deal first with breaking the things. We will then provide the tools on how to find and solve the configuration errors. Some of the configuration directives used in this article have not been demonstrated before, so even if you are not interested in breaking things this article will still be insightful.
Cipher mismatches
In this recipe, we will change the cryptographic ciphers that OpenVPN uses. Initially, we will change the cipher only on the client side, which will cause the initialization of the VPN connection to fail. The primary purpose of this recipe is to show the error messages that appear, not to explore the different types of ciphers that OpenVPN supports.
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. 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 server configuration file basic-udp-server.conf (download code, ch:2) and the client configuration file basic-udp-client.conf at hand.
How to do it…
- Start the server using the configuration file basic-udp-server.conf:
[root@server]# openvpn –config basic-udp-server.conf
- Next, create the client configuration file by appending a line to the basic-udp-client.conf file:
cipher CAST5-CBC
Save it as example7-1-client.conf.
- Start the client, after which the following message will appear in the client log:
[root@client]# openvpn –config example7-1-client.conf
… WARNING: ‘cipher’ is used inconsistently, local=’cipher CAST5-
CBC’, remote=’cipher BF-CBC’
… [openvpnserver] Peer Connection Initiated with server-ip:1194
… TUN/TAP device tun0 opened
… /sbin/ip link set dev tun0 up mtu 1500
… /sbin/ip addr add dev tun0 192.168.200.2/24 broadcast
192.168.200.255
… Initialization Sequence Completed
… Authenticate/Decrypt packet error: cipher final failed - And, similarly, on the server side:
… client-ip:52461 WARNING: ‘cipher’ is used inconsistently,
local=’cipher BF-CBC’, remote=’cipher CAST5-CBC’
… client-ip:52461 [openvpnclient1] Peer Connection Initiated
with openvpnclient1:52461
… openvpnclient1/client-ip:52461 Authenticate/Decrypt packet
error: cipher final failed
… openvpnclient1/client-ip:52461 Authenticate/Decrypt packet
error: cipher final failed
The connection will not be successfully established, but it will also not be disconnected immediately.
How it works…
During the connection phase, the client and the server negotiate several parameters needed to secure the connection. One of the most important parameters in this phase is the encryption cipher, which is used to encrypt and decrypt all the messages. If the client and server are using different ciphers, then they are simply not capable of talking to each other.
By adding the following configuration directive to the server configuration file, the client and the server can communicate again:
cipher CAST5-CBC
There’s more…
OpenVPN supports quite a few ciphers, although support for some of the ciphers is still experimental. To view the list of supported ciphers, type:
$ openvpn –show-ciphers
This will list all ciphers with both variables and fixed cipher length. The ciphers with variable cipher length are very well supported by OpenVPN, the others can sometimes lead to unpredictable results.
TUN versus TAP mismatches
A common mistake when setting up a VPN based on OpenVPN is the type of adapter that is used. If the server is configured to use a TUN-style network but a client is configured to use a TAP-style interface, then the VPN connection will fail. In this recipe, we will show what is typically seen when this common configuration error is made.
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 (Download code-ch:2 here). 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 server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.confat hand.
How to do it…
- Start the server using the configuration file basic-udp-server.conf:
[root@server]# openvpn –config basic-udp-server.conf
- Next, create the client configuration:
client
proto udp
remote openvpnserver.example.com
port 1194
dev tap
nobind
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.key 1
ns-cert-type serverSave it as example7-2-client.conf.
- Start the client
[root@client]# openvpn –config example7-2-client.conf
The client log will show:
… WARNING: ‘dev-type’ is used inconsistently, local=’dev-type
tap’, remote=’dev-type tun’
… WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu
1573′, remote=’link-mtu 1541′
… WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1532′,
remote=’tun-mtu 1500′
… [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 CompletedAt 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.
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. 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 server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.confat hand..
How to do it…
- Append a line to the server configuration file basic-udp-server.conf:
comp-lzo
Save it as example7-3-server.conf.
- Start the server:
[root@server]# openvpn –config example7-3-server.conf
- 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”
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 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. 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 server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.conf at hand.
How to do it…
- Start the server using the configuration file basic-udp-server.conf:
[root@server]# openvpn –config basic-udp-server.conf
- Next, create the client configuration:
client
proto udp
remote openvpnserver
port 1194
dev tun
nobindca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.keyns-cert-type server
Note the lack of the second parameter for tls-auth. Save it as example7-4-client.conf file.
- 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 client-
ip: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.