Host to LAN Tunnel HowTo
About
This document provides an example of how to connect to a network using OpenVPN with certificates for authentication, and a username/password pair for an extra layer of security.
Introduction
Picture a road traffic monitoring system with a control center and a number of mobile stations that should be able to connect to the control center over a public network to report vehicle data and receive configuration information.
.-------. .-------. | HostA | | HostB | '---+---' '---+---' .2| |.2 '---. .---' 10.0.1.0/24 | | 10.0.2.0/24 .1| |.1 .--+--+--. .---------. | | OpenVPN L3 Tunnel | | | Server +=========================+ Client1 | | | ssl0 ssl0 | | '----+---' 10.0.3.1 '----+----' Public IP: | | 198.18.19.20 | .--.-. | | ( ( )__ | '------------(_, \ ) ,_)----------' Control Center '-'--`--' | Mobile Stations | .--------. `-------+ |-. | ClientN| | '--------' | '--------'
Client1
- represents a mobile station, running the OpenVPN client who wants to reach HostA and HostB in the control center.
Server
- is the gateway to the control center as well as the device where the OpenVPN server is running.
The example assumes that certificates and CA-certificates have already been imported to the client and server respectively.
Server Tunnel Setup
On the server device, begin by setting up the basic tunnel.
example:/#> configure example:/config/#> tunnel ssl 0 example:/config/tunnel/ssl-0/#> server example:/config/tunnel/ssl-0/#> method cert example:/config/tunnel/ssl-0/#> certificate server1 example:/config/tunnel/ssl-0/#> ca-certificate server1 example:/config/tunnel/ssl-0/#> type tun example:/config/tunnel/ssl-0/#> pool start 10.0.3.100 num 100 netmask 255.255.255.0 example:/config/tunnel/ssl-0/#> leave example:/#>
A few comments on the above sequence:
-
The certificate and CA-certificate both have the label
server1
but they are two different certificates. When importing a PKCS-bundle into WeOS, all included certificates and keys are assigned the same label. WeOS makes sure the correct certificate is used -
The tunnel type is set to
tun
as we have no use for link layer (Ethernet) signalling in this scenario -
The
pool
setting enables dynamic IP address assignment of connecting clients from the specified range. The tunnel is now ready and waiting for connections
Ensure that the tunnel ssl0 is listed as UP
using:
example:/#> show tunnel ssl
Next, assign an IP address to the local tunnel interface.
example:/#> configure example:/config/#> iface ssl0 example:/config/iface-ssl0/#> inet static 10.0.3.1/24 example:/config/iface-ssl0/#> leave example:/#>
Verify that the interface named ssl0
is UP and has the IP
address/netmask which was just configured:
example:/#> show iface
Client Tunnel Setup
On the client device, begin by setting up the basic tunnel.
example:/#> configure example:/config/#> tunnel ssl 0 example:/config/iface-ssl0/#> no server example:/config/iface-ssl0/#> method cert example:/config/iface-ssl0/#> certificate client1 example:/config/iface-ssl0/#> ca-certificate client1 example:/config/iface-ssl0/#> type tun example:/config/iface-ssl0/#> peer 198.18.19.20 example:/config/iface-ssl0/#> leave example:/#>
The client config is similar to that of the server. The main differences are:
- The no server command is used inform WeOS that this is a client.
- Different certificates are used.
- A peer command identifies the public IP address of the server.
This should be enough to make the tunnel come up (it might take a few seconds). Run:
example:/#> show tunnel ssl example:/#> show iface
And verify that tunnel ssl0 is UP and the corresponding interface has received an IP address from the pool configured on the server.
It should now be possible to ping the server across the tunnnel:
example:/#> ping count 3 10.0.3.1
Server Hardening
With the tunnel operational we can now “harden” it with additional authentication.
On the server device, start by defining a username and password to be used for client identification.
example:/#> configure example:/config/#> aaa example:/config/aaa/#> local-db 1 example:/config/aaa/local-db-1/#> username example:/config/aaa/local-db-1/#> client1 qwerty example:/config/aaa/local-db-1/#> leave example:/#>
This sets up username client1 and associates it with the password qwerty. In this case the credentials are stored on the local device but other options are available. See [Placeholder: AAA context documentation] for details.
Now add a user authentication method to the tunnel configuration.
example:/#> configure example:/config/#> tunnel ssl 0 example:/config/tunnel/ssl-0/#> aaa-method local-db 1 example:/config/tunnel/ssl-0/#> leave example:/#>
This configuration change causes the OpenVPN server to restart. The client eventually detects that it has lost connection (it might take up to a minute) and try to re-connect, but will not be allowed to do so as it is not yet configured with the correct user credentials.
Client Hardening
On the client device, check tunnel status.
example:/#> show tunnel ssl
The ssl0 tunnel should be DOWN. If it is still up, it means the broken connection due to the server restart has not been detected yet. (See the Keepalive option for more details on this mechanism.)
Now add the username and password to the tunnel configuration:
example:/#> configure example:/config/#> tunnel ssl 0 example:/config/tunnel/ssl-0/#> identity client1 example:/config/tunnel/ssl-0/#> password qwerty example:/config/tunnel/ssl-0/#> leave example:/#>
This change causes another restart of the tunnel. Follow steps from part 1 to verify that the tunnel is UP and that pinging the other end works.
Server Push Routes
The final part is to configure the server to automatically push routes to the internal networks that the client needs to access. This simplifies client administration as the needed routes are created automatically on the client.
example:/#> configure example:/config/#> tunnel ssl 0 example:/config/tunnel/ssl-0/#> push-network 10.0.1.0/24 example:/config/tunnel/ssl-0/#> push-network 10.0.2.0/24 example:/config/tunnel/ssl-0/#> leave example:/#>
The OpenVPN server restarts again, dropping all connections.
Client Push Routes
The OpenVPN client eventually detects the connection loss and restarts the tunnel once more. If you want to speed up the process, you can manually force a tunnel restart by executing:
example:/#> tunnel ssl restart
Note: if you have multiple tunnels, this restarts all of them.
Wait a few seconds for the tunnel to be re-established. Then check the routing table:
example:/#> show ip route
There should be routes to the 10.0.1.0 and 10.0.2.0 networks with the tunnel interface as gateway. With the routes in place it should be possible to ping HostA and HostB on the control center internal network:
example:/#> ping count 3 10.0.1.2 example:/#> ping count 3 10.0.2.2
Note: if you are trying this example in a real network, you must configure Host A and B to reach the 10.0.3.0 network (for example by assigning the server as their default gateway), otherwise they will not be able to respond to the ping.