How to Access a PLC or SCADA System Remotely Without a VPN

The Remote Access Challenge in Operational Technology

Operational Technology (OT) networks the networks that run PLCs, SCADA systems, HMIs, and industrial controllers are typically isolated from the corporate IT network and the public internet by design. Air-gapping or strict firewall segmentation protects production systems from cyber threats. This is the right approach for security. The problem arises when legitimate remote access is needed: vendor commissioning support, remote fault diagnosis by an off-site engineer, or monitoring by a manager who is not physically on site.

The traditional solution is a VPN either a hardware VPN appliance at the plant or a software VPN client on the engineer's laptop connecting to the corporate network. VPNs work well when properly configured and maintained, but they require IT department involvement, approved hardware, provisioned user accounts, and ongoing maintenance. In smaller facilities, system integrators, or situations requiring rapid access during an incident, that process takes time that may not be available.

How Tunnel-Based Access Works in an OT Environment

The key architectural principle is that the tunnel is initiated from inside the OT network, not from outside. A gateway machine a Windows PC, a Linux server, or an industrial edge device running inside the plant runs the Localtonet client and makes an outbound connection to the Localtonet relay server. Outbound connections on standard ports (typically 443) are allowed by most industrial firewalls because they follow the same pattern as normal HTTPS web traffic.

Once the tunnel is established, traffic flows like this: the remote engineer connects to the relay address, the relay forwards the connection through the tunnel to the gateway machine inside the plant, and the gateway machine forwards it to the target device the PLC web interface, the SCADA server, or the Modbus TCP endpoint. The PLC never communicates directly with the internet. Only the gateway machine does, and only outbound.

Scenario A: Accessing a SCADA or HMI Web Interface

Many modern SCADA systems and PLC HMI panels include a built-in web server that serves a browser-based operator interface. Siemens SIMATIC panels, Weintek HMIs, Ignition SCADA, Wonderware Web Client, and similar platforms all provide HTTP or HTTPS interfaces on standard web ports. An HTTP tunnel exposes this interface to a remote browser with a valid HTTPS URL.

Architecture

Setup steps on the gateway machine

Scenario B: Modbus TCP Remote Access

Modbus TCP is the most widely supported protocol for direct PLC data access from software clients. Siemens S7-1200 and S7-1500 PLCs support Modbus TCP as both client and server. Allen-Bradley PLCs with the appropriate Add-On Instruction or ProSoft gateway module also expose Modbus TCP. The standard port is 502.

A Localtonet TCP tunnel forwards raw TCP traffic transparently, which is exactly what Modbus TCP requires. The remote Modbus client connects to the relay address and the tunnel forwards the connection to the PLC on port 502 inside the plant.

Setup steps

# Python example using pymodbus
from pymodbus.client import ModbusTcpClient

# Connect via the Localtonet relay instead of the local PLC IP
client = ModbusTcpClient(
    host='example.localto.net',
    port=33502,
    timeout=10
)

client.connect()

# Read holding registers (Function Code 03)
# Reading 10 registers starting at address 0
result = client.read_holding_registers(address=0, count=10, slave=1)

if not result.isError():
    print('Register values:', result.registers)
else:
    print('Read error:', result)

client.close()

Gateway Machine Setup and Recommended Architecture

The gateway machine is the only device in the OT network that needs internet access and Localtonet installed. It should be a dedicated machine or industrial PC, not the SCADA server itself, to maintain separation between the OT application layer and the external access layer.

Running Localtonet as a Persistent Service

For installations where remote access must be available at any time not just when someone manually starts a tunnel register Localtonet as a system service so it starts automatically on boot and restarts automatically if it stops.

Linux (systemd)

sudo localtonet --install-service --authtoken <YOUR_TOKEN>
sudo localtonet --start-service --authtoken <YOUR_TOKEN>

# Verify service is active
systemctl status localtonet
journalctl -u localtonet -f

Windows (Service)

# Run as Administrator
localtonet.exe --install-service --authtoken <YOUR_TOKEN>
localtonet.exe --start-service --authtoken <YOUR_TOKEN>

# Verify
Get-Service -Name "localtonet"

After registration, Localtonet starts automatically at system boot and resumes tunnel connections without any manual intervention. Tunnels configured in the dashboard become active as soon as the client connects to the relay.

Security and Access Control

Remote access to OT systems carries significant responsibility. The following controls should be considered mandatory, not optional.

Frequently Asked Questions