OpenVPN Cookbook - Second Edition

5 (4 reviews total)
By Jan Just Keijser
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Point-to-Point Networks

About this book

OpenVPN provides an extensible VPN framework that has been designed to ease site-specific customization, such as providing the capability to distribute a customized installation package to clients, and supporting alternative authentication methods via OpenVPN’s plugin module interface.

This book provides you with many different recipes to help you set up, monitor, and troubleshoot an OpenVPN network. You will learn to configure a scalable, load-balanced VPN server farm that can handle thousands of dynamic connections from incoming VPN clients. You will also get to grips with the encryption, authentication, security, extensibility, and certifications features of OpenSSL.

You will also get an understanding of IPv6 support and will get a demonstration of how to establish a connection via IPv64. This book will explore all the advanced features of OpenVPN and even some undocumented options, covering all the common network setups such as point-to-point networks and multi-client TUN-style and TAP-style networks. Finally, you will learn to manage, secure, and troubleshoot your virtual private networks using OpenVPN 2.4.

Publication date:
February 2017
Publisher
Packt
Pages
400
ISBN
9781786463128

 

Chapter 1.  Point-to-Point Networks

In this chapter, we will cover the following:

  • The shortest setup possible

  • OpenVPN secret keys

  • Multiple secret keys

  • Plaintext tunnel

  • Routing

  • Configuration files versus the command line

  • IP-less configurations

  • Complete site-to-site setup

  • Three-way routing

  • Using IPv6

 

Introduction


The recipes in this chapter will provide an introduction to configuring OpenVPN. They are based on a point-to-point type of network, meaning that only a single client can connect at a given time.

A point-to-point network is very useful when connecting to a small number of sites or clients. It is easier to set up, as no certificates or public key infrastructure (PKI) is required. Also, routing is slightly easier to configure as no client-specific configuration files containing --iroute statements are required.

The drawbacks of a point-to-point network are as follows:

  • The lack of having perfect forward secrecy-a key compromise may result in a total disclosure of previous sessions

  • The secret key must exist in plaintext form on each VPN peer

 

The shortest setup possible


This recipe will explain the shortest setup possible when using OpenVPN. For this setup, you require two computers that are connected over a network (LAN or Internet). We will use both a TUN-style network and a TAP-style network and will focus on the differences between them. A TUN device is used mostly for VPN tunnels where only IP traffic is used. A TAP device allows all the Ethernet frames to be passed over the OpenVPN tunnel, hence providing support for non-IP based protocols, such as IPX and AppleTalk.

While this may seem useless at first glance, it can be very useful to quickly test whether OpenVPN can connect to a remote system.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 Pro 64bit and OpenVPN 2.3.10.

How to do it...

Here are the steps that you need to follow:

  1. Launch the server-side (listening) OpenVPN process for the TUN-style network:

              [[email protected]]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun
    

    Note

    The preceding command should be entered as a single line. The character \ is used to denote the fact that the command continues on the next line.

  2. Then, launch the client-side OpenVPN process:

             [WinClient] C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
                --ifconfig 10.200.0.2 10.200.0.1 --dev tun \
                --remote openvpnserver.example.com
    

    The following screenshot shows how a connection is established:

    As soon as the connection is established, we can ping the other end of the tunnel.

  3. Next, stop the tunnel by pressing the F4 function key in the command window and restart both ends of the tunnel using the TAP device.

  4. Launch the server-side (listening) OpenVPN process for the TAP-style network:

    [[email protected]]# openvpn --ifconfig 10.200.0.1 255.255.255.0 \
            --dev tap
    
  5. Then launch the client-side OpenVPN process:

              [WinClient] C:\>"
    \Program Files\OpenVPN\bin\openvpn.exe" \
                --ifconfig 10.200.0.2 255.255.255.0 --dev tap \
                --remote openvpnserver.example.com
    

The connection will now be established and we can again ping the other end of the tunnel.

How it works...

The server listens on UDP port 1194, which is the OpenVPN default port for incoming connections. The client connects to the server on this port. After the initial handshake, the server configures the first available TUN device with the IP address 10.200.0.1 and it expects the remote end (the Peer address) to be 10.200.0.2.

The client does the opposite: after the initial handshake, the first TUN or TAP-Win32 device is configured with the IP address 10.200.0.2. It expects the remote end (the Peer address) to be 10.200.0.1. After this, the VPN is established.

Note

Notice the warning:

******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext

Here, the data is not secure: all of the data that is sent over the VPN tunnel can be read!

There's more...

Let's look at a couple of different scenarios and check whether they would modify the process.

Using the TCP protocol

In the previous example, we chose the UDP protocol. It would not have made any difference if we had chosen the TCP protocol, provided that we had done that on the server side (the side without --remote) as well as the client side. The following is the code for doing this on the server side:

