Similar to the inline certificates used in the previous recipe, it is also possible to specify connection blocks. These connection blocks are treated as multiple definitions for remote servers and they are tried in order until a VPN connection is established. The advantage of using a connection block is that for each remote server, server-specific parameters can be specified, such as the protocol (UDP or TCP), the remote port, whether a proxy server should be used, and so on.
In this recipe, we will set up two servers, one listening on a UDP port and the other on a TCP port. We will then configure the OpenVPN client to try the first server using a UDP connection. If the connection cannot be established, the client will attempt to connect to the second server using a TCP connection.
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 server configuration file, example8-9-server.conf, from the Tuning TCP-based connections recipe from Chapter 8, Performance Tuning.
- Start both the servers:
[root@server1]# openvpn --config basic-udp-server.conf [root@server2]# openvpn --config example8-9-server.conf
- Check the log files to check that both the servers have successfully started.
- Create the client configuration file:
client dev tun <connection> remote openvpnserver1.example.com proto udp port 1194 </connection> <connection> remote openvpnserver2.example.com proto tcp port 1194 </connection> remote-cert-tls server 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
- Save it as
example10-4-client.conf. - Start the client:
[root@client]# openvpn --config example10-4-client.conf - After the connection has been established, stop the first OpenVPN process on the server that the client connected to:
[root@server1]# killall openvpnAnd wait for the client to reconnect. After the default timeout period, the client will reconnect to the alternate server using the TCP protocol.
When the OpenVPN client starts up, it attempts to connect to the server specified in the first <connection> block. If that connection fails, it will try the next <connection> block entry and so forth. When an OpenVPN server becomes unavailable or is stopped, the client will automatically restart and try to connect to the first available OpenVPN server again.
The OpenVPN client first parses the global directives, which are specified outside the <connection> blocks. For each block, the global directives are then overruled using block-specific directives. This makes it easier to specify in the <connection> blocks only those parameters that are different for each connection.
Connection blocks, as well as inline certificates, are very handy features to easily distribute OpenVPN configurations using a single file. However, a consequence of these features is that the use of the command line to overrule the directives specified in the configuration file becomes harder, if not impossible. There are a few other things to keep in mind when using connection blocks.
There are only a few directives allowed inside a connection block:
bindandbind-ipv6connect-retry,connect-retry-max, andconnect-timeoutexplicit-exit-notifyfloathttp-proxy,http-proxy-option,http-proxy-retry, andhttp-proxy-timeoutlink-mtuandlink-mtu-extralocal lportmssfixnobindportprotoremoteandrportsocks-proxyandsocks-proxy-retrytun-mtuandtun-mtu-extra
All other directives are considered global and can only be specified once.