HMI remote access port forwarding fails: test each step

Symptoms and what each points to

Match your case to one line before touching the router:

• Works on the plant network, dead everywhere else. The panel's service is healthy. The fault sits in the forwarding rule, the router's loopback behavior, or the tunnel route.
• The public address loads from a phone on cellular data but fails from an office PC. The forwarding rule is correct. The router lacks NAT loopback, a limitation of the router, not a mistake in the rule.
• The tunnel connects and the panel's private address still fails. The tunnel has no route to the plant LAN, the address ranges overlap, or a firewall rule blocks the client pool.
• It worked last week and died after a power cut. The panel's address moved. The rule still points at the old one and forwards into an empty socket.
• Nothing ever arrives, on any network. The rule's destination address, internal port or protocol field is wrong.

Confirm the panel project first

Start where the path is known good, on the plant network:

1. Open the panel by its private address and the port the project sets, in the same app or browser a remote user will use. A screen here confirms the service, its address and its port together.
2. Write down the port for each service. A panel project usually runs a web server and a separate remote-access service on two different ports, and each port needs its own forwarding rule.
3. Fix the panel's address: a static address on the panel, or a reservation on the router, so a reboot leaves the panel where the rule points.
4. Note the protocol each service uses, TCP or UDP, from the panel's own documentation. The rule must repeat it exactly.

Check the forwarding rule field by field

Every rule on the router's forwarding page carries the same four fields, and one wrong value in any of them ends the connection:

• External port, the number typed after the public address. It can differ from the internal port, and when it does, the app entry must use the external one.
• Protocol, TCP, UDP, or both. A TCP service behind a UDP-only rule never answers.
• Destination address, the panel's fixed address, character for character. One digit off sends the traffic to another device or to nothing, and the router still calls the rule valid.
• Internal port, the port the service actually listens on, as recorded from the project.

Save the rule and run the outside test before adjusting anything else.

Test the public address from a cellular connection

Use a phone on cellular data with Wi-Fi switched off. From there the request enters the router from the internet side, the same path a remote user's request takes.

Then open the same address from an office PC on the plant network. Routers without NAT loopback refuse an inside client's request to their own public address, and small business routers commonly ship without it. The pairing carries the verdict: cellular success confirms the rule end to end, and an in-plant failure of the same address marks the router's missing loopback. A write-up of exactly that pattern on a plant controller shows the two results side by side: private IP works, loopback does not.

Example: one plant, three tests

The plant LAN is 192.168.1.0/24, one subnet of 254 usable host addresses, 192.168.1.1 through 192.168.1.254. The panel is fixed at 192.168.1.50. The project runs the web server on port 80 and the remote-access service on port 8080. The router's public address is 203.0.113.10, an example address. Two rules are saved:

Check the numbers as equalities. For the remote-access service, three values must match: the app entry 203.0.113.10:8080, the external port 8080 and the panel service port 8080. For the destination, the rule's 192.168.1.50 must be the panel's address exactly. Note the trap a /24 sets: a typo of 192.168.1.150 still falls inside 192.168.1.1 through 192.168.1.254, so the router accepts the rule and forwards the traffic to a device that runs no panel service. A wrong destination inside the plant range fails silently, which is why the address gets compared character for character.

Run the three tests one at a time, with a browser timeout of 30 seconds so a silent drop reads as a failure:

1. Plant laptop to http://192.168.1.50:8080: the screen loads. Service, address and port confirmed.
2. Office PC to 203.0.113.10:8080: the request times out after 30 seconds. NAT loopback is missing.
3. Phone on cellular data to 203.0.113.10:8080: the screen loads. The rule is correct end to end, and remote users will connect.

Read the three results together and the example carries to one verdict. Test 1 loads the screen at 192.168.1.50:8080 on the plant LAN, so the service, its address and its port are good. Test 2 times out after 30 seconds at 203.0.113.10:8080 from inside, which clears the rule and marks the router as lacking loopback. Test 3 loads the same address 203.0.113.10:8080 from cellular data, which confirms the forwarding rule end to end. The result: keep both rules as saved, tell in-plant users to open 192.168.1.50:8080 directly, and tell remote users to open 203.0.113.10:8080. Nothing in the rule needs changing.

The tablet through the tunnel is the fourth test, and the tunnel section below carries it.

Make the tunnel route to the plant LAN

After the app reports the tunnel up, open the panel's private address, 192.168.1.50 in the example, through the tunnel. The public address through a tunnel tests the wrong path.

When the private address fails through a connected tunnel, check three things in order:

• The route. The VPN server configuration must push a route to the plant subnet, 192.168.1.0/24, to every client. Where that setting lives depends on the gateway; the network or route list in the VPN setup holds it.
• The overlap. Many home and hotel routers default to 192.168.1.0/24 too, another 254-address subnet. A tablet on such a network hears 192.168.1.50 as a local device and hands the packets to a neighbor, never into the tunnel. Keep the client pool on a separate range, for example 10.0.8.0/24 against a plant 192.168.1.0/24. Both stay inside the private ranges RFC 1918 sets aside for internal use: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.
• The firewall. With the tunnel connected, the route pushed and the ranges distinct, the gateway's firewall must allow traffic from the client pool subnet, 10.0.8.0/24, to the panel subnet, 192.168.1.0/24, on the service port, 8080 in the example.

Keep the opening to one service

A forwarding rule publishes the panel to the entire internet, and internet-wide scanners sweep whole address ranges constantly. Treat every published port as found. The tunnel is the safer shape, because it asks for an authorized client before any traffic moves. Forward one service to the panel's fixed address, and take the rule out the day the tunnel carries the traffic. No DMZ entry. What a connected user can reach on the panel itself is its own decision: HMI screen access control for a protected operator view covers that configuration.

If the remote viewer only needs to watch the process, specify a read-only process display for a plant keeps the write path closed from the start. For a status view on a separate screen, how to embed a remote machine screen safely covers the display side.

Recommendation: run remote access through a VPN that routes to the plant LAN, keep the client pool on a separate subnet such as 10.0.8.0/24 against a 192.168.1.0/24 plant LAN, and test by opening the panel's private address through the tunnel from a phone on cellular data. Until the tunnel is in place, forward one service to the panel's fixed address, verify it from cellular data, and remove the rule the day the tunnel takes over.

When every segment passes and the page still will not load

Compare the address on the router's status page with the address the internet sees. Open the status page, note the WAN address, then open an address lookup page from a plant PC. Two different addresses mean a device sits in front of the router, a second router on site or the carrier's own network. RFC 6598 reserves 100.64.0.0/10 for carrier-grade NAT, so a WAN address in 100.64.0.0/10, or in any RFC 1918 range, is the tell: the rule belongs on the first device in the path, and the inner router forwards into a dead end.

If the addresses match and the cellular test still fails, look at the router's forwarding log where it keeps one. A logged request that never opens the page points at the panel side. An empty log points at the path before the router. Send the router maker's support desk the four rule fields, the WAN address, and the cellular and in-plant results with timestamps. Send no credentials while troubleshooting is open.

Questions