[[email protected]]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
    --dev tun --proto tcp-server

Here's the code for the client side:

[[email protected]]# openvpn --ifconfig 10.200.0.2 10.200.0.1 \
    --dev tun --proto tcp-client --remote openvpnserver.example.com

Forwarding non-IP traffic over the tunnel

With the TAP-style interface, it is possible to run non-IP traffic over the tunnel. For example, if AppleTalk is configured correctly on both sides, we can query a remote host using the aecho command:

aecho openvpnserver
22 bytes from 65280.1: aep_seq=0. time=26. ms
22 bytes from 65280.1: aep_seq=1. time=26. ms
22 bytes from 65280.1: aep_seq=2. time=27. ms

A tcpdump -nnel -i tap0 command shows that the type of traffic is indeed non-IP-based AppleTalk.

 

OpenVPN secret keys


This recipe uses OpenVPN secret keys to secure the VPN tunnel. It is very similar to the previous recipe, but this time, we will use a shared secret key to encrypt the traffic between the client and the server.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 64 bit and OpenVPN 2.3.10.

How to do it...

  1. First, generate a secret key on the server (listener):

              [[email protected]]# openvpn --genkey --secret secret.key
    
  2. Transfer this key to the client side over a secure channel (for example, using scp).

  3. Next, launch the server-side (listening) OpenVPN process:

              [[email protected]]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun --secret secret.key
    
  4. Then, launch the client-side OpenVPN process:

             [WinClient] C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
               --ifconfig 10.200.0.2 10.200.0.1 \
               --dev tun --secret secret.key \
               --remote openvpnserver.example.com
    

The connection is now established, as shown in the following screenshot:

How it works...

This example works exactly as the first one: the server listens to the incoming connections on UDP port 1194. The client connects to the server on this port. After the initial handshake, the server configures the first available TUN device with the IP address 10.200.0.1 and it expects the remote end (Peer address) to be 10.200.0.2. The client does the opposite.

There's more...

By default, OpenVPN uses two symmetric keys when setting up a point-to-point connection:

  • A cipher key to encrypt the contents of the packets being exchanged.

  • An HMAC key to sign packets. When packets arrive that are not signed using the appropriate HMAC key, they are dropped immediately. This is the first line of defense against a "denial-of-service" attack.

  • The same set of keys are used on both ends and both keys are derived from the file specified using the --secret parameter.

An OpenVPN secret key file is formatted as follows:

# 
# 2048 bit OpenVPN static key 
# 
-----BEGIN OpenVPN Static key V1----- 
<16 lines of random bytes> 
-----END OpenVPN Static key V1----- 

From the random bytes, the OpenVPN Cipher and HMAC keys are derived. Note that these keys are the same for each session.

See also

  • The next recipe, Multiple secret keys, will explain the format of secret keys in detail

 

Multiple secret keys


As stated in the previous recipe, OpenVPN uses two symmetric keys when setting up a point-to-point connection. However, it is also possible to use shared yet asymmetric keys in point-to-point mode. OpenVPN will use four keys in this case:

  • A cipher key on the client side

  • An HMAC key on the client side

  • A cipher key on the server side

  • An HMAC key on the server side

The same keying material is shared by both sides of the point-to-point connection, but the keys that are derived for encrypting and signing the data are different for each side. This recipe explains how to set up OpenVPN in this manner and how the keys can be made visible.

Getting ready

For this recipe, we use the secret.key file from the previous recipe. Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 64 bit and OpenVPN 2.3.10. We'll use the secret.key file from the OpenVPN secret keys recipe here.

How to do it...

  1. Launch the server-side (listening) OpenVPN process with an extra option to the --secret parameter and with more verbose logging:

              [[email protected]]# openvpn \
                --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun --secret secret.key 0 \
                --verb 7
    
  2. Then launch the client-side OpenVPN process:

             [WinClient] C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
               --ifconfig 10.200.0.2 10.200.0.1 \
               --dev tun --secret secret.key 1\
               --remote openvpnserver \
               --verb 7
    

The connection will be established with a lot of debugging messages.

If we look through the server-side messages (searching for crypt), we can find the negotiated keys on the server side. Note that the output has been reformatted for clarity:

... Static Encrypt: 
Cipher 'BF-CBC' initialized with 128 bit key 
... Static Encrypt:  
CIPHER KEY: 80797ddc 547fbdef 79eb353f 2a1f3d1f 
... Static Encrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication 
... Static Encrypt:  
HMAC KEY: c752f254 cc4ac230 83bd8daf 6141e73d 844764d8 
... Static Decrypt:  
Cipher 'BF-CBC' initialized with 128 bit key 
... Static Decrypt:  
CIPHER KEY: 8cf9abdd 371392b1 14b51523 25302c99 
... Static Decrypt:  
Using 160 bit message hash 'SHA1' for HMAC authentication 
... Static Decrypt:  
HMAC KEY: 39e06d8e 20c0d3c6 0f63b3e7 d94f35af bd744b27 

