OpenVPN 2 Cookbook

Chapter 1. Point-to-Point Networks

In this chapter, we will cover:

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
3-way routing

Shortest setup possible

This recipe will explain the shortest setup possible when using OpenVPN. For this setup two computers are used 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 full 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.0 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1 and the client was running Windows XP SP3 and OpenVPN 2.1.1.

How to do it...

We launch the server (listening)-side OpenVPN process for the TUN-style network:
```
[root@server]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
--dev tun
```
Tip
The above command should be entered as a single line. The character '\' is used to denote the fact that the command continues on the next line.
Then we 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.
Next, we stop the tunnel by pressing the F4 function key in the Command window and we restart both ends of the tunnel using the TAP device:

We launch the server (listening)-side OpenVPN process for the TAP-style network:

    [root@server]# openvpn --ifconfig 10.200.0.1 255.255.255.0 \
            --dev tap

Then we 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 is 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 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: after the initial handshake, the first TUN or TAP-Win32 device is configured with IP address 10.200.0.2. It expects the remote end (Peer address) to be 10.200.0.1. After this, the VPN is established.

In case of a TAP-style network, the server configures the first available TAP device with the IP address 10.200.0.01 and netmask 255.255.255.0. Similarly, the client is configured with IP address 10.200.0.2 and netmask 255.255.255.0.

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 the data that is sent over the VPN tunnel can be read!

There's more...

Using the TCP protocol

In the previous example, we chose the UDP protocol. For this example, it would not have made any difference if we had chosen the TCP protocol, provided that we do that on the server side (the side without --remote):

[root@server]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
    –-dev tun --proto tcp-server

And also on the client side:

[root@server]# openvpn --ifconfig 10.200.0.2 10.200.0.1 \
    --dev tun --proto tcp-client

Forwarding non-IP traffic over the tunnel

It is now 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 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 a shared secret key is used to encrypt the traffic between the client and the server.

Getting ready

How to do it...

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

    [root@server]# openvpn --genkey --secret secret.key

We transfer this key to the client side over a secure channel (for example, using scp).

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

   [root@server]# openvpn --ifconfig 10.200.0.1 10.200.0.2 \
            --dev tun --secret secret.key

Then, we 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 established:

How it works...

This example works exactly as the very first: 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 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!

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 those 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.0 or higher on two computers. Make sure that the computers are connected over a network. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Windows XP SP3 and OpenVPN 2.1.1.

How to do it...

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

    [root@server]# openvpn \
            --ifconfig 10.200.0.1 10.200.0.2 \
            --dev tun --secret secret.key 0 \
            --verb 7

Then we 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 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 can see that each one of them is mirrored on the client and the server side.

How it works...

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

$ openvpn –-genkey –-secret secret.key

An OpenVPN static key file is 2048 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 following parameter is used: tls-auth ta.key.

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

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

How to do it...

Launch the server (listening)-side OpenVPN process:

   [root@server]# openvpn \
            --ifconfig 10.200.0.1 10.200.0.2 \
            --dev tun -–auth none

Then launch the client-side OpenVPN process:

   [root@client]# openvpn \
            --ifconfig 10.200.0.2 10.200.0.1 \
            --dev tun –-auth none\
            --remote openvpnserver.example.com

The connection is established with two warning messages in 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 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:

Set up the connection as outlined.

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

[root]@client]# tcpdump -w -I eth0 -s 0 host openvpnserver \
           | strings

Now, send some text across the tunnel, using something like nc (Netcat). First, launch nc on the server side:
```
 [server]$ nc -l 31000
```

On the client side, launch nc in client mode and type the words hello and goodbye.

 [client]$ nc 10.200.0.1 3100
         hello
         goodbye

In the tcpdump window, you should now see:

Routing

Point-to-point style 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 it 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 use the following network layout:

How to do it...

First we establish the connection, but we also make sure OpenVPN daemonized itself:

    [root@server]# openvpn \
            --ifconfig 10.200.0.1 10.200.0.2 \
            --dev tun --secret secret.key \
            --daemon --log /tmp/openvpnserver.log

Then we 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

The connection is established:

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

Now we add routing:

