ClearOS Documentation

×

Warning

301 error for file:https://clearos.com/dokuwiki2/lib/exe/css.php?t=dokuwiki&tseed=82873f9c9a1f5784b951644363f20ef8

User Tools

Site Tools


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 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).

This document has been edited to remove “comp-lzo” from all configs due to the VORACLE vulnerability
Also note that it has to be removed from both ends of a site-to-site connection.

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.

Site-to-Site Configuration

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.

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
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody
secret static.key
cipher AES-256-CBC
KeyComment
portThe UDP port for the connection
ifconfigThe IP addresses are used internally by OpenVPN
routeThis 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.

You can also add a line

remote my-remote.poweredbyclear.com

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

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
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:

  • 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

If the site you are connecting to has MultiWAN you can repeat the “remote” line for each WAN IP/FQDN and OpenVPN will try them all until it connects.

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
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

If you want to mitigate the SWEET32 vulnerability (the warning in the logs), add the line

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.

Update Firewall

Almost there. In the web-based administration tool, go to Network|Firewall|Incoming Firewall 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:

  • UDP port 1195

Additional Networks

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.

Start/Restart OpenVPN

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

or

systemctl enable openvpn@connect_to_remote.service
systemctl restart openvpn@connect_to_remote.service

Connection Monitoring Script

Sometimes you may need to restart the connection if it does not automatically reconnect. There is the outline of a connection monitoring script here.

Appendix: Alternate implicit site to site

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 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
  • 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.

Site2

port 1195
proto udp
dev tun
remote 1.1.1.1
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
  • 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.

Troubleshooting

Log Files

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.

Cannot connect to server

Go to the OpenVPN configuration page in the web-based administration tool Service Status 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:

  • /var/log/messages
  • /var/log/system
  • /var/log/secure

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.

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.

content/en_us/kb_o_connecting_networks_with_openvpn.txt · Last modified: 2019/05/08 03:22 by nickh

https://clearos.com/dokuwiki2/lib/exe/indexer.php?id=content%3Aen_us%3Akb_o_connecting_networks_with_openvpn&1558403154