What are the new features of OpenVPN 2.1 and 2.2?

Inline certificates

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.

Getting ready

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.

How to do it…

1. First, start the server:

   [[email protected]]# openvpn –config basic-udp-server.conf

2. Create the client configuration file:

   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.

3. Then, connect the client:

   [[email protected]]# openvpn –config example12-1-client.conf

How it works…

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.

Connection blocks

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.

Getting ready

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).

How to do it…

1. Start both the servers:

   [[email protected]]# openvpn –config basic-udp-server.conf

   [[email protected]]# openvpn –config example9-7-server.conf

2. Check the log files to check that both the servers have successfully started.
3. 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>

   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.

4. Start the client:

   [[email protected]]# openvpn –config example12-2-client.conf

5. After the connection has been established, stop the first OpenVPN process on the server that the client connected to:

   [[email protected]]# 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.

How it works…

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.

There’s more…

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.

Allowed directives inside connection blocks

There are only a few directives allowed inside a connection block:

• bind
• connect-retry, connect-retry-max, connect-timeout
• float
• http-proxy, http-proxy-option, http-proxy-retry, http-proxy-timeout
• local lport
• nobind
• port
• proto
• remote, rport
• socks-proxy, socks-proxy-retry

All other directives are considered global and can only be specified once.

Pitfalls when mixing TCP and UDP-based setups

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.