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

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
   

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

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

See also

• Chapter 8, Troubleshooting OpenVPN: Routing Issues, in which the most common routing issues are explained.