On the server side, we add a static route:

    [root@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 you have IP traffic forwarding enabled. On Linux this can be achieved using the following:
```
       [root@client]# sysctl -w net.ipv4.ip_forward=1
```
- Make sure that on the Windows client on the client-side LAN 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 that this setting does not survive a reboot of the system.
  Here 192.168.4.5 is the LAN IP address of the OpenVPN client.

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

          [root@server]# 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

And next the LAN IP of a machine on the OpenVPN client LAN:

          [root@server]# 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 file /etc/sysctl.cnf.
```
 net.ipv4.ip_forward = 1
```
We also need to make sure that on the client LAN there is a route back to the OpenVPN server. 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
```
where 192.168.4.5 is the LAN IP address of the OpenVPN client.

There's more...

Routing issues

On the openvpn-users mailing list, a large number of the problems reported have to do with routing issues. Most of them have little to do with the OpenVPN itself but more with understanding the routing and the flow of packets over the network. Chapter 8, Troubleshooting OpenVPN: Routing Issues, 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.

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

How to do it...

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

Save this file as example1-6-client.conf.

We launch the server (listening)-side OpenVPN process on a non-standard port:

    [root@server]# openvpn \
            --ifconfig 10.200.0.1 10.200.0.2 \
            --dev tun --secret secret.key \
            --port 11000

Then we 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:

How it works...

The command-line and the configuration file are read and parsed from left to right. This means that most options that are specified before the configuration file can be overruled by entries in that file. Similarly, 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 that case, it is also possible to specify the option before specifying the --config directive.

There's more...

Here is another example to show 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' from the client.conf configuration file overruled the --verb 0 as specified on the command line. However, with the following command line:

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

Then the connection log shows the following:

… NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

This shows all the other messages that have been muted.

OpenVPN 2.1 specifics

Some of the newer features of OpenVPN 2.1 deviate slightly from this principle, notably the <connection> blocks and the inline certificates. See Chapter 12, OpenVPN 2.1 specifics for more details.

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

We use the following network layout:

Install OpenVPN 2.0 or higher on two computers. Make sure that the computers are connected over a network. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1 and the client was running Fedora 13 Linux and OpenVPN 2.1.1. We'll use the secret.key file from the OpenVPN Secret keys recipe here.

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

How to do it...

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
persist-tun
persist-key
keepalive 10 60
ping-timer-rem

verb 3
daemon
log-append /tmp/openvpn.log

Save it as example1-7-server.conf.

On the client side, we 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
persist-tun
persist-key
keepalive 10 60
ping-timer-rem

verb 3
daemon
log-append /tmp/openvpn.log

Save it as example1-7-client.conf.

We start the tunnel on both ends:

    [root@server]# openvpn --config example1-7-server.conf

And:

    [root@client]# openvpn --config client.conf

Now our site-to-site tunnel is established.

Check the log files on both the client and server, to verify that the connection has been established.
After the connection comes up, the machines on the LANs behind both 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 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

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

The OpenVPN process runs as user nobody, group nobody, after the initial connection is established. Even if somebody is able to take control of the OpenVPN process itself he would still only be user nobody and not root. Note that on some Linux distributions the group nogroup is used instead.
The persist-tun and persist-key options are used to ensure that the connection comes back up 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, Multi-client TUN-style Networks), the traffic is recognizable as OpenVPN traffic due to the initial TLS handshake.

3-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 a redundant routing so that all sites are connected even if one of the tunnels is disrupted.

Getting ready

We use the following network layout:

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. In this recipe, the tunnel endpoints were running CentOS 5 Linux or Fedora 13 Linux and OpenVPN 2.1.1. Make sure that the routing (IP forwarding) is configured on all the OpenVPN endpoints.

How to do it...

We generate three static keys:

    [root@siteA]# openvpn –-genkey –-secret AtoB.key
          [root@siteA]# openvpn –-genkey –-secret AtoC.key
          [root@siteA]# openvpn –-genkey –-secret BtoC.key

Transfer these keys to all endpoints over a secure channel (for example, using scp).

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
Next, create example1-8-serverCtoA.conf:
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
and example1-8-serverBtoC.conf:
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
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
Also, create 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
and finally the 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:

[root@siteB]# openvpn --config example1-8-serverBtoA.conf
[root@siteB]# openvpn --config example1-8-serverBtoC.conf
[root@siteC]# openvpn --config example1-8-serverCtoA.conf

These are followed by the connector tunnels:

[root@siteA]# openvpn --config example1-8-clientAtoB.conf
[root@siteA]# openvpn --config example1-8-clientAtoC.conf
[root@siteC]# openvpn --config example1-8-clientCtoB.conf

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

How it works...

It can clearly be 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:

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

There are always 2 routes to each remote network.

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
[…]

A route:

Via the "direct" tunnel to site B; this route has the lowest metric
Via an indirect tunnel: first to site C and then onward 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 are 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...

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

Filter reviews by

All

Amazon verified reviews

Ralph Saunders Nov 19, 2016

This book was exactly what I was looking for. David Parks review of the book is exactly what I would write about it. The book is vpery easy to read, with working real world examples that the author walks you through and all of the examples are follew by an explaination of what is going on. One reviewer complained that it did not include how to configure firewalls, but that is not fair at all. The author provides enough of an explaination of what is going on that configuring a firewall is no problem at all. If you are looking to set up a VPN using OpenVPN, this is the book you'll want to have.

Amazon Verified review

David Parks Jun 16, 2011

The cookbook style means they laid out the book as a series of example scenarios which address the majority of openvpn configurations and questions. But they lay out the examples in a very logical way, starting from simple to more complex, so the whole thing can be read both as a book and referenced for specific cases.There's no fluff, you dive right in chapter one, paragraph one, no one's going to baby you in this book. But the beginning chapters provide a very simple setup, so you don't need to know much more than basic sys-admin stuff to follow it clearly.The scenarios are well designed, and easy to follow. But the book never stops at just a how-to description. In each case there is an easy to follow how to, then an expanded description of what is going on in the how-to section, followed by more information about tertiary situations and questions that may naturally arise from the particular situation being discussed.I had many questions along the way and in every case the answer was already thought of by the author and answered in the next paragraph. I was impressed with the authors attention to detail.This is a great book for someone learning. It won't take long to read (I did it in a focused 24hr period), it's not very verbose, but provides exactly the information necessary, and is structured such that you can skip irrelevant sections easily and safely.

Mark McIntyre Apr 01, 2014

working through the book and trying the exercises as they are demonstrated in the book have been very helpful. i would recommend to any who want to learn the basics (and a bit more) of openvpn.

Sentinel Jun 21, 2011

If you're still at the "how do I install" OpenVPN stage, this book is not for you just yet. The author freely admits that in the "Who this book is for", so I do consider it a point against it. You should also have some networking knowledge as the author suggests.Right after you have installed and played with OpenVPN a little, this book is awesome. I had what I thought was a complete setup, but this book brought out a whole note card full of other things for me to look at. It is very concisely written. The author has also distilled the common problems and solutions found in user groups. I will happily be an even heavier user of OpenVPN after reading this book.

DK Jan 29, 2015

There's all you need to setup VPN proficiently. From the simplest things to the advanced performance tuning. I really appreciate the author's effort.