On the client side, we will find the same keys but the "Encrypt" and "Decrypt" keys would have been reversed:

... Static Encrypt:  
Cipher 'BF-CBC' initialized with 128 bit key 
... Static Encrypt:  
CIPHER KEY: 8cf9abdd 371392b1 14b51523 25302c99 
... Static Encrypt:  
Using 160 bit message hash 'SHA1' for HMAC authentication 
... Static Encrypt:  
HMAC KEY: 39e06d8e 20c0d3c6 0f63b3e7 d94f35af bd744b27 
... Static Decrypt:  
Cipher 'BF-CBC' initialized with 128 bit key 
... Static Decrypt:  
CIPHER KEY: 80797ddc 547fbdef 79eb353f 2a1f3d1f 
... Static Decrypt:  
Using 160 bit message hash 'SHA1' for HMAC authentication 
... Static Decrypt:  
HMAC KEY: c752f254 cc4ac230 83bd8daf 6141e73d 844764d8 

If you look at the keys carefully, you will see that each one of them is mirrored on the client and the server side.

How it works...

OpenVPN derives all the keys from the static.key file, provided there is enough entropy (randomness) in the file to reliably generate four keys. All the keys generated using the following will have enough entropy:

$ openvpn --genkey --secret secret.key

An OpenVPN static key file is 2,048 bits in size. The cipher keys are each 128 bits, whereas the HMAC keys are 160 bits each, for a total of 776 bits. This allows OpenVPN to easily generate four random keys from the static key file, even if a cipher is chosen that requires a larger initialization key.

There's more...

The same secret key files are used in a client/server setup when the tls-auth ta.key parameter is used.

See also

  • The Setting up the public and private keys recipe from Chapter 2, Client-server IP-only Networks, in which the tls-auth key is generated in a very similar manner

 

Plaintext tunnel


In the very first recipe, we created a tunnel in which the data traffic was not encrypted. To create a completely plain text tunnel, we also disable the HMAC authentication. This can be useful when debugging a bad connection, as all traffic over the tunnel can now easily be monitored. In this recipe, we will look at how to do this. This type of tunnel is also useful when doing performance measurements, as it is the least CPU-intensive tunnel that can be established.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Fedora 22 Linux and OpenVPN 2.3.10.

As we are not using any encryption, no secret keys are needed.

How to do it...

  1. Launch the server-side (listening) OpenVPN process:

             [[email protected]]# openvpn \
                --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun --auth none
    
  2. Then launch the client-side OpenVPN process:

             [[email protected]]# openvpn \
                --ifconfig 10.200.0.2 10.200.0.1 \
                --dev tun --auth none\
                --remote openvpnserver.example.com
    
  3. The connection will be established with the following two warning messages as the output:

    
    ... ******* WARNING *******: null cipher specified, no encryption will be 
                          used
    
    
    ... ******* WARNING *******: null MAC specified, no authentication will 
                          be used
    
    

How it works...

With this setup, absolutely no encryption is performed. All of the traffic that is sent over the tunnel is encapsulated in an OpenVPN packet and then sent as is.

There's more...

To actually view the traffic, we can use tcpdump; follow these steps:

  1. Set up the connection as outlined.

  2. Start tcpdump and listen on the network interface, not the tunnel interface itself:

           [[email protected]]# tcpdump -l -w -  -i eth0 -s 0 host 
               openvpnserver | strings
    
  3. Now, send some text across the tunnel, using something like nc (Netcat). First, launch nc on the server side:

           [server]$ nc -l 31000
    
  4. On the client side, launch the nc command in client mode and type hello and goodbye:

           [client]$ nc 10.200.0.1 3100
             hello
             goodbye
    
  5. In the tcpdump window, you should now see the following:

  6. Press Ctrl + C to terminate tcpdump as well as nc.

 

Routing


The point-to-point type of networks are great if you want to connect two networks together over a static, encrypted tunnel. If you only have a small number of endpoints (fewer than four), then routing is far easier than using a client/server setup as described in Chapter 2, Client-server IP-only Networks.

Getting ready

For this recipe, we will use the following network layout:

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 64 bit and OpenVPN 2.3.10. We'll use the secret.key file from the OpenVPN secret keys recipe here.

