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.
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 6 Linux and OpenVPN 2.3.11, and the client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the client configuration file, basic-udp-client.conf, handy along with the configuration file, basic-udp-server.conf, from the Server-side routing recipe, from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.conf.
- 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.conffile:tun-mtu 1400
Save it as
example6-5-client.conf. - Start the client and look at the client log:
[root@client]# openvpn --config example6-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 ... /sbin/ip link set dev tun0 up mtu 1400 ... /sbin/ip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255 ... Initialization Sequence CompletedThere are a few warnings when the tunnel comes up, but the connection is initialized.
- It is possible to send traffic over the link, which we can verify using the
pingcommand:[client]$ ping -c 2 10.200.0.1 PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data. 64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=30.6 ms 64 bytes from 10.200.0.1: icmp_seq=2 ttl=64 time=30.7 ms - However, consider when sending larger packets, for example:
[client]$ ping -s 1450 10.200.0.1In such a case, 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.
The MTU 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.
On the Windows platform, it is not easy to change the MTU setting for the Tap-Win32 adapter that OpenVPN uses. The tun-mtu directive 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.
- Chapter 9, Performance Tuning, which gives some hints and examples on how to optimize the
tun-mtudirective