Access PLCs and HMIs Through a Site Gateway

What you will have at the end#

A machine builder supports a production line at a customer's plant. A small Linux gateway, gw-01, sits on the line's network and reaches three machines:

plc-01-acme-plant-07.eu.localport.dev    tcp 502 · tcp 102     PLC, Modbus TCP and S7
hmi-01-acme-plant-07.eu.localport.dev    http 80 · tcp 5900    operator panel, web and VNC
cam-01-acme-plant-07.eu.localport.dev    tcp 554               camera, RTSP
gw-01-acme-plant-07.eu.localport.dev     tcp 22                the gateway itself, SSH

An engineer at the office forwards the PLC's Modbus port:

localport access plc-01-acme-plant-07.eu.localport.dev -L 5020:502

Their Modbus client connects to 127.0.0.1:5020 and reads the PLC on the line. The PLC, the HMI and the camera run nothing of yours, and none of these addresses answers anyone without a certificate and a grant.

Before you start#

You need:

• A team on the Pro, Business or Enterprise plan. Remote Access is not available on other plans.
• The owner or admin role to create the fleet and write grants.
• A Linux gateway on the plant network with systemd, such as an industrial PC or a Raspberry Pi, that can reach each machine's IP address. It needs outbound access to port 443 on the internet.
• The LAN address and ports of each machine, from the plant's network documentation.
• Approval from the plant's IT or OT team. What to tell the plant's IT and OT team lists what they will ask.
• The Localport agent on the gateway and on each engineer's computer, from Installation.

How a site gateway works#

The gateway runs one agent process per machine. Each process joins the fleet as its own device and delivers connections to that machine's LAN address with --host:

engineer's laptop  →  Localport edge  →  agent on gw-01  →  192.168.10.21:502 (plc-01)
                                                         →  192.168.10.31:80  (hmi-01)
                                                         →  192.168.10.41:554 (cam-01)

Each machine is a separate device for three reasons:

• Each has its own address, so engineers know what they are connecting to.
• Each has its own grants. A grant reaches every port allowed on the device it covers, so a camera grant never reaches a PLC.
• Each has its own record in the access log, with the device and port of every session.

The gateway only makes outbound connections. The plant firewall needs no inbound rule, no port forward and no static IP. Detailed explanation: Remote Access.

Set up the gateway#

Step 1: Create the fleet and one device per machine#

In the dashboard, go to Fleets and click Create fleet. Name it Plant 07, choose the Region closest to the plant, and click Create Fleet. Open the fleet's Settings, enter acme-plant-07 in Subdomain and save. Then open the Devices tab and switch Auto-join off, so only the devices you create can connect.

Click Create device for each machine, add its ports, and click Create device:

Use HTTP for a web interface, so the access log also counts its requests and response codes. Use TCP for everything else, including industrial protocols, which pass through unchanged. Give each kind of machine its own name prefix, plc-, hmi- and cam-, so grants can name a prefix. Detailed guide: Fleets.

Step 2: Test one device from the gateway#

Install the agent on the gateway, then run the device command with the PLC's LAN address. The Create device & Connect sheet builds it when you fill in Host and Allowed ports:

localport connect --token tok_YOUR_FLEET_TOKEN --region eu --name plc-01 --host 192.168.10.21 --allow-ports 502,102

• --name plc-01 is the device entry this process serves.
• --host 192.168.10.21 is where the gateway delivers connections for it: the PLC's address on the plant network.
• --allow-ports 502,102 is a limit set on the gateway itself. The process serves those ports only, whatever the dashboard allows later.

plc-01 turns online on the Devices tab within seconds. Press Ctrl+C once it does. The next step runs every device as a service.

Step 3: Run every device as a service#

A systemd template unit runs one agent process per device from one file. Each process reads the fleet token from a credential file that only the service can read, so the token never appears in a command line or an environment variable.

Take the agent's hardened unit, deploy/localport.service, and save it on the gateway as /etc/systemd/system/localport@.service. Replace its ExecStart= line with these two lines:

EnvironmentFile=/etc/localport/%i.env
ExecStart=localport connect --region eu --name %i --host ${DEVICE_HOST} --allow-ports ${DEVICE_PORTS}

%i is the instance name, which is the device name. Each device gets a small file with its address and ports:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin localport
sudo install -d -m 0700 -o localport -g localport /etc/localport
printf '%s' 'tok_YOUR_FLEET_TOKEN' | sudo tee /etc/localport/token >/dev/null
sudo chmod 0600 /etc/localport/token

printf 'DEVICE_HOST=192.168.10.21\nDEVICE_PORTS=502,102\n' | sudo tee /etc/localport/plc-01.env >/dev/null
printf 'DEVICE_HOST=192.168.10.31\nDEVICE_PORTS=80,5900\n'  | sudo tee /etc/localport/hmi-01.env >/dev/null
printf 'DEVICE_HOST=192.168.10.41\nDEVICE_PORTS=554\n'      | sudo tee /etc/localport/cam-01.env >/dev/null
printf 'DEVICE_HOST=localhost\nDEVICE_PORTS=22\n'           | sudo tee /etc/localport/gw-01.env >/dev/null

sudo systemctl daemon-reload
sudo systemctl enable --now localport@plc-01 localport@hmi-01 localport@cam-01 localport@gw-01

