





















































To ease the deployment of OpenVPN configuration, public and private key files, a new feature is available to include all of them in a single file. This is done by integrating the contents of the ca, cert, key, and optionally the tls-auth file into the client configuration file itself. So, in this recipe, we will set up such a configuration file and use it to connect to our standard OpenVPN server.
We use the following network layout:
Set up the client and server certificates. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file basic-udp-server.conf (download code- ch:2) at hand.
[root@server]# openvpn --config basic-udp-server.conf
client
proto udp
remote openvpnserver.example.com
port 1194
dev tun
nobind
ca [inline]
cert [inline]
key [inline]
tls-auth [inline] 1
<ca>
-----BEGIN CERTIFICATE-----
# insert base64 blob from ca.crt
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
# insert base64 blob from client1.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
# insert base64 blob from client1.key
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
# insert ta.key
-----END OpenVPN Static key V1-----
</tls-auth>
Insert the contents of the ca.crt, client1.crt, client1.key and ta.key files in the configuration. Save it as example12-1-client.conf.
[root@client]# openvpn --config example12-1-client.conf
When OpenVPN parses the configuration directives, ca, cert, key, and tls-auth (and dh for server configuration files), and it finds the value [inline], then an XML-like block must be present later in the configuration file. The contents of this XML-like block are then read and treated in the same manner as when a file is specified. When all the required configuration files or blocks are present, the connection is established.
Note that it is not required to treat all of the above configuration directives in the same manner. It is also possible to only specify an [inline] block for the CA certificate file, as this file tends to be static for all the clients.
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 use the following network layout:
Set up the client and server certificates. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (download code- ch:2) at hand, as well as the server configuration file, example9-7-server.conf (download code- ch:9).
[root@server1]# openvpn --config basic-udp-server.conf
[root@server2]# openvpn --config example9-7-server.conf
client
dev tun
<connection>
remote openvpnserver1.example.com
proto udp
port 1194
</connection>
<connection>
remote openvpnserver2.example.com
proto tcp
port 1194
</connection>
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
ns-cert-type server
Save it as example12-2-client.conf.
[root@client]# openvpn --config example12-2-client.conf
[root@server1]# killall openvpn
And 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 new features introduced in OpenVPN 2.1. 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:
All other directives are considered global and can only be specified once.
Connection blocks make it very easy to mix TCP and UDP-based setups. The downside is that the global parameters specified in the configuration file must be valid for both the TCP and UDP-based setups. This rules out the use of the commonly-used fragment directive, as well as a few other tuning parameters. It is expected that this shortcoming of <connection> blocks will be addressed in a future version of OpenVPN.