How to do it...

  1. First, establish the connection, but also make sure OpenVPN has daemonized itself:

              [[email protected]]# openvpn \
                --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun --secret secret.key \
                --daemon --log /tmp/openvpnserver.log
    
  2. Then, launch the client-side OpenVPN process:

              [client]$ openvpn \
                --ifconfig 10.200.0.2 10.200.0.1 \
                --dev tun --secret secret.key \
                --remote openvpnserver \
                --daemon --log /tmp/openvpnclient.log
    
  3. The connection is established:

          [server]$ tail -1 /tmp/openvpnserver.log
               Initialization Sequence Completed
    

Now we add routing:

  1. On the server side, we add a static route:

          [[email protected]]# route add -net 192.168.4.0/24 gw 10.200.0.2
    
  2. On the client side, we need to do two things:

    Make sure that you have the IP traffic forwarding enabled. On Linux, this can be achieved using the following:

                 [[email protected]]# sysctl -w net.ipv4.ip_forward=1
    

    Note

    Note that this setting does not survive a reboot of the system.

    On the Windows client on the client-side LAN, make sure there is a route back to the OpenVPN server:

                C:> route add 10.200.0.0 mask 255.255.255.0 192.168.4.5
    

    Note

    Here, 192.168.4.5 is the LAN IP address of the OpenVPN client.

  3. From the server, we can now ping machines on the client LAN. First, ping the LAN IP of the OpenVPN client:

            [[email protected]]# ping -c 2 192.168.4.5
            PING 192.168.4.5 (192.168.4.5) 56(84) bytes of data.
            64 bytes from 192.168.4.5: icmp_seq=0 ttl=64 time=31.7 ms
            64 bytes from 192.168.4.5: icmp_seq=1 ttl=64 time=31.3 ms
           --- 192.168.4.5 ping statistics ---
            2 packets transmitted, 2 received, 0% packet loss, time   
            1000ms
           rtt min/avg/max/mdev = 31.359/31.537/31.716/0.251 ms, pipe 2
    
  4. Then, ping the LAN IP of a machine on the OpenVPN client LAN:

              [[email protected]]# ping -c 2 192.168.4.164
            [server]$ ping -c 2 192.168.4.164
           PING 192.168.4.164 (192.168.4.164) 56(84) bytes of data.
           64 bytes from 192.168.4.164: icmp_seq=0 ttl=63 time=31.9 ms
           64 bytes from 192.168.4.164: icmp_seq=1 ttl=63 time=31.4 ms
           --- 192.168.4.164 ping statistics ---
           2 packets transmitted, 2 received, 0% packet loss, time 
            1001ms
           rtt min/avg/max/mdev = 31.486/31.737/31.989/0.308 ms, pipe 2
    

How it works...

In our network setup, the LAN we want to reach is behind the OpenVPN client, so we have to add a route to the server:

[server]$ route add -net 192.168.4.0/24 gw 10.200.0.2

On the client side, we need to do two things:

  • Make sure that the routing is enabled. If you want routing to remain enabled after a reboot, edit the /etc/sysctl.cnf file:

            net.ipv4.ip_forward = 1 
    
  • We also need to make sure that there is a route back to the OpenVPN server on the client LAN. This can be done by adding a route to the LAN gateway or by adding a static route to each of the machines on the client LAN. In this recipe, we added a route to a Windows client that is in the same LAN as the OpenVPN client:

            C:> route add 10.200.0.0 mask 255.255.255.0 192.168.4.5
    

Here, 192.168.4.5 is the LAN IP address of the OpenVPN client.

There's more...

Let's discuss a bit about routing issues and how to automate the setup.

Routing issues

On the OpenVPN users mailing list, a large number of the problems that are reported have something to do with routing issues. Most of them have little to do with OpenVPN itself, but more with understanding the routing and the flow of packets over the network. Chapter 7, Troubleshooting OpenVPN - Routing, provides some recipes to diagnose and fix the most common routing problems.

Automating the setup

It is also possible to add the appropriate routes when the tunnel first comes up. This can be done using the --route statement:

[server]$ openvpn \
    --ifconfig 10.200.0.1 10.200.0.2 \
    --dev tun --secret secret.key \
    --daemon --log /var/log/openvpnserver-1.5.log \
    --route 192.168.4.0 255.255.255.0

Note that on the client LAN, the route back to the server still has to be set manually.

See also

  • The Three-way routing recipe, later on in this chapter, where a more complicated setup using three remote sites is explained

  • Chapter 7, Troubleshooting OpenVPN - Routing

 

Configuration files versus the command line


Most recipes in this book can be carried out without using configuration files. However, in most real-life cases, a configuration file is much easier to use than a lengthy command line. It is important to know that OpenVPN actually treats configuration file entries and command-line parameters identically. The only difference is that all command-line parameters start with a double dash (--) whereas the configuration file entries do not. This makes it very easy to overrule the configuration file entries using an extra command-line parameter.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 64 bit and OpenVPN 2.3.10. In this recipe, we'll use the secret.key file from the OpenVPN secret keys recipe.

