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.
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.
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 the 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 an
example1-8-serverCtoA.conffile: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
Also, create an
example1-8-serverBtoC.conffile: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 an
example1-8-clientAtoC.conffile: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, 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.
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.
Let's discuss a bit about scalability and routing protocols.
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.
Chapter 7, Troubleshooting OpenVPN - Routing, in which the most common routing issues are explained