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:

             [root@siteA]# openvpn --genkey --secret AtoB.key
             [root@siteA]# openvpn --genkey --secret AtoC.key
             [root@siteA]# 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:

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