How to do it...

  1. Create a configuration file based on an earlier recipe:

           dev tun
           port 1194
           ifconfig 10.200.0.1 10.200.0.2
           secret secret.key 
           remote openvpnserver.example.com
           verb 3
    
  2. Save this file as example1-6-client.conf.

  3. Launch the server-side (listening) OpenVPN process on a non-standard port:

              [[email protected]]# openvpn \
                --ifconfig 10.200.0.1 10.200.0.2 \
                --dev tun --secret secret.key \
                --port 11000
    
  4. Then launch the client-side OpenVPN process and add an extra command-line parameter:

              [WinClient] C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
                --config client.conf \
                --port 11000
    

The connection is established:

Jan 11 16:14:04 2016 UDPv4 link local (bound): [undef]
Jan 11 16:14:04 2016 UDPv4 link remote: [AF_INET]172.16.8.1:11000
Jan 11 16:14:06 2016 Peer Connection Initiated with [AF_INET]172.16.8.1:11000
Jan 11 16:14:12 2016 TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/d=up
Jan 11 16:14:12 2016 Initialization Sequence Completed

How it works...

The command line and the configuration file are read and parsed from left to right and top to bottom. This means that most options that are specified before the configuration file can be overruled by the entries in that file. Similarly, the options specified after the following directive overrule the entries in that file:

--config client.conf

Hence, the following option overruled the line "port 1194" from the configuration file:

--port 11000

However, some options can be specified multiple times, in which case, the first occurrence "wins." In such a case, it is also possible to specify the option before specifying the --config directive.

There's more...

Here is another example that shows the importance of the ordering of the command-line parameters:

C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
    --verb 0 \
    --config client.conf \
    --port 11000

This produces the exact same connection log as shown before. The verb 3 command from the client.conf configuration file overruled --verb 0, as specified on the command line. However, refer to the following command line:

C:\>"\Program Files\OpenVPN\bin\openvpn.exe" \
    --config client.conf \
    --port 11000 \
    --verb 0

Using this command line, the connection log will remain entirely empty, yet the VPN connection will be in functioning mode.

Exceptions to the rule

Some of the newer features of OpenVPN deviate slightly from this principle, most notably the <connection> blocks and the inline certificates. Some people prefer to write the following command:

remote openvpnserver.example.com 1194

They prefer this instead of the following command:

port 1194
remote openvpnserver.example.com

The downside of this notation is that this is translated as a connection block by OpenVPN. For connection blocks, it is not possible to overrule the port using --port 11000.

 

Complete site-to-site setup


In this recipe, we set up a complete site-to-site network, using most of the built-in security features that OpenVPN offers. It is intended as a "one-stop-shop" example of how to set up a point-to-point network.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Fedora 22 Linux and OpenVPN 2.3.10. We'll use the secret.key file from the OpenVPN secret keys recipe here.

We will use the following network layout:

Make sure routing (IP forwarding) is configured on both the server and client.

How to do it...

  1. Create the server configuration file:

            dev tun 
            proto udp 
            local  openvpnserver.example.com 
            lport  1194 
            remote openvpnclient.example.com 
            rport  1194 
     
            secret secret.key 0 
            ifconfig 10.200.0.1 10.200.0.2 
            route 192.168.4.0 255.255.255.0 
     
            user  nobody 
            group nobody  # use "group nogroup" on some distros 
            persist-tun 
            persist-key 
            keepalive 10 60 
            ping-timer-rem 
     
            verb 3 
            daemon 
            log-append /tmp/openvpn.log 
    
  2. Save it as example1-7-server.conf.

  3. On the client side, create the configuration file:

            dev tun 
            proto udp 
            local  openvpnclient.example.com 
            lport  1194 
            remote openvpnserver.example.com 
            rport  1194 
     
            secret secret.key 1 
            ifconfig 10.200.0.2 10.200.0.1 
            route 172.31.32.0 255.255.255.0 
     
            user  nobody 
            group nobody  # use "group nogroup" on some distros 
            persist-tun 
            persist-key 
            keepalive 10 60 
            ping-timer-rem 
     
            verb 3 
            daemon 
            log-append /tmp/openvpn.log 
    
  4. Save it as example1-7-client.conf.

  5. Then start the tunnel on both ends. The following is for the server end:

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

    Here's the code for the client end:

              [[email protected]]# openvpn --config example1-7-client.conf
    

    Now our site-to-site tunnel is established.

  6. Check the log files on both the client and server to verify that the connection has been established.

  7. After the connection comes up, the machines on the LANs behind both the end points can be reached over the OpenVPN tunnel. For example, when we ping a machine on the client-side LAN from the server, we will see the following:

How it works...

The client and server configuration files are very similar:

  • The server listens only on one interface and one UDP port

  • The server accepts connections only from a single IP address and port

  • The client has these options mirrored

