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.
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. The client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the configuration file, basic-udp-server.conf, from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks.
- 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 tun nobind remote-cert-tls server tls-auth /etc/openvpn/cookbook/ta.key ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/client1.crt key /etc/openvpn/cookbook/client1.key
Note the lack of the second parameter for
tls-auth. Save it asexample6-4-client.conffile. - Start the client:
[root@client]# openvpn --config example6-4-client.confThe client log will show no errors, but the connection will not be established either. In the server log we'll find the following:
... 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,
client1, is connecting using the wrongtls-authparameter and the connection is refused.
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 at the end of the configuration line:
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 client1: 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.
- The Multiple secret keys recipe from Chapter 1, Point-to-Point Networks, in which the format and usage of the OpenVPN secret keys is explained in detail