Architecture

The reason for this solution was that the LoRaWAN gateway we installed was sponsored to the TTN Community. Because of that we agreed that the manufacturer (sponsor) only has root access and the gateway manager can only do application management. Who needs access on a good working system? As a result of this decision there is no ssh access to the gateway. Also the gateway hardware cannot be used for other tasks like a OpenVPN client for for remote access.

To address the need for remote access to the web interface of the gateway, this OpenVPN solution was developed.

The architecture of this solution contains three compontents.

1. the OpenVPN server
2. the OpenVPN client at the gateway (gateway client)
3. the OpenVPN client at the operator (admininistration client)
   

In our solution the client is the one that takes the initiative to connect to the server.

The server is the central part where all clients connect to. The server provides routing capabilities trough the VPN network. There are two type of clients in our solution:

The first is the gateway client. In our situation the LoRaWAN gateway is connected to the local lan at the gateway location. This LAN, and any device connected to it, is reachable from the OpenVPN server trough the VPN tunnel that the gateway client initiates to the server.

The second client type is any computer from which management is preformed on the gateway. This administration client is accessing the OpenVPN server like a dial-up or Remote Access Server (RAS). From the administration client the gateway can be connected trough the OpenVPN server.

Figure 1 shows the architecture overview of the system.

Figure 1: Overview of the OpenVPN solution.

Hardware

There are many possible implementations to have as a OpenVPN server. The most obvious one is to have a (linux) server (VPS) that serves as OpenVPN server. All clients make contact to the server that has a presence on the internet. We use a DynDNS service that is described later.

In our solution we use for both the server and the gateway client a dedicated router. In our case a "obsolete" Linksys WRT54GL router that is flashed with an DDWRT OpenVPN image. A description about flashing a WRT54GL router can be found here: how to install and configure openvpn on your DDWRT router.

Linksys WRT54GL routers can be bought for 10 euro's or less on second hand market places like Marktplaats.  Being cheap is not the only positive thing about the WRT54GL. The unit is stable, needs little maintenance and is running on 12V.

Figure 1 shows the interior of the cabinet that contains the gateway (bottom right) and the Linksys WRT54GL router that functions as OpenVPN Gateway Client (top right)

Figure 1: view on the internal of the gateway cabinet.

Routing

In our OpenVPN solution routing is provided between three LAN.

1.  The first LAN Is the LAN to which administration clients are connected (10.0.19.0/24)
   
2.  The second LAN is the LAN at the OpenVPN server. This LAN has no connected devices. (10.0.10.0/24)
   
3.  The third LAN is de LAN at the gateway client. Here the gateway is connected to the router. (10.0.20.0/24)
   

The configuration and IP-ddresses are shown in Figure 1.

Figure 1:  Overview of IP numbering

Certificates and DynDNS

The OpenVPN solution is capable of providing a high security tunnel. In our solution the level of security is not an issue. We need a tunnel to pass trough various routers and NAT. Also the routing trough the tunnel is static. Therefore we use "low" security and a simple implementation on the tunnels between the  Server and the gateway clients.

For the administration clients, authentication is important and different users with different clients shall connect to the server. Therefore the "normal" tunnel is used with root and client certificates.

Certificates

OpenVPN requires certificates. Certificates can be produced using EasyRSA. EasyRSA is an option that comes with the OpenVPN installation and is available for both Linux and Windows. A good description of producing all server and client certificates can be found here Easy Windows Guide at openvpn wiki

The tunnel between the central server and the gateway client can use a single static key. The static key is a simple method of crating a tunnel with less high security than a full blown implementation using a root certificate. A description can be found at the static key mini howto at OpenVPN.

For the administration clients a full deployment using a root certificate and client certificates is used. This simplifies acces trough multiple administration clients to the server.

DynDNS

The central server shall be made reachable from the internet. Therfore we need a URL that follows any ip address that is linked to to our central server.

We use DuckDNS as or DynDNS provider. DynDNS service is true free and can be used in combination with many systems and OS.

Conclusion

This article showed how we used OpenVPN for administration of our sponsored LoRaWAN gateway.

Some final remarks:

• The directives we had have directly added to the decisions we made for our implementation.
• This solution can be adapted or enhanced to fit your situation.
• It is very well possible to use Raspberry-PI of Linux(VPS) systems to produce the same functionality.

I hope this article was helpful and will be a inspiration for solutions for similar cases.