Here is the set of configuration options:

user  nobody 
group nobody 
persist-tun 
persist-key 
keepalive 10 60 
ping-timer-rem 

These options are used to make the connection more robust and secure, as follows:

The OpenVPN process runs as user nobody and group nobody after the initial connection is established. Even if somebody is able to take control of the OpenVPN process itself, he or she would still only be nobody and not root. Note that on some Linux distributions, nogroup is used instead.

The persist-tun and persist-key options are used to ensure that the connection comes back automatically if the underlying network is disrupted. These options are necessary when using user nobody and group nobody (or group nogroup).

The keepalive and ping-timer-rem options cause OpenVPN to send a periodic "ping" message over the tunnel to ensure that both ends of the tunnel remain up and running.

There's more...

This point-to-point setup can also be used to evade restrictive firewalls. The data stream between the two endpoints is not recognizable and very hard to decipher. When OpenVPN is run in client/server (see Chapter 2, Client-server IP-only Networks), the traffic is recognizable as OpenVPN traffic due to the initial TLS handshake.

See also

  • The last recipe in this chapter, Using IPv6, which builds upon this recipe by adding support for IPv6 traffic

  • Chapter 7, Troubleshooting OpenVPN - Routing, in which the most common routing issues are explained

 

Three-way routing


For a small number (less than four) of fixed endpoints, a point-to-point setup is very flexible. In this recipe, we set up three OpenVPN tunnels between three sites, including routing between the endpoints. By setting up three tunnels, we create redundant routing so that all the sites are connected even if one of the tunnels is disrupted.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Fedora 22 Linux and OpenVPN 2.3.10.

We will use the following network layout:

Make sure that the routing (IP forwarding) is configured on all the OpenVPN endpoints.

How to do it...

  1. We generate three static keys:

              [[email protected]]# openvpn --genkey --secret AtoB.key
              [[email protected]]# openvpn --genkey --secret AtoC.key
              [[email protected]]# openvpn --genkey --secret BtoC.key
    
  2. Transfer these keys to all the endpoints over a secure channel (for example, using scp).

  3. Create the server (listener) configuration file named example1-8-serverBtoA.conf:

            dev tun 
            proto udp 
            port  1194 
     
            secret AtoB.key 0 
            ifconfig 10.200.0.1 10.200.0.2 
     
            route 192.168.4.0 255.255.255.0 vpn_gateway 5 
            route 192.168.6.0 255.255.255.0 vpn_gateway 10 
            route-delay 
     
            keepalive 10 60 
            verb 3 
    
  4. Next, create an example1-8-serverCtoA.conf file:

            dev tun 
            proto udp 
            port  1195 
     
            secret AtoC.key 0 
            ifconfig 10.200.0.5 10.200.0.6 
     
            route 192.168.4.0 255.255.255.0 vpn_gateway 5 
            route 192.168.5.0 255.255.255.0 vpn_gateway 10 
            route-delay 
     
            keepalive 10 60 
            verb 3 
    
  5. Also, create an example1-8-serverBtoC.conf file:

            dev tun 
            proto udp 
            port  1196 
     
            secret BtoC.key 0 
            ifconfig 10.200.0.9 10.200.0.10 
     
            route 192.168.4.0 255.255.255.0 vpn_gateway 10 
            route 192.168.6.0 255.255.255.0 vpn_gateway 5 
            route-delay 
     
            keepalive 10 60 
            verb 3 
    
  6. Now, create the client (connector) configuration files, example1-8-clientAtoB.conf:

            dev tun 
            proto udp 
            remote siteB 
            port  1194 
     
            secret AtoB.key 1 
            ifconfig 10.200.0.2 10.200.0.1 
     
            route 192.168.5.0 255.255.255.0 vpn_gateway 5 
            route 192.168.6.0 255.255.255.0 vpn_gateway 10 
            route-delay 
     
            keepalive 10 60 
            verb 3 
    
  7. Also, create an example1-8-clientAtoC.conf file:

            dev tun 
            proto udp 
            remote siteC 
            port  1195 
     
            secret AtoC.key 1 
            ifconfig 10.200.0.6 10.200.0.5 
     
            route 192.168.5.0 255.255.255.0 vpn_gateway 10 
            route 192.168.6.0 255.255.255.0 vpn_gateway 5 
            route-delay 
     
            verb 3 
    
  8. And finally, create example1-8-clientCtoB.conf:

            dev tun 
            proto udp 
            remote siteB 
            port  1196 
     
            secret BtoC.key 1 
            ifconfig 10.200.0.10 10.200.0.9 
     
            route 192.168.4.0 255.255.255.0 vpn_gateway 10 
            route 192.168.5.0 255.255.255.0 vpn_gateway 5 
            route-delay 
     
            keepalive 10 60 
            verb 3 
    

