OpenVPN has (limited) built-in support for automatic failover and load-balancing: if the connection to one OpenVPN server cannot be established, then the next configured server is chosen. The remote-random directive can be used to load-balance many OpenVPN clients across multiple OpenVPN servers. In this recipe, we will set up two OpenVPN servers and then use the remote-random directive to have a client choose either one of the two servers.
Note that OpenVPN does not offer transparent failover, in which case the existing connections are transparently migrated to another server. Transparent failover is much harder to achieve with a VPN setup (not just OpenVPN), as the secure session keys need to be migrated from one server to the other as well. This is currently not possible with OpenVPN.
We will use the following network layout:
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, as well as the client configuration file, basic-udp-client.conf at hand.
- Start both servers:
[root@server1]# openvpn --config basic-udp-server.conf [root@server2]# openvpn --config basic-udp-server.conf
Check the log files to see that both the servers have successfully started.
Note that we can use the exact same configuration file on both servers. By using masquerading, the VPN clients will appear to come from either
server1orserver2. - Set up masquerading on both servers:
[root@server1]# iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE [root@server2]# iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
- Create the client configuration file:
client proto udp remote openvpnserver1.example.com 1194 remote openvpnserver2.example.com 1194 remote-random dev tun nobind remote-cert-tls server tls-auth /etc/openvpn/cookbook/ta.key 1 ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/client1.crt key /etc/openvpn/cookbook/client1.key
- Save it as
example10-2-client.conf. - Start the client:
[root@client]# openvpn --config example10-2-client.conf
The OpenVPN client will randomly choose which server to connect to.
After the connection has been established, stop the first OpenVPN process on the server that the client connected to:
[root@server1]# killall openvpn
And wait for the client to reconnect. After the default timeout period, the client will reconnect to an alternate server.
When the OpenVPN client starts up and remote-random is specified, it randomly picks a server from the list of available remote servers. If the VPN connection to this server cannot be established, it will pick the next server from the list, and so on. When the VPN connection is dropped, for example, due to a failing server, the OpenVPN client will try to reconnect after a default timeout period. In the server configuration file used in the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, the timeout period is configured using the keepalive option.
When setting up a failover OpenVPN solution there are many things to consider, some of which are outlined here.
It is also possible to mix TCP and UDP-based setups by specifying the protocol type with the remote directive:
remote openvpnserver1.example.com 1194 udp remote openvpnserver2.example.com 1194 tcp
It is much handier to use connection blocks in this case. The use of connection blocks is explained later in this chapter.
There is one major advantage when using a TCP-based setup in combination with a failover solution. If the OpenVPN server to which a client is connected is unavailable, the TCP connection will fail almost immediately. This leads to a very short timeout period after which the OpenVPN client will try to reconnect. With a UDP-based setup, the client cannot so easily detect whether the server is unavailable and must first wait for the keepalive timeout to pass.
A question that is asked from time to time is whether it is possible to configure OpenVPN to also support automatic reverting: a second OpenVPN instance is set up to provide a failover solution. When the main OpenVPN server is unavailable, the backup instance takes over. However, when the main OpenVPN server comes back online, the clients are not automatically reconnected to the main server. For this, a client reset (or server reset of the second OpenVPN instance) is required. It is possible to achieve this using scripting but it depends largely on what type of connectivity is considered acceptable: it takes some time for an OpenVPN client to detect when the remote server is not responding and to reconnect. The VPN connectivity will be intermittent in such a setup. Especially when the network connection to the main OpenVPN server is not stable, this can lead to very low availability.
A quick and dirty method to have all clients revert back to the first server is to use the management interface on the second server and disconnect all clients.
- The Server-side routing recipe from Chapter 2, Client-server IP-only Networks, which explains the basic setup of OpenVPN
- The Connection blocks recipe, which shows an alternate and more flexible method for supporting multiple servers in a single client configuration file