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 use the terms headquarters and remote office. Just know that this is just simple terminology used for this implementation guide. You can create hub and spoke VPN solutions (many remote offices connecting to a single headquarters) as well as mesh VPN solutions (where each site connects to all other sites).
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.
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 keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key cipher AES-256-CBC
|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.
if you want, then either end can initiate the connection. If you do this, it would be better if the remote office also had a static WAN IP
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 ifconfig 10.8.222.41 10.8.222.40 route 192.168.22.0 255.255.255.0 keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key cipher AES-256-CBC
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 ifconfig 10.8.222.41 10.8.222.40 redirect-gateway def1 keepalive 10 60 persist-key persist-tun user nobody group nobody secret static.key cipher AES-256-CBC
to the configs at both ends of the tunnel. If you do it at one end only, the tunnel will not come up.
Almost there. In the web-based administration tool, go to <navigation>Network|Firewall|Incoming Firewall</navigation> in the menu. Port 1195 was explicitly specified and UDP was imlicitly 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. In this case add multiple “route” lines to the tunnel configuration file for each remote network you want to connect to.
Now it is time to set to auto-start and start the OpenVPN software on the headquarters and remote office but it is ideally done through the webconfig just by restarting OpenVPN. Alternatively, from the command line do:
systemctl enable openvpn@connect_to_headquarters.service systemctl restart openvpn@connect_to_headquarters.service
systemctl enable openvpn@connect_to_remote.service systemctl restart openvpn@connect_to_remote.service
Sometimes you may need to restart the connection if it does not automatically reconnect. There is the outline of a connection monitoring script here.
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. 18.104.22.168) 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 site2.poweredbyclear.example.com float local 192.168.0.100 secret static.key verb 2 ifconfig 172.31.255.1 172.31.255.2 route 10.1.3.0 255.255.255.0 172.31.255.2 cipher AES-256-CBC
port 1195 proto udp dev tun remote 22.214.171.124 local site2.poweredbyclear.example.com secret static.key 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 cipher AES-256-CBC
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.
Go to the OpenVPN configuration page in the web-based administration tool and ensure the service is started. If the status says Stopped, click on the Start. If the services fails to start, you can get more information from the logs. The following log files may contain clues:
Log file contents are available for display and/or download via the web-based administration tool. You will need to install (if you haven't done so already) the Log Viewer app from the Marketplace.
If the server is also your gateway to the Internet, navigate to Incoming Firewall and ensure port 1195 is open.
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.