Chapter 7
See also
Chapter 1's recipe, Multiple secret keys, in which the format and usage of the OpenVPN secret keys is explained in detail.
Troubleshooting MTU and tun-mtu issues
One of the more advanced features of OpenVPN is the ability to tune the network parameters of both the TUN (or TAP) adapter and the parameters of the encrypted link itself. This is a frequent cause of configuration mistakes, leading to low performance or even the inability to successfully transfer data across the VPN tunnel. This recipe will show what happens if there is an MTU (Maximum Transfer Unit) mismatch between the client and the server and how this mismatch can cause the VPN tunnel to fail only under certain circumstances.
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 file by appending a line to the basic-udp-client.conf file:
tun-mtu 1400
Save it as example7-5-client.conf.
3.Start the client and look at the client log:
[root@client]# openvpn --config example7-5-client.conf
…WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1441', remote='link-mtu 1541'
…WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400', remote='tun-mtu 1500'
…[openvpnserver] Peer Connection Initiated with server-ip:1194
…TUN/TAP device tun0 opened
195
Troubleshooting OpenVPN: Configurations
…/sbin/ip link set dev tun0 up mtu 1400
…/sbin/ip addr add dev tun0 192.168.200.2/24 broadcast 192.168.200.255
…Initialization Sequence Completed
There are a few warnings when the tunnel comes up, but the connection is initialized.
4.It is possible to send a traffic over the link, which we can verify using the ping command:
[client]$ ping -c 2 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=30.6 ms 64 bytes from 192.168.200.1: icmp_seq=2 ttl=64 time=30.7 ms
5.However, when sending larger packets, for example:
[client]$ ping -s 1450 192.168.200.1
Then, the following messages appear in the client log file:
…Authenticate/Decrypt packet error: packet HMAC authentication failed
…Authenticate/Decrypt packet error: packet HMAC authentication failed
The same thing will happen if the client tries to download a large file.
How it works...
The MTU or Maximum Transfer Unit determines how large packets can be that are sent over the tunnel without breaking up (fragmenting) the packet into multiple pieces. If the client and the server disagree on this MTU size, then the server will send packets to the client that are simply too large. This causes an HMAC failure (if tls-auth is used, as in this recipe) or the part of the packet that is too large is thrown away.
There's more...
On the Windows platform, it is not easy to change the MTU setting for the Tap-Win32 adapter that OpenVPN uses. The directive tun-mtu can be specified but the Windows version of
OpenVPN cannot alter the actual MTU setting, as Windows did not support this until Windows Vista. OpenVPN, however, does not yet have the capability of altering the MTU size on Windows Vista or Windows 7.
See also
Chapter 9, Performance Tuning, which gives some hints and examples on how to optimize the tun-mtu directive.
196
Chapter 7
Troubleshooting network connectivity
This recipe will focus on the type of log messages that are typically seen when the OpenVPN configurations are fine, but the network connectivity is not. In most cases, this is due to a firewall blocking access to either the server or the client. In this recipe, we explicitly block access to the server and then try to connect to it.
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.On the server, explicitly block access to OpenVPN using iptables:
[root@server]# iptables –I INPUT –p udp --dport 1194 –j DROP
3.Next, start the client using the configuration file basic-udp-client.conf:
[root@client]# openvpn --config basic-udp-client.conf
The client will try to connect the server using the UDP protocol. After a while, a timeout will occur because no traffic is getting through and the client will restart:
…TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
…TLS Error: TLS handshake failed
…SIGUSR1[soft,tls-error] received, process restarting
Abort the client and stop the server.
How it works...
When OpenVPN is configured to use the default UDP protocol, the client will wait for an answer from the server for 60 seconds. If no answer was received, the connection is restarted. As we are explicitly blocking UDP traffic, the timeout occurs and the client is never able to connect.
197
Troubleshooting OpenVPN: Configurations
The amount of time the client waits for the connection to start is controlled using the directive: hand-window N
Here, N is the number of seconds to wait for the initial handshake to complete. The default value is 60 seconds.
Of course, the connection can be repaired by removing the firewall rule.
There's more...
One of the major differences between the UDP protocol and the TCP protocol is the way connections are established: every TCP connection is started using a TCP handshake by both the client and the server. If the handshake fails, then the connection is not established. There is no need to wait for traffic coming back from the server, as the connection itself is dropped:
…Attempting to establish TCP connection with openvpnserver:1194 [nonblock]
…TCP: connect to openvpnserver:1194 failed, will try again in 5 seconds: Connection refused
Troubleshooting 'client-config-dir' issues
In this recipe, we will demonstrate how to troubleshoot issues related to the use of the directive client-config-dir. This directive can be used to specify a directory for so-called
CCD files. CCD files can contain OpenVPN directives to assign a specific IP address to a client, based on the client's certificate. Experience has shown that it is easy to misconfigure this directive. In this recipe, we will make one of the common misconfigurations and then show how to troubleshoot it.
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's recipe Server-side routing at hand, as well as the client configuration file basic-udp-client.conf.
How to do it...
1.Append the following lines to the configuration file basic-udp-server.conf:
client-config-dir /etc/openvpn/cookbook/clients ccd-exclusive
Save it as example7-7-server.conf.
198
Chapter 7
2.Make sure the directory /etc/openvpn/cookbook/clients is accessible only to root:
[root@server]# chown root /etc/openvpn/cookbook/clients [root@server]# chmod 700 /etc/openvpn/cookbook/clients
3.Start the server:
[root@server]# openvpn --config example7-7-server.conf
4.Next, start the client using the configuration file basic-udp-client.conf:
[root@client]# openvpn --config basic-udp-client.conf
Then, the client will fail to connect with a message:
…[openvpnserver] Peer Connection Initiated with server-ip:1194
…AUTH: Received AUTH_FAILED control message
The server log file is a bit confusing: first, it mentions that there was a problem reading the CCD file openvpnclient1 but then it states that the client is connected:
…client-ip:42692 TLS Auth Error: --client-config-dir authentication failed for common name 'openvpnclient1' file='/etc/openvpn/cookbook/ clients/openvpnclient1'
…client-ip:42692 [openvpnclient1] Peer Connection Initiated with client-ip:42692
The VPN connection has not been properly initiated, however.
How it works...
The following directives are used by the OpenVPN server to look in the directory
/etc/openvpn/cookbook/clients for a CCD file with the name (CN) of the client certificate:
client-config-dir /etc/openvpn/cookbook/clients ccd-exclusive
The purpose of the second directive, ccd-exclusive, is to only allow clients for which a CCD file is present. If a CCD file for a client is not present, the client will be denied the access.
The name of the client certificate is listed in the server log:
… client-ip:42692 TLS Auth Error: --client-config-dir authentication failed for common name 'openvpnclient1'
But, it can also be retrieved using:
openssl x509 –subject –noout –in client1.crt
Look for the first part starting with /CN= and convert all spaces to underscores.
199
Troubleshooting OpenVPN: Configurations
The OpenVPN server process is running as user nobody and because we have set very restrictive permissions on the directory /etc/openvpn/cookbook/clients, this user is not capable of reading any files in that directory. When the client with certificate openvpnclient1 connects, the OpenVPN server is not capable of reading the CCD file
(even though it might be there). Because of the ccd-exclusive directive, the client is then denied access.
There's more...
In this section, we will explain how to increase the logging verbosity and what some of the most common client-config-dir mistakes are.
More verbose logging
Increasing the verbosity of logging is often helpful when troubleshooting client-config- dir issues. With verb 5 and the right permissions, you will see the following log file entries in the OpenVPN server log:
openvpnclient1/client-ip:39814 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/cookbook/clients/openvpnclient1
If this message is not present in the server log, then it is safe to assume that the CCD file has not been read.
Other frequent client-config-dir mistakes
There are a few frequent client-config-dir mistakes:
A non-absolute path is used to specify the client-config-dir, for example: client-config-dir clients.
This might work in some cases, but you have to be very careful when starting the server or when combining this with directives such as --chroot or --cd. Especially when the --chroot directive is used, all paths, including the absolute path, will be relative to the chroot path.
The CCD file itself must be correctly named, without any extension. This typically tends to confuse the Windows users. Look in the server log to see what the OpenVPN server thinks; the /CN= name is of the client certificate. Also, be aware that
OpenVPN rewrites some characters of the /CN= name, such as spaces. For the full list of characters that will be remapped, see the manual page, section String Types and Remapping.
The CCD file and the full path to it must be readable to the user under which the OpenVPN server process is running (usually nobody).
200