Repost of a write-up done on an employee’s personal blog outlining some of the technical details behind a recent project. Source
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. On 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.
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.
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|
|Wester Alves||10.8.0.102||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.
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.
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.
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.
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.
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.
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.
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.