Connecting Networks with OpenVPN
OpenVPN provides a secure and robust VPN for connecting both road warriors as well as multiple networks. The solution also gets around the realities of today's Internet:
- Native support in NAT (network address translation) environments
- Native support for dynamic IP addresses
- Robust connection monitoring and automatic reconnections
In other words, OpenVPN can be used in many environments where IPsec just won't work (or work reliably).
In this document, we will provide an implementation guide for a hub and spoke (headquarters and remote office) VPN solution and a mesh VPN solution.
Installation
The first thing you want to do is install the OpenVPN app via Marketplace. Though this app only provides the road warrior implementation for OpenVPN, it also provides a good starting point for network-to-network OpenVPN connections.
Configuring for Hub & Spoke Topology
Selecting the Headquarters Node
In our example, we have selected the system in the main office to be the headquarters node. There are two reasons for this decision:
- The main office has the most robust network connection
- The ClearOS system is connected directly to the Internet
The second point is important. If you find yourself in a situation where a ClearOS system is behind another router (particularly a NAT-based router), know you can still create a network-to-network VPN.
If you see this page, you can start editing it with new content by clicking the pencil icon with the '+' symbol. Be sure to include the proper keywords mechanisms located in this template to ensure that it is properly indexed in the various menus. If there is a particular menu in which you would like to see your article appear, please look at the comments within that menu to understand the basic search terms required.
Create the Secret Key
Login to a command line shell environment and run the following to create the secret key used verify VPN endpoints:
openvpn --genkey --secret /etc/openvpn/static.key
This key must be copied to the other ClearOS system involved in the OpenVPN connection.
Create the Headquarters Configuration
Now that the secret key has been created, it is time to move on to the configuration file. Create a file in /etc/openvpn with the .conf file extension, for example /etc/openvpn/connect_to_remote.conf. Here's a sample configuration:
dev tun port 1195 ifconfig 10.8.222.40 10.8.222.41 route 192.168.11.0 255.255.255.0 comp-lzo keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key
Key | Comment |
---|---|
port | The UDP port for the connection |
ifconfig | The IP addresses are used internally by OpenVPN |
route | This is the LAN of the remote office! |
You can use this configuration file as-is but the route must be changed! Please specify the LAN network range used by the remote office.
Create the Remote Office Configuration
Route LAN-to-LAN Traffic Only
In most scenarios, only traffic destined to the headquarter's LAN needs go through the VPN tunnel. All traffic destined to the Internet would still go through the local ClearOS gateway. The remote office configuration is nearly identical. Create a configuration with the .conf suffix in /etc/openvpn, for example /etc/openvpn/connect_to_headquarters.conf:
dev tun port 1195 remote my-hq.poweredbyclear.com 1195 ifconfig 10.8.222.41 10.8.222.40 route 192.168.22.0 255.255.255.0 comp-lzo keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key
The configuration file is nearly identical, but a few changes are required:
- Specify the hostname or IP of the headquarters system for the remote parameter
- Swap the IPs specified in the ifconfig parameter
- Change the route to match the network range used by headquarters
Route All Traffic
In some circumstances, you may want to route all traffic from the remote office through the headquarters. The configuration is similar, but the following changes are required:
- Remove the route command
- Add the redirect-gateway def1 parameter
The configuration should look similar to:
dev tun port 1195 remote my-hq.poweredbyclear.com 1195 ifconfig 10.8.222.41 10.8.222.4 redirect-gateway def1 comp-lzo keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key
Update Firewall
Almost there. In the web-based administration tool, go to
- UDP port 1195
Additional Networks
You may need to allow all traffic over your network link or perhaps restrict the traffic to certain. This rule would open up the tunnel completely regardless of the source network behind the internal network (ie. multiple subnets):
iptables -I FORWARD -i eth4 -o tun1 -m conntrack --ctstate NEW -j ACCEPT iptables -I FORWARD -i tun1 -o eth4 -m conntrack --ctstate NEW -j ACCEPT
Start/Restart OpenVPN and Troubleshoot
Now it is time to start the OpenVPN software on the headquarters and remote office.
service openvpn restart
There are a lot of little things that can go wrong in the configuration (firewall, routing, internal IPs, hostnames), so double check everything if the VPN connection is not working. The /var/log/messages and /var/log/secure log files can provide clues when troubleshooting.
Configuring for Mesh Topology
In some cases you may want to apply implicit site to site rules to state on both ends where the traffic for the tunnel MUST originate and where it must terminate. This is useful if you require a multiwan site to use one interface only. It is also useful for security purposes by requiring resolution and sourcing from a specific site.
For this example, I will give an interesting scenario in order to explain some of the aspects of the directives. In this situation Site1 is a ClearOS server running behind a NAT gateway provided from the ISP. They have a static address but the ISP can ONLY give that address (ie. 1.1.1.1) to their NATing equipment. We have opened and forwarded the port 1195 UDP. Site 2 has only a DHCP address from their ISP and it changes from time to time. To compensate for this we have added Dynamic DNS and they get their DNS address (ie. site2.poweredbyclear.example.com) from ClearCenter.
Site1
port 1195 proto udp dev tun remote site1.poweredbyclear.example.com float local 192.168.0.100 secret static.key comp-lzo verb 2 ifconfig 172.31.255.1 172.31.255.2 route 10.1.3.0 255.255.255.0 172.31.255.2
- remote - Since site2's address will by dynamic, we will use the hostname as opposed to an IP address. OpenVPN will look up the hostname and then contact that address for the far end of the tunnel.
- float - Since that IP address could change at any time. Once it is established on the legit name we will allow the far end's address to change as long as all the other information is correct.
- local - even through site2 will access us using the public address, we cannot bind OpenVPN to an address that doesn't exist on the box. This is the outside facing External address of this box.
- ifconfig - this side of the tunnel is 172.31.255.1. The other side of the tunnel is 172.31.255.2. This will be reflected in an 'ifconfig'. The 172.31.255.2 is pingable when the tunnel is up.
- route - Here we give the network of the far side of the tunnel and implicitly specify the tunnel address as the destination.
Files and file changes
/etc/openvpn/server/site1.conf /etc/openvpn/server/static.key /etc/clearos/firewall.d/custom: $IPTABLES -I FORWARD -i eth1 -o tun2 -m conntrack --ctstate NEW -j ACCEPT $IPTABLES -I FORWARD -i tun2 -o eth1 -m conntrack --ctstate NEW -j ACCEPT
Configuration changes
systemctl enable openvpn-server@site2.service systemctl start openvpn-server@site2.service
Site2
port 1195 proto udp dev tun remote 1.1.1.1 local site2.poweredbyclear.example.com secret static.key comp-lzo verb 2 ifconfig 172.31.255.2 172.31.255.1 route 10.1.1.0 255.255.255.0 172.31.255.1 route 10.1.2.0 255.255.255.0 172.31.255.1
- remote - Since site1's address is static, we will can specify the IP. We can also use a hostname instead which would allow us to change the ISP and NOT break the configuration.
- float - Notice that this side does NOT specify 'float'. This is because the IP address of the other side is static and should NEVER float. We reject attempts to connect from any address but 1.1.1.1.
- local - Since we are using Dynamic DNS this should work. But this configuration will fail if we come up on the wrong address and Dynamic DNS has not yet updated. For this reason, if you specify a dynamic DNS address in your local line, you should also put in place an openvpn connection script.
- ifconfig - this side of the tunnel is 172.31.255.2. The other side of the tunnel is 172.31.255.1. This will be reflected in an 'ifconfig'. The 172.31.255.1 is pingable when the tunnel is up.
- route - Here we give multiple networks that are available onthe far side of the tunnel and implicitly specify the far end tunnel address as the destination.
Files and file changes
/etc/openvpn/server/site2.conf /etc/openvpn/server/static.key /etc/clearos/firewall.d/custom: $IPTABLES -I FORWARD -i eth1 -o tun2 -m conntrack --ctstate NEW -j ACCEPT $IPTABLES -I FORWARD -i tun2 -o eth1 -m conntrack --ctstate NEW -j ACCEPT
Configuration changes
systemctl enable openvpn-server@site1.service systemctl restart openvpn-server@site1.service
Configuration on both sites
The following is a connection script which runs every minute and restarts the tunnel if the tunnel has failed.
/root/support/scripts/openvpn.connection.tester.sh #!/bin/bash localservice=$1 site=$2 if [ "$site" == "" ]; then /bin/echo Usage: openvpn.connection.tester.sh [Local OpenVPN sitename] [Far side tunnel name or IP] exit 0 fi ping_test=`/bin/ping -c 4 $site | /bin/grep "100% packet loss"` if [ "$ping_test" ]; then /bin/systemctl restart openvpn-server@${localservice}.service else #/bin/echo "Connection good." : fi
chmod 700 /root/support/scripts/openvpn.connection.tester.sh
edit /etc/hosts 172.31.255.1 aws_oregon-aws_singapore.clearos.sudrania.com aws_oregon-aws_singapore 172.31.255.2 aws_singapore-aws_oregon.clearos.sudrania.com aws_singapore-aws_oregon
On Site1
edit crontab with 'crontab -e' */1 * * * * /root/support/scripts/openvpn.connection.tester.sh site2_site1_site2_site1
On Site2
edit crontab with 'crontab -e' */1 * * * * /root/support/scripts/openvpn.connection.tester.sh site1_site2_site1_site2
Troubleshooting
OpenVPN is very verbose in its logging and logs of authentications and errors will be registered to the /var/log/messages log file on the ClearOS side. On the client side it will log what is happening in the details log of the client application. These logs, while very technical, are EXTREMELY helpful in determining issues with the connection. The OpenVPN team has done a fantastic job at creating precise logs which are often the last place you need to go to find out why you cannot connect.
DNS
If you are having issues with DNS on your OpenVPN connection, it can be that you are using an external DNS server to resolve internal hosts or an internal which doesn't resolve external hosts. If you use the ClearOS gateway to resolve the DNS from its cache, you can split the resolution of external and internal domains using this guide.