Each instance starts at boot and restarts after a failure. Check one with journalctl -u localport@plc-01 -f. To add a machine later, create its device in the dashboard, write its .env file and enable localport@<name>. Detailed guide: Run the agent as a background service.

Give engineers access#

Step 4: Grant access by kind of machine#

The fleet reaches nobody until a grant names who may connect. Open the fleet's Access tab and click Give access:

• Type: Role for everyone in a role, or Member for one person.
• Who: the role or the person.
• Access: leave All devices off, type plc-* in the search field and press Enter to add it as a pattern. Add hmi-* the same way.

Then click the Give access to button, which names who you chose.

A grant reaches every port allowed on the devices it covers. Granting plc-* reaches Modbus and S7 on every PLC, and nothing on the cameras. A role grant covers that role only, so owners and admins who also connect need a grant of their own. Detailed guide: Grants and Access.

Connect your tools#

Step 5: Sign in on your computer#

localport login

Open the link it prints, sign in, choose the team if asked, check that the code matches and click Sign in. The certificate lasts 8 hours and does not renew. Detailed guide: Member Access.

Step 6: Forward the PLC's ports#

On the Devices tab, click Access on the plc-01 row. Under Ports to forward, set a local port for each, and click Copy command:

localport access plc-01-acme-plant-07.eu.localport.dev -L 5020:502 -L 10102:102

Leave it running. In your engineering or diagnostic tool, use 127.0.0.1 as the PLC's address and the local port in place of the standard one: 5020 for Modbus, 10102 for S7. Both forwards travel over one connection, and the listeners accept connections from your computer only.

If a tool cannot change the port, forward to the same local port, such as -L 502:502. On Linux, a local port below 1024 needs root.

Step 7: Open the HMI#

localport access hmi-01-acme-plant-07.eu.localport.dev -L 8080:80 -L 15900:5900

Open http://localhost:8080 in a browser for the HMI's web interface. For its screen, point a VNC viewer at localhost on port 15900, or localhost::15900 in viewers that read a single number as a display. Detailed guide: RDP and VNC Access to Remote Machines.

Step 8: Connect a monitoring server#

A SCADA server, historian or monitoring system needs access that does not expire every 8 hours. Give it a machine identity:

• In Identities, open Setup keys and click Create setup key. Choose Server or machine and name the identity scada-01.
• Click Choose what it can reach, pick the Plant 07 fleet and add the devices it reads, then click Grant access to scada-01.
• On the server, run localport setup lps_YOUR_SETUP_KEY once.

Then list its forwards in an access config file:

version: 1

access:
  - device: plc-01-acme-plant-07.eu.localport.dev
    forward: ["5020:502"]
  - device: cam-01-acme-plant-07.eu.localport.dev
    forward: ["8554:554"]

localport access --config access.yaml

The certificate lasts 30 days and renews in the background while the command runs. Run it as a service so it starts at boot. Detailed guide: Setup Keys.

What works through a forward#

A forward carries a TCP connection to one port. That decides which tools work:

• Any tool that connects to an IP address and a TCP port works. Modbus TCP on 502, Siemens S7 on 102, OPC UA on 4840, EtherNet/IP explicit messaging on 44818, MQTT, RTSP, SSH, VNC and web interfaces.
• Traffic over UDP does not pass, such as EtherNet/IP I/O on UDP 2222 or real-time PROFINET. Localport carries no UDP.
• Discovery by broadcast or at layer 2 does not pass, such as a tool scanning the network for devices. Enter the address and port by hand.

Some engineering software only reaches a controller on the same network segment. For those tools, connect over SSH or Remote Desktop to an engineering PC at the plant, and run the software there.

What to tell the plant's IT and OT team#

The plant's network owners will ask how the gateway behaves. The facts they need:

• Outbound only. The agent opens outbound connections to Localport on port 443. The plant firewall needs no inbound rule, port forward or static IP.
• A limit set on site. --allow-ports on the gateway caps the ports each process serves, whatever the dashboard allows. The plant can hold the gateway to the ports it approved.
• Every caller is identified. Nothing reaches the equipment without a client certificate from your team and a grant for that machine.
• Every session is recorded. The access log records who reached which machine and port, from where and for how long. Traffic content is not recorded.
• The agent is open source. The plant's security team can read the code that runs on the gateway at github.com/localport/agent.
• It can be cut off at once. Removing a grant or a device, or stopping the service on the gateway, ends every session.

How long a session lasts#

An engineer's session stays open while their 8-hour sign-in is valid, the gateway's process for that device stays connected, and their grant stands. Removing the grant closes it at once. An open session is never closed for being idle. The full list: How long a session lasts.

Troubleshooting#

Limitations#

• TCP only. UDP and broadcast traffic do not pass.
• One process per device on the gateway. A gateway serving many machines runs one systemd instance for each.
• A grant covers every port allowed on a device. Split machines that different people should reach into different devices or prefixes.
• Remote Access reaches equipment. It does not manage it. It does not push firmware or collect machine data. Run those tools over the access it gives you.

Frequently asked questions#

What to read next#

• Set Up Remote Access to a Device Fleet. Fleets, naming, auto-join and role grants.
• Fleets. Devices, ports, --host and --allow-ports in detail.
• Setup Keys. Machine identities for servers.
• CI/CD with OIDC. Pipelines with no stored secret.
• Access Log. Every session, by machine and port.