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.