First, we start all the listener tunnels:

[[email protected]]# openvpn --config example1-8-serverBtoA.conf
[[email protected]]# openvpn --config example1-8-serverBtoC.conf
[[email protected]]# openvpn --config example1-8-serverCtoA.conf

These are followed by the connector tunnels:

[[email protected]]# openvpn --config example1-8-clientAtoB.conf
[[email protected]]# openvpn --config example1-8-clientAtoC.conf
[[email protected]]# openvpn --config example1-8-clientCtoB.conf

And with that, our three-way site-to-site network is established.

How it works...

It can be clearly seen that the number of configuration files gets out of hand too quickly. In principle, two tunnels would have been sufficient to connect three remote sites, but then there would have been no redundancy.

With the third tunnel and with the configuration options, there are always two routes available for each remote network:

route 192.168.5.0 255.255.255.0 vpn_gateway 5
route 192.168.6.0 255.255.255.0 vpn_gateway 10
route-delay
keepalive 10 60

For example, site A has two routes to site B (LAN 192.168.5.0/24), as seen from the following routing table:

[siteA]$ ip route show
[...]
192.168.5.0/24 via 10.200.0.1 dev tun0  metric 5
192.168.5.0/24 via 10.200.0.5 dev tun1  metric 10
[...]

These are the two routes to site A:

  • Via the "direct" tunnel to site B; this route has the lowest metric

  • Via an indirect tunnel: first to site C and then to site B; this route has a higher metric and is not chosen until the first route is down

This setup has the advantage that if one tunnel fails, then after 60 seconds, the connection and its corresponding routes are dropped and restarted. The backup route to the other network then automatically takes over and all three sites can reach each other again.

When the direct tunnel is restored, the direct routes are also restored and the network traffic will automatically choose the best path to the remote site.

There's more...

Let's discuss a bit about scalability and routing protocols.

Scalability

In this recipe, we connect three remote sites. This results in six different configuration files that provide the limitations of the point-to-point setup. In general, to connect n number of possible sites with full redundancy, you will have n * ( n - 1 ) configuration files. This is manageable for up to four sites, but after that, a server/multiple-client setup, as described in the next chapters, is much easier.

Routing protocols

To increase the availability of the networks, it is better to run a routing protocol, such as RIPv2 or OSPF. Using a routing protocol, the failing routes are discovered much faster, resulting in less network downtime.

See also

  • Chapter 7, Troubleshooting OpenVPN - Routing, in which the most common routing issues are explained

 

Using IPv6


In this recipe, we extend the complete site-to-site network recipe to include support for IPv6.

Getting ready

Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Fedora 22 Linux and OpenVPN 2.3.10. We'll use the secret.key file from the OpenVPN secret keys recipe here.

We will use the following network layout:

How to do it...

  1. Create the server configuration file:

            dev tun 
            proto udp 
            local  openvpnserver.example.com 
            lport  1194 
            remote openvpnclient.example.com 
            rport  1194 
     
            secret secret.key 0 
            ifconfig 10.200.0.1 10.200.0.2 
            route 192.168.4.0 255.255.255.0 
     
            tun-ipv6 
            ifconfig-ipv6 2001:db8:100::1 2001:db8:100::2 
     
            user  nobody 
            group nobody  # use "group nogroup" on some distros 
            persist-tun 
            persist-key 
            keepalive 10 60 
            ping-timer-rem 
     
            verb 3 
            daemon 
            log-append /tmp/openvpn.log 
    
  2. Save it as example1-9-server.conf.

  3. On the client side, create the configuration file:

            dev tun 
            proto udp 
            local  openvpnclient.example.com 
            lport  1194 
            remote openvpnserver.example.com 
            rport  1194 
     
            secret secret.key 1 
            ifconfig 10.200.0.2 10.200.0.1 
            route 172.31.32.0 255.255.255.0 
     
            tun-ipv6 
            ifconfig-ipv6 2001:db8:100::2 2001:db8:100::1 
     
            user  nobody 
            group nobody  # use "group nogroup" on some distros 
            persist-tun 
            persist-key 
            keepalive 10 60 
            ping-timer-rem 
     
            verb 3 
    
  4. Save it as example1-9-client.conf.

  5. Then start the tunnel on both ends The following is for the server end:

              [[email protected]]# openvpn --config example1-9-server.conf
    

    This is the code for the client end:

              [[email protected]]# openvpn --config example1-9-client.conf
    

    Now our site-to-site tunnel is established.

  6. After the connection comes up, the machines on the LANs behind both end points can be reached over the OpenVPN tunnel. Notice that the client OpenVPN session is running in the foreground.

  7. Next, ping the IPv6 address of the server endpoint to verify that IPv6 traffic over the tunnel is working:

             [client]$ ping6 -c 4 2001:db8:100::1
             PING 2001:db8:100::1(2001:db8:100::1) 56 data bytes
             64 bytes from 2001:db8:100::1: icmp_seq=1 ttl=64 time=7.43 ms
             64 bytes from 2001:db8:100::1: icmp_seq=2 ttl=64 time=7.54 ms
             64 bytes from 2001:db8:100::1: icmp_seq=3 ttl=64 time=7.77 ms
             64 bytes from 2001:db8:100::1: icmp_seq=4 ttl=64 time=7.42 ms
             --- 2001:db8:100::1 ping statistics ---
             4 packets transmitted, 4 received, 0% packet loss, time 3005ms
             rtt min/avg/max/mdev = 7.425/7.546/7.778/0.177 ms
    
  8. Finally, abort the client-side session by pressing Ctrl + C. The following screenshot lists the full client-side log:

