Site-to-site VPN routing explained in detail
Introduction
A site-to-site setup is where two (or more) different networks are connected together using one OpenVPN tunnel. In this connection model, devices in one network can reach devices in the other network, and vice versa. The implementation of this is, for as far as Access Server is involved in this, relatively simple. The more difficult part comes when dealing with firewalls and security filtering options, and altering routing tables in routers and Internet gateways, as there are so many of them of various brands and models, that we cannot possibly document all of them. However, routers should all have one thing in common: the ability to route traffic using static routes. With that capability comes the means to send traffic from one network to another, through a gateway system that provides connectivity to the other network. An OpenVPN Access Server with a Linux VPN gateway client forms such a gateway system, to form a bridge between two networks. If your network equipment is then properly adjusted as well, then a site-to-site setup that works transparently for all devices in the two networks can be achieved.
On this page we aim to provide you with a guide that gives insight in how this works, to give you an understanding of how things should be setup to get things working.
Overview of an example site-to-site setup
In the diagram above, the headquarters of our example company are on the right, and there are computers and servers there. One of the servers has the OpenVPN Access Server product installed. All of the computers and servers in that network are connected to a router (the little flat square box with a gear icon) that also provides access to the Internet. On the left is a subsidiary office that has a few computers and servers as well, all connected to their own router that also provides access to the Internet.
One of the servers in the subsidiary office has an OpenVPN client program installed on a Linux operating system, which has an active OpenVPN tunnel connection to the OpenVPN Access Server at the headquarters. In this example site-to-site setup, complete access has been opened up between computers and servers in the headquarters and the subsidiary office. In other words, a user sitting at a computer in the subsidiary office can access the servers at the headquarters as if he were there, thanks to an OpenVPN tunnel connection between the two networks. This OpenVPN tunnel travels over the Internet and its contents are securely encrypted.
Step by step description of how traffic flows
We have created a series of pictures that show how a request from a client computer in the subsidiary office reaches an application server at the headquarter office, and how a response gets sent back. Each step of the process is shown clearly with highlighted lines and relevant network information. Simply go through the images to see a step by step progression. It's worth noting that this type of setup still allows other VPN clients to log on to the OpenVPN Access Server and gain access to any of the devices in these 2 networks. Also, a site-to-site setup need not be limited to one subsidiary network, it can be multiple just as easily.
How to set up OpenVPN Access Server for site-to-site
We are assuming that you already have an OpenVPN Access Server installation working, and that it is installed in your private network behind a router with Internet access and has a private IP address, with port forwarding set up so that it can be reached from the outside, and with appropriate settings made so that it is actually reachable with an OpenVPN client program from the outside. In other words, that you have an OpenVPN Access Server installation that works and lets OpenVPN clients connect. If you haven't installed Access Server yet then please do so first. See the Access Server installation options page for more information.
This section here describes which settings to configure in the OpenVPN Access Server to make a site-to-site setup possible. We are going to assume we're setting up the site-to-site setup as shown in the pictures above, with the subnets used there. If your subnets are different, and they very likely are, you should adjust as needed to match your situation. Important note: it is required for site-to-site to work that the subnets are different in the two networks.
Go to the Admin UI and go to VPN Settings. In the item titled Should VPN clients have access to private subnets set the selection to Yes, using routing (advanced) and in the large text field just below it specify the subnet of the network where your OpenVPN Access Server is located. To compare it to the example site-to-site setup described in the picture series above, this would be 192.168.70.0/24. Make sure the checkbox to allow access from the private subnets is left checked. Now save settings and update running servers.
Next go to User Permissions and create a new user and password. If you use an external authentication system like PAM, RADIUS, or LDAP, make sure the account exists there. You will need to able to actually log in and use this account, of course. On the new user account check the box for auto-login privileges. Then click Show to reveal more settings. Set the Configure VPN gateway option to yes and in the large text field that then appears below it, enter the subnet of the remote network where the Linux OpenVPN client gateway system is going to be installed. In the example site-to-site setup described in the picture series above, this would be 10.0.60.0/24. Now save settings and update running servers.
As far as the OpenVPN Access Server program is concerned, this is what completes a site-to-site setup configuration on this end. There remain a number of things still to configure. The router in the network where the Access Server is needs to be made aware that there are additional subnets in existence, and that they can be reached by contacting the private IP address of the Access Server installation. In our example network, the OpenVPN Access Server has an IP of 192.168.70.222. It also has a VPN client subnet of 172.16.0.0/20 and it will eventually have a site-to-site connection running to subnet 10.0.60.0/24. To make the router aware of these extra subnets look up the documentation of your router device, and look up how to add static routes. These are the static routes that need to be added:
- Network 172.16.0.0 with subnet mask 255.255.240.0 through gateway 192.168.70.222
- Network 10.0.60.0 with subnet mask 255.255.255.0 through gateway 192.168.70.222
You will note that we are specifying a subnet mask. Most routing equipment wants it specified in this manner instead of using CIDR format with the /24 and /20 and so on. There are tables that you can look up online that you can use to easily convert one to the other.
With the new static routes in place, whenever traffic now arrives at the router that has as a destination an IP address somewhere in 172.16.0.0/20 or 10.0.60.0/24, it will know that it should forward this to the OpenVPN Access Server at IP address 192.168.70.222. It will then forward it to where it needs to go, as it knows how to contact those two subnets.
How to set up the OpenVPN Linux Gateway client
We prefer using a Linux operating system to handle the role of a VPN client that also serves as gateway. We prefer Ubuntu LTS on a virtual machine or dedicated hardware. We simply have the best experiences with it, and there are simple tools available on Linux that are free and easy to install and use to diagnose any problems that may come up. Also Linux is free to use and can run on very light-weight equipment. Even a Raspberry Pi3 or such can handle this task, and there are also embedded systems that can handle it. Equipment aside, if you have a Linux operating system with an OpenVPN client that can connect to the OpenVPN Access Server, and you can enable something called IP forwarding, then you should be able to get an OpenVPN Linux Gateway client up and running fairly easily. You do not need the install the OpenVPN Access Server program itself on this Linux client system.
What you do need is the OpenVPN open source client program for Linux. On Ubuntu you can install this with the command apt-get install openvpn. With the client program now installed, it is going to check for any *.conf files in the /etc/openvpn/ directory and at system startup try to connect them and keep them connected. What we need next is to obtain the auto-login connection profile for the user account created for site-to-site connectivity, and save it in the /etc/openvpn/ directory. To do that we need to get the file first:
Go to the OpenVPN Access Server's client UI using a web browser, click the connect dropdown menu and switch it to login. Enter the user name and password of the user account you created for site-to-site connectivity and click go. You will be presented with a list of files available for this user account. Locate the auto-login profile and download it. It will be called client.ovpn.
Transfer this client.ovpn file to your Linux client system (with SCP or WinSCP or copying and pasting contents of the file in a text editor like nano) and place it in the /etc/openvpn/ directory. Rename the file to something like headquarters.conf. The filename is not particular important, but the extension must end with .conf for the OpenVPN daemon to pick it up. Now reboot the Linux client operating system. It should now automatically connect and you should be able to see this connection appear on the OpenVPN Access Server's Current Users overview.
Next enable IP forwarding on the Linux client system. IP forwarding is the function in an operating system that allows it to accept an incoming network packet on one network interface, and if the destination is on another network, to forward it there. This is what you need when packets coming in from your network need to go to the VPN tunnel, or vice versa. On Ubuntu you can do this fairly easily by opening /etc/sysctl.conf with a text editor like nano, and uncommenting the line #net.ipv4.ip_forward=1. Uncommenting means you remove the # character. Then exit and save the file. Now reboot the Linux client operating system.
As far as the OpenVPN Linux Client gateway system is concerned, this is what completes a site-to-site setup configuration on this end. There remains now only one thing left to configure. The router in the network where the Linux Gateway client is needs to be made aware that there are additional subnets in existence, and that they can be reached by contacting the private IP address of the Linux Gateway client installation. In our example network, the OpenVPN Linux client gateway system has an IP of 10.0.60.55. It also is part of the VPN client subnet of 172.16.0.0/20 that exist on the Access Server and it will now have a site-to-site connection running to subnet 192.168.70.0/24. To make the router aware of these extra subnets look up the documentation of your router device, and look up how to add static routes. Please note that you should add these static routes on the router in the subsidiary office network where the OpenVPN Linux Gateway client system is, not on the network where the Access Server is. These are the static routes that need to be added:
- Network 172.16.0.0 with subnet mask 255.255.240.0 through gateway 10.0.60.55
- Network 192.168.70.0 with subnet mask 255.255.255.0 through gateway 10.0.60.55
As with the static routes on the other router, you will note that we are specifying a subnet mask. Most routing equipment wants it specified in this manner instead of using CIDR format with the /24 and /20 and so on. There are tables that you can look up online that you can use to easily convert one to the other.
With the new static routes in place, whenever traffic now arrives at the router that has as a destination an IP address somewhere in 172.16.0.0/20 or 192.168.70.0/24, it will know that it should forward this to the OpenVPN Linux Gateway client at IP address 10.0.60.55. It will then forward it to where it needs to go, as it knows how to contact those two subnets.
Troubleshooting
With the above setup steps followed, both the OpenVPN Access Server and the OpenVPN Linux Gateway client should be operating perfectly. There are however a great number of possible problems that can be encountered with surrounding equipment. For example there can be firewalls on the client and server computers that block traffic from "unknown" subnets. On cloud networks like Amazon AWS, security groups and source checking can be a factor in blocking traffic. Furthermore, static routes could have been set up wrong so that they work from LAN to WAN interface, so that it tries to send the traffic to the Internet instead of staying purely on the LAN side of the router. Unfortunately there are too many possible issues that lie completely outside of the OpenVPN Access Server and its connected OpenVPN Linux Gateway client to document them all. Instead, we therefore have tried to provide the means to diagnose the connection yourself.
We have a troubleshooting guide that will help in determining the point where traffic breaks down. That will then lead to conclusions to effectively resolve the problem.