A VPN router at the plant is the reliable way to reach a PLC and its HMI from another site. Give the Ethernet module and the HMI static IPs on one dedicated /24 subnet, terminate an encrypted tunnel on the router, and your programming and HMI software connect as they do on the bench. A dial-in serial line stays a last resort for the CPU only, at about 143 seconds per megabyte.
A PLC at a distant site and the HMI panel next to it can be serviced from your office as if both sat on the bench. The piece that makes that work is a VPN router at the plant end. Give the PLC's Ethernet module a static address such as 192.168.10.10 and the HMI 192.168.10.11 on one dedicated /24 subnet. The router at 192.168.10.1 ends an encrypted tunnel from your PC, and the programming software and HMI software connect exactly as they do locally. This article gives the hardware list, a complete worked IP plan, the build steps in order, the checks that prove the tunnel, and the one case where a dial-up serial line still earns its keep: at 56 kbit/s, a 1 MB download takes about 143 seconds.
How do I access a PLC and an HMI from another site?
Install a VPN-capable router at the plant, put the PLC Ethernet module and the HMI on static IPs in one dedicated /24 subnet, and dial in with the matching VPN client; both devices then answer your software as if they sat on your own bench.
The router encrypts everything between your PC and the plant, so the PLC and the HMI need no VPN support of their own: ordinary TCP/IP, a static address each, and a gateway set at the router. Pick the client before you pick the router, because the two ends must speak the same protocol; that choice is worked through in Remote HMI wireless access: choose the client first. Many industrial routers add a cloud broker. The site router and your client each dial out to the broker's server, the tunnel forms once both connections are up, and no port opens on the plant side toward the internet.
Why not just forward router ports to the PLC and the HMI?
Do not port-forward the PLC or the HMI to the public internet: a scanned address lands on the controller, industrial devices rarely carry strong login protection of their own, and one open port hands an attacker a path straight to the process.
A tunnel hands you the whole plant subnet under one login, instead of one exposed port per device. IEC 62443, the industrial cybersecurity standard series, treats a remote link as one conduit between zones: a single controlled path, authenticated at the boundary, with the plant devices kept off the public internet. A VPN router ending one authenticated tunnel is exactly that conduit. Keep any port-forward rule you already have for local work only, and take it out before the panel returns to service; the way to prove whether a given port answers from outside is walked through step by step in HMI remote access port forwarding fails: test each step.
What do I need for remote PLC and HMI access?
You need four things: a VPN-capable router at the plant with a working internet line, one free private /24 subnet for the plant devices, static IP settings for the PLC Ethernet module and the HMI, and the matching VPN client on the PC you service from.
- Router and internet line. Any model that speaks your client's protocol, with a working WAN connection; ask the ISP whether the plant's WAN address is static or dynamic, and plan a dynamic DNS name from day one if it is dynamic.
- One free private /24. It must not overlap your office LAN or any network you connect from; the worked example below shows the overlap check.
- Static addresses. Set the PLC Ethernet module per its manual and the HMI in its network settings, each with its gateway pointing at the router's LAN port.
- VPN client. Installed on the PC you service from, speaking the router's protocol.
- Plant IT. If a firewall sits above the router, they permit the tunnel through it.
- Cabinet power. Feed the router from the 24 V DC control rail through a DIN-rail supply, so a tripped wall circuit cannot pull the link down with it.
Where the site has no wired internet service at all, a cellular router can carry the WAN side; the trade-offs are compared in these cellular router options for remote industrial sites.
What does a worked example look like for one plant?
The plant and your office both sit on 192.168.1.x today, so the tunnel would connect and then go silent; renumber the plant to 192.168.10.0/24, set the PLC Ethernet module to 192.168.10.10 and the HMI to 192.168.10.11, and the link carries live traffic.
Here is the design carried through with real numbers. Office and plant were both built on 192.168.1.0/24 with mask 255.255.255.0. The tunnel connects and the pings die: the office PC sees 192.168.1.x as its own local network, sends plant-bound packets onto the office floor, and no reply ever finds its way back. Renumber the plant to 192.168.10.0/24. That subnet holds 256 addresses, minus the network and broadcast addresses, which leaves 254 usable hosts, enough for the controller, the panel and years of additions.
| Device or range | Address | Gateway |
|---|---|---|
| VPN router LAN port | 192.168.10.1 | is the gateway |
| PLC Ethernet module, static | 192.168.10.10 | 192.168.10.1 |
| HMI panel, static | 192.168.10.11 | 192.168.10.1 |
| DHCP pool, 101 addresses | 192.168.10.100 to 192.168.10.200 | 192.168.10.1 |
| VPN client pool | 192.168.200.0/24 | router assigns |
The static addresses sit below the DHCP pool, so a borrowed laptop can never take the controller's address. Result: with the tunnel up, the office PC pings 192.168.10.10 and gets a reply, the programming software goes online against the module, and the HMI software reads live values from the panel exactly as on the bench. A bench link answers in about 1 ms; this tunnel across the country runs about 60 to 90 ms round trip on broadband, which programming and HMI software absorb with no change of settings.
How do I set up the VPN router step by step?
Build the link in this order: device addresses first, bench proof second, router VPN third, WAN lockdown fourth, first connection last, because that order means you never debug two unknowns at the same time.
- Give the PLC Ethernet module and the HMI their static addresses and gateways from the IP plan. Without the gateway entry, a device hears your request and its reply dies at the plant, because it holds no route back through the router.
- Prove both devices on the plant's own LAN before the router is touched: programming software online to the module, HMI software online to the panel. Never debug a tunnel and a device at the same time.
- Configure the VPN service on the router: an account with a credential or certificate for each person, the plant subnet the tunnel exposes, and a client address pool on its own range outside the plant subnet.
- Lock the WAN side down: change the router's default password, turn administration off from the internet, forward no PLC or HMI ports, and bring the firmware current.
- If a plant firewall sits above the router, have site IT permit the tunnel now; the router never sees a handshake the firewall drops.
- Connect the VPN client from your PC and confirm the PC holds a route to the plant /24.
- Point the programming software at the module's address and the HMI software at the panel's address, then go online and read one value.
How do I check the tunnel before I rely on it?
Run three checks with the tunnel up: ping both device addresses from the example plan and expect replies, open the HMI software and watch one live value refresh, then drop the tunnel and confirm the same pings fail.
The disconnected ping is the check that catches real trouble: if the devices still answer with the tunnel down, a port-forward or a NAT rule is exposing them to the internet, and that rule comes out the same day. Leave the tunnel configured and connect when you need it; the plant side holds no schedule to maintain. One rule governs the first write or download: make it only when the machine state allows it and a person at the plant can stop the process, because a remote write reaches a running machine exactly as a local one does.
What breaks a VPN link to a plant most often?
Five faults cause nearly every failed first connection: overlapping subnets, a missing gateway on the devices, a WAN address that changed overnight, an upstream firewall that swallows the handshake, and a tunnel MTU that stalls large downloads.
- The tunnel connects and nothing answers. Both ends sit on the same subnet. Renumber one side to a range you use nowhere else, as in the worked example.
- The tunnel is up but pings time out. The devices hold no gateway. Point the module and the panel at the router's LAN address.
- It worked yesterday and is dead today. The plant's WAN address changed overnight. The dynamic DNS name from the planning list fixes it, or ask the ISP for a static address.
- The router never sees a handshake. A firewall or the ISP blocks the VPN above it. Site IT permits the tunnel, and the handshake arrives.
- Small transfers succeed but a large download stalls at the same spot each time. The tunnel's headers push the path MTU below 1500 bytes. Set MSS clamping to about 1360 bytes on the tunnel interface and the stall clears.
- The tunnel is healthy but the software still fails to go online. The fault has moved into the device. The Ethernet module maker's support FAQ documents remote access behavior for most modules, so read it before redesigning anything.
Should I keep a dial-in serial line as a backup?
Keep a dial-in serial line only as a second road into the CPU for the day the plant's internet dies: at 56 kbit/s a 1 MB program download takes about two and a half minutes, and no modem reaches the HMI's Ethernet screens at all.
The arithmetic behind that figure: 1,000,000 bytes is 8,000,000 bits, and 8,000,000 divided by 56,000 bit/s is about 143 seconds, so the download alone takes roughly two and a half minutes before any protocol overhead. The modem path reaches the CPU's serial port only; it cannot carry the panel's Ethernet screens, so it is a spare road into the controller, never the main route. Buy one only where a phone line and a free CPU serial port already exist at the cabinet. Where the internet line itself is the weak point, the cellular WAN option above does far more for the site.
Recommendation: Put a VPN router at the plant as the only remote path, with the PLC Ethernet module and the HMI on static addresses inside one dedicated /24 that overlaps nothing you connect from. Add a cellular WAN router when the site's wireline service is unreliable, and keep a dial-in serial line only where a phone line and a spare CPU serial port already exist.
Questions
Does adding remote access change how the HMI panel talks to the PLC?
No. The tunnel sits between the sites only. On the plant floor everything stays as it was: the panel still polls the controller over the local network at bench speed, screens still switch at the same rate, and nothing in the panel program changes. Remove the router and the plant runs as before, which is why the router belongs outside the control devices, never inline between panel and controller.
What changes when the plant's internet address is dynamic?
The tunnel still works; your client just needs a name that follows the address. Nearly every VPN router offers dynamic DNS: the router tells a DNS provider its current WAN address each time the ISP changes it, and your client connects to that hostname instead of a raw address. For a plant you service often, a static address from the ISP is worth asking for, because it removes the one part of the link that moves without telling you.
How many engineers can connect to one plant router at once?
As many concurrent client sessions as the router's datasheet allows, and no more, so check that number before you buy; it runs from a handful to dozens depending on the model. Give each technician a separate account with a separate credential, remove the account the day someone leaves the job, and you also gain a record of whose session was online when a change went through.
Can plant staff see who connected and when?
Most VPN routers keep a connection log with the account, start time and duration of each client session. Turn it on during commissioning and export it monthly at first; after an unexplained fault, that log settles who was in the system and when. On routers that support it, sending the log to a small syslog receiver in the cabinet keeps the record even if the router is reset or replaced.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.