How it works...

Both client and server configuration files are very similar to the ones from the Complete site-to-site setup recipe, with the addition of the following two lines:

tun-ipv6 
ifconfig-ipv6 2001:db8:100::2 2001:db8:100::1 

This enables IPv6 support, next to the default IPv4 support.

Also, in the client configuration, the options daemon and log-append are not present, hence all of the OpenVPN output is sent to the screen and the process continues running in the foreground.

There's more...

Let's talk a bit about log file errors and the IPv6-only tunnel.

Log file errors

If we take a closer look at the client-side connection output, we will see a few error messages after pressing Ctrl +  C , most notably the following:

RTNETLINK answers: operation not permitted 

This is a side-effect when you use the user nobody option to protect an OpenVPN setup, and it often confuses new users. What happens is this:

OpenVPN starts as root, opens the appropriate tun device, and sets the right IPv4 and IPv6 addresses on this tun interface.

For extra security, OpenVPN then switches to nobody, dropping all the privileges associated with root.

When OpenVPN terminates (in our case, by pressing  Ctrl +  C ), it closes the access to the tun device and tries to remove the IPv4 and IPv6 addresses assigned to that device. At this point, the error messages appear, as nobody is not allowed to perform these operations.

Upon termination of the OpenVPN process, the Linux kernel closes the tun device and all the configuration settings are removed.

In this case, these error messages are harmless, but in general, one should pay close attention to the warning and error messages that are printed by OpenVPN.

IPv6-only tunnel

With OpenVPN 2.3, the IPv6-only tunnel is required to always enable IPv4 support. From OpenVPN 2.4 on, it is possible to set up an IPv6-only connection.

See also

The recipe Complete site-to-site setup, earlier in this chapter, in which an IPv4-only site-to-site setup is explained in detail.

The last recipe of Chapter 6, Troubleshooting OpenVPN - Configurations, which explains how to interpret the OpenVPN log files in detail.

About the Author

  • Jan Just Keijser

    Jan Just Keijser is an open source professional from Utrecht, the Netherlands. He has a wide range of experience in IT, ranging from providing user support, system administration, and systems programming to network programming. He has worked for various IT companies since 1989. He was an active USENET contributor in the early 1990s and has been working mainly on Unix/Linux platforms since 1995.

    Currently, he is employed as a senior scientific programmer in Amsterdam, the Netherlands, at Nikhef, the institute for subatomic physics from the Dutch Foundation for Fundamental Research on Matter (FOM). He works on multi-core and many-core computing systems and grid computing as well as smartcard applications. His open source interests include all types of virtual private networking, including IPSec, PPTP, and, of course, OpenVPN. In 2004, he discovered OpenVPN and has been using it ever since.

    His first book was OpenVPN 2 Cookbook by Packt Publishing in 2011, followed by Mastering OpenVPN, also by Packt Publishing, in 2015.

    Browse publications by this author

Latest Reviews

(4 reviews total)
it seems to be a good book.
I didn't think about anything. This mandatory text box is annoying.
Informative and detailed...

Recommended For You

Python Machine Learning - Third Edition

Applied machine learning with a solid foundation in theory. Revised and expanded for TensorFlow 2, GANs, and reinforcement learning.

By Sebastian Raschka and 1 more
C# 8.0 and .NET Core 3.0 – Modern Cross-Platform Development - Fourth Edition

Learn the fundamentals, practical applications, and latest features of C# 8.0 and .NET Core 3.0 from expert teacher Mark J. Price.

By Mark J. Price
Python Parallel Programming Cookbook - Second Edition

Implement effective programming techniques in Python to build scalable software that saves time and memory

By Giancarlo Zaccone
Networking Fundamentals

Become well-versed with basic networking concepts such as routing, switching, and subnetting, and prepare for the Microsoft 98-366 exam

By Gordon Davies