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

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.

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
comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody
secret static.key
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.

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 Network|Firewall|Incoming Firewall in the menu. UDP port 1195 was 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. 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.

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

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.

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.

content/en_us/kb_o_connecting_networks_with_openvpn.txt · Last modified: 2017/09/14 13:27 by cjones