The rule is fine; the client never reaches it. A port forward rewrites only packets that arrive addressed to its external port, and HMI programming software with no port setting always dials the panel's fixed port, TCP 9999. Make the rule's external port 9999 too, or carry the session through a VPN and publish nothing.
If the HMI programming software has no field for a port number, no router rule will give it one. A port forward does not change the TCP port a client dials; it only rewrites traffic that already arrives addressed to the rule's external port. Software that programs a panel at a fixed TCP 9999 keeps dialing 9999 at whatever address you type, so a rule listening on some other public port and mapping inward to 9999 never sees a single packet. The fix is to make the rule's external port 9999 as well, or to skip the public internet path and carry the session through a VPN. This page explains why the mismatch happens, how to tell it apart from the other common port-forwarding failures, and what to change on the router.
Why the rule never sees the connection
A TCP connection has a destination endpoint, and the client picks it: an address and a port. Port forwarding on a router is a fixed translation rule. Packets that arrive at the router's public address on one specific external port get their destination rewritten to an inside address and port, then pass inward. Nothing else matches. When no rule matches, the router drops the packet silently or answers with a TCP reset, depending on how its firewall is set.
The rule and the client therefore have to agree on one number: the external port. A panel programmed over Ethernet at TCP 9999 needs the client to dial the router's public address on 9999. If the programming software offers an address field and no port field, 9999 is the port it dials. A rule that listens on TCP 5000 and forwards to 9999 inside is built correctly and completely idle. The router cannot start a connection to its own port 5000 on the client's behalf; the destination port belongs to the client, and this software gives you no way to move it.
Symptoms and what each points to
- The connect attempt hangs about 21 seconds, then reports a timeout. The SYN packets reached the router and nothing answered them. The usual cause is a rule whose external port does not match the port the software dials.
- The attempt fails in under a second with a refused or reset message. Something sent a TCP reset: a firewall that rejects unmatched ports outright, or a rule that matched and forwarded to a panel with nothing listening on 9999 at that moment.
- Programming works on the bench and fails across the router. On the bench the client dials the panel's address directly, so NAT is out of the path. A bench test exercises the direct path, so save the real test for the remote network.
- A different tool connects through the same rule but programming does not. That tool probably has a port field and dials the rule's external port by design. The programming software cannot, so one rule cannot serve both.
Check the rule and the client in order
- Read the rule back from the router and write down its four fields: protocol, external port, internal address, internal port. The external port is usually labelled the WAN or public port on the router's port-forwarding page.
- Open the programming software's connection settings. An address field with no port field means the destination port is fixed at the panel's programming port, 9999 in the setup described here.
- Run a packet capture on the programming PC during one connect attempt and read the first outbound packet. Its destination address and port are what the software actually dials, and that port is the external port the rule needs.
- Confirm the path. From the same subnet as the panel, the client never touches the router's rule, so a rule change shows no result on the bench.
- Work the hops one at a time if the picture is still unclear. The hop-by-hop port-forwarding test covers the router, firewall and client checks in order.
The fix on the router
- Open the port-forward rule and set the external port to the same 9999 the panel listens on. Leave the protocol at TCP, the internal address at the panel's address, and the internal port at 9999.
- Restrict the rule to source addresses if the router offers it: allow only the public address of the network you program from.
- Save, then test from the actual programming PC at the remote site: enter the router's public address, open the project, and confirm the software reaches the panel. If the offline indicator stays red after the port test passes, why a red offline indicator survives a passing TCP port test explains that gap.
One safety note: TCP 9999 open to the whole internet is an open door to whatever the panel accepts from a programming client. Restrict the rule to your own public address, or keep the panel off the public path entirely with a VPN.
Worked example: a fixed client against a rule on port 5000
Setup: the panel sits at 192.168.10.50 and listens for programming on TCP 9999. The site router's public address is 203.0.113.10. The existing rule reads TCP, external port 5000, internal address 192.168.10.50, internal port 9999. The programming software has an address field and no port field.
First attempt: you type 203.0.113.10 into the software, so the client dials 203.0.113.10 on port 9999. The rule listens on 5000. Port 9999 does not match external port 5000, so no rule matches, and the router drops the packet. The client sends its first SYN at t = 0 s and retries with the interval doubling: a retry at t = 3 s, one at t = 9 s (3 + 6), one at t = 21 s (3 + 6 + 12), then a timeout. The wait is about 21 seconds, and the rule never fired once.
Fix: change the rule's external port from 5000 to 9999. The client's dial of 203.0.113.10:9999 now matches the rule on the external port. The router rewrites the destination to 192.168.10.50:9999, the panel answers with SYN-ACK, return traffic follows the translation back, and the programming session opens. The internal port needed no change, because the client already dialed the port the panel listens on.
Keep 9999 off the public internet
A plain port forward has exactly one listening port, so it cannot present one public port while receiving on another. Two designs work when site policy forbids a programming port on the WAN address:
- A VPN. The programming PC joins the site network through the tunnel and dials the panel's private address, 192.168.10.50 on TCP 9999, directly. Nothing is published. The setup is the same one used for remote PLC and HMI access: set up a VPN router for remote PLC and HMI access.
- A tunnel endpoint you control. An SSH session to a device at the site, with a local forward that listens on 9999 at the PC and carries the traffic to 192.168.10.50:9999 through the SSH server. The client still dials 9999, so the software works unchanged, and the public side carries SSH only. Publishing that SSH endpoint through a controller firewall takes a destination rewrite and a source rewrite together; the DNAT and SNAT walkthrough shows the rule pair.
The common thread: the client has to dial the port a device listens on, or the traffic has to travel inside a tunnel that ends on the client's side. A rule on port 5000 cannot be made to serve a client that only ever dials 9999.
Recommendation: if the programming software has no port field, set the router rule's external port to the same port the panel listens on, 9999 in this setup, and restrict the rule to the public address you program from. If site policy will not allow a programming port on the WAN address, bring the programming PC in through a VPN and publish nothing. Confirm the panel-side port in the panel's own documentation first; if your panel listens on a different number, both port fields in the rule take that number.
Questions
Can I forward a different public port to TCP 9999 on the panel?
Only if the client can be aimed at that public port, and this software cannot. A rule that maps external 5000 to internal 9999 translates only traffic addressed to 5000, and a client with no port field never dials it. With the client fixed, the external port must be 9999, or the session must travel through a VPN or an SSH-style local forward that ends on a port the client chooses.
Can the panel's own programming port be moved off 9999 to match my rule?
There is no port setting in the programming software, and no published panel setting that moves the port on that side either. Treat 9999 as fixed unless your panel's own documentation shows a different number. The rule then takes that number in both of its port fields, with the protocol set to TCP, and the client stays untouched.
Does opening TCP 9999 on the router expose anything else?
It exposes one service on one panel: the programming port at 9999, to whatever source addresses the rule allows. It opens nothing else on the panel and no other device behind the router; each of those needs its own rule. Restrict the rule to the public address you program from, and remove it when the job is done.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.