Creating a Remote Access System with OpenVPN

Creating a Remote Access System with OpenVPN

Introduction

Remote access has never been more important, with internet connectivity expanding daily and customer expectation for such technology increasing, not being able to deploy, modify and diagnose your software remotely puts you in the dark ages of technology.

We learnt this lesson the hard way spending 1000's of hours travelling to Aerobic Digester plants all over the country to design, program, test, & commission the software that runs them. This software is complicated and crucial to the running and safety of these plants. Downtime or incorrect control logic can cause costly damage.

What makes these systems different is their control systems aren't "PC" based, they're run on purpose designed hardware called PLC's. In this case they are the Siemens S7 1500 CPU’s. True hardware based PLC's are bulletproof, they last for years and will never "Blue Screen" or crash.

The Problem

We had tried simple existing technologies to allow remote access such as PPTP & OpenVPN setup on the site routers. Although these connections would be unstable due to bad implementations of the VPN protocols by router manufacturer's, they would for the most part work.

This was until more sites were being built and there internet connectivity constantly changing between 4G, Satellite & Broadband. These changes were down to sites being built in remote locations making viable broadband solutions difficult.

A solution, not dependant on the sites router became important. On many sites, the login details to these routers are a complete unknown thanks to IT engineers coming and going not leaving a paper trial.

Solutions to this problem do already exist, even in the form of industry-specific hardware, unfortunately, they are very expensive. For this reason we decided to build something ourselves.

Solution

Our solution was to create a single virtual LAN, when connected to this LAN a client would be able to see and communicate with all connected devices. This means when one of our programmers connects to the VPN they can see every remote PLC without changing connection. Below is an sample of sites IP addresses and forwarded ports into the virtual LAN.

Site TUN IP Address Ports
Manor Farm 10.8.0.100 102, 5900
Fairfields 10.8.0.101 102, 5900
Wester Alves 10.8.0.102 102, 5900
Inchdairnie 10.8.0.103 102, 5900
Stracathro 10.8.0.104 102, 5900
Tornagrain 10.8.0.105 102, 5900
CleatHill 10.8.0.106 102, 5900
Savock 10.8.0.107 102, 5900
Stragglethorpe 10.8.0.108 102, 5900
Tuxford 10.8.0.109 102, 5900

Having a single server where the site is the client takes away the need for port forwarding. As long as the device we ship to site can gain access to internet it will connect to our VPN.

Set-up

Server

For this to work client-to-client needs to be enabled in the OpenVPN's server configuration. Without this option users wouldn't be able to communicate with each other. Enabling client-config-dir is also essential as it allows us to map all sites to static internal OpenVPN IP addresses.

Client

We decided to use EdgeRouter X's as the on site VPN device, they are configured with the following NAT forwardig rules:

iptables -A PREROUTING -t nat -i vtun0 -p tcp --dport 102 -j DNAT --to 192.168.0.1:102
iptables -A PREROUTING -t nat -i vtun0 -p tcp --dport 5900 -j DNAT --to 192.168.0.3:5900
iptables -t nat -A POSTROUTING -j MASQUERADE

In the above example 192.168.0.1:102 & 192.168.0.3:5900 will be forwarded to the internal OpenVPN IP address of the EdgeRouter. This allows anyone on the private OpenVPN network to access these ports.

Deployment

Site configuration is simple, each EdgeRouter deployed to site will be assigned a static OpenVPN IP address such as 10.8.0.100. Each device is set to DHCP on eth0, this means all the unit needs to connect to our OpenVPN server is a working internet connection with DHCP enabled.

Relying on DHCP means we don't need access or information about the sites network infrastructure, modify port forwarding rules or get sites to pay for static WAN IP addresses. We just ship the unit and they plug it in.

Below is an example of how a two site deployment would look, our programmers would be able to get access by connecting to our OpenVPN server and using either 10.8.0.100 or 10.8.0.101 to access one of the two sites.

Maintenance

Using the LTS version of Ubuntu on our server with some automated scripts to get security updates means minimal manual intervention. Adding new clients is partly automated with scripts also.

Security

OpenVPN is a tried and tested protocol, it's Open Source and heavily audited by the professional and independent security community's. It has the strongest reputation out of all modern VPN protocols.

Cost Effectiveness

The EdgeRouters we deploy to site cost £50 per unit, each unit needs to be configured in the office by flashing our pre-made image. We host our OpenVPN server on DigitalOcean VPS at a cost of £4 per month, we pay an extra £1 for monthly backups.

Similar systems in our industry cost £800-900 for the unit that's shipped to site. Usually require configuration on site, with a monthly subscription of £30 - £300 a year.

Conclusion

Our solution for remote access has proven to be reliable, scalable & very cost effective. Thanks to the cost saving we can now offer remote access that benefits us and our customer as standard.

EdgeRouter X on site in Scotland