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:
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.
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.
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 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.
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.
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.
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:
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:
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
Almost there. In the web-based administration tool, go to <navigation>Network|Firewall|Incoming Firewall</navigation> in the menu. UDP port 1195 was specified in our OpenVPN configuration, so access to this port is required. Add this firewall rule:
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
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.
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.
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
/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
systemctl enable openvpn-server@site2.service systemctl start openvpn-server@site2.service
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
/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
systemctl enable openvpn-server@site1.service systemctl restart openvpn-server@site1.service
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
edit crontab with 'crontab -e' */1 * * * * /root/support/scripts/openvpn.connection.tester.sh site2_site1_site2_site1
edit crontab with 'crontab -e' */1 * * * * /root/support/scripts/openvpn.connection.tester.sh site1_site2_site1_site2
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.
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.