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.
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.
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 andexample1-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 filesexample1-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, createexample1-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 theexample1-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.
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:
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.
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.
Chapter 8, Troubleshooting OpenVPN: Routing Issues, in which the most common routing issues are explained.