The programming port on this panel family is fixed at TCP 9999 and cannot be changed, so remote access is decided by the network path. Test the programming connection on the panel's own subnet, then reach it through an approved site VPN, and never forward port 9999 to the public internet.
An HMI panel in this family keeps its programming port fixed at TCP 9999. No project setting, network setting or firmware field moves it, so a remote-access plan starts from that number instead of hunting for a way to change it. The port is not the problem, though: a programming service that answers on 9999 works from anywhere once the network path reaches it. So the work is in the path. Check that the panel answers on site, then reach it through the site's VPN so only authenticated tunnels touch the control network. What does not work is publishing 9999 to the internet with a port forward, and what never works is searching the menus for a port setting that is not there.
Why the programming port cannot move
The programming service is the listener a panel keeps open for project transfers and the programming client. Vendors of this class of panel publish Ethernet port lists, and the programming or project-transfer line reads TCP 9999 for the panels covered here. The number belongs to the firmware, so there is no field in the project or the network settings that reassigns it.
That makes 9999 a planning constant: every programming connection you will ever make to this panel dials 9999, and the network path has to be built for it.
Picking an unpopular number is no help either. The IANA registry labels 1024 to 49151 as registered ports and 49152 to 65535 as dynamic ports, and those labels change nothing for a firewall: a port number adds no reachability, the route does.
A panel that serves pages to a web browser runs a separate service for that, on a port of its own, documented in the same port list. Do not plan the browser connection on 9999, and do not plan programming on the browser port.
Symptoms and what each points to
- Programming connects on the shop floor but times out from home or a hotel. The panel and its fixed port are fine. The path between your client and the panel's subnet is missing: no route to the subnet, no tunnel, or a rule that blocks the programming port on the way. A timeout after 30 seconds of waiting is the usual signature.
- No menu or project setting offers a port change. Expected on this panel family. Stop searching the settings and build the path for the documented port.
- The port was changed in the connection settings and now nothing connects, even on site. That field sets the port the client dials. The panel never moved, so any other number finds no listener. Put 9999 back.
- A port forward maps an outside port to the panel and the connection still fails. A forward adds a public map, not a route: the site firewall or the internet provider can still block the traffic. And if the map does pass, it hands the programming service to every scanner on the internet. Take the forward out. Why a port forward does not change the HMI programming TCP port walks through what a forward can and cannot touch.
- The panel's web page opens on site but not remotely, while programming works. The page is the separate service with its own port, so it needs its own rule in the remote path.
Checks in order
- Write down the failing action: a programming connection or a browser page, from which client, at which location.
- Read the panel's address, subnet mask and default gateway from its network settings, and read the programming port from the vendor's published port list. Use that exact number in every test.
- From a laptop plugged into the same switch as the panel, connect the programming software to the panel address on TCP 9999. Give the connection 30 seconds to succeed or time out. If this fails, the panel side is wrong: correct the address, mask or service first, because no remote path works over a broken local one. A ping of 4 packets to the panel address is a quick first check that the subnet is reachable.
- If the local test passes, run the same connection from the remote client through the approved remote-access route. A pass on site followed by a timeout from outside puts the fault in the path, which is where the fix below aims.
- Have the network administrator review the route and the firewall rules for the programming port from the remote range to the panel subnet, checked against the documented service.
Scenario: the panel answers on site but the office cannot reach it
Inputs:
- Panel at 192.168.1.50 with mask 255.255.255.0, a 256-address subnet. Example addresses of the kind used on a small control subnet; the real ones come from the panel's network settings.
- Programming service on TCP 9999, the fixed, documented port for this panel family.
- Laptop on the shop-floor switch at 192.168.1.20 with the same mask, 3 ft of cable from the panel's switch.
- Office PC connected through the site VPN, holding tunnel address 10.8.0.5 with mask 255.255.255.0, 40 miles from the plant.
The rule in words: a client reaches a device without a gateway when the two addresses, each ANDed with the mask, give the same network number. When the numbers differ, the traffic must cross a gateway, and that gateway has to carry the destination subnet and permit the port.
The arithmetic:
- Laptop: 192.168.1.20 AND 255.255.255.0 = 192.168.1.0
- Panel: 192.168.1.50 AND 255.255.255.0 = 192.168.1.0
- Same network number, so the laptop reaches the panel directly: the programming client dials 192.168.1.50 on TCP 9999 and the panel answers within 2 seconds, with no firewall rule involved.
- Office PC: 10.8.0.5 AND 255.255.255.0 = 10.8.0.0, a different network from 192.168.1.0. Its packets go to the gateway, and they only arrive at the panel if the VPN gateway carries 192.168.1.0/24 into the tunnel and permits TCP 9999 from 10.8.0.0/24 to the panel subnet. Over a healthy tunnel that adds roughly 20 ms of round-trip time; a timeout after 30 seconds means the rule or the route is missing.
Result: on-site programming needs no rules at all, and the office connection lives or dies on the route and the rule on the tunnel.
Decision: a local pass plus a remote timeout means the fault is the path. Carry the panel subnet, 192.168.1.0/24 here, into the VPN and permit TCP 9999 from the tunnel range to that subnet. A local fail means the panel side is wrong: correct the address or the service before touching the VPN.
The fix: carry the panel subnet through a site VPN
- Put the remote-access gateway on the control side of the plant network: a VPN router or the site's approved remote-access box, connected so it can route to the panel's subnet. Setting up a VPN router for remote PLC and HMI access covers that side step by step.
- Carry the panel subnet to authorized clients: the gateway pushes the subnet, 192.168.1.0/24 in the example, into each tunnel, and its firewall permits TCP 9999 from the tunnel address range to that subnet. A client then dials the panel's real address on 9999 and the packets travel inside the tunnel.
- Put every client behind an authenticated VPN account under the organization's access policy, and remove shared or anonymous access to the control network.
- Take the public port forward of 9999 out. Published vulnerability entries in the NIST database describe control services that listen on TCP 9999 by default, so an exposed listener is a known target, and IEC 62443 draws the same line from the design side: a plant network is divided into zones joined by controlled conduits, and a raw publish of a programming port on the internet border is the control zone with no conduit at all.
- Test from the real remote location, then record what passed: subnet carried, rule, client, date. When the connection still times out, the off-site path test gives the order to check the hops in.
A site with no internet of its own needs the uplink first. A cellular router for remote industrial site internet access gives the site its own connection, and the VPN runs outbound over it, so nothing has to be published to the internet at all. A status or notice screen added next to the panel later rides the same plan: shop-floor status and notice screens take their own address in the control subnet and are reached only through the tunnel.
The decision
Recommendation: Keep the programming port at TCP 9999 and build the network around it. Check the programming connection from a laptop on the panel's own subnet first. Once that passes, reach the panel only through the site VPN: carry the panel subnet to authorized clients, permit the programming port over the tunnel, and remove any public forward of it. Where the site has no internet of its own, add a cellular router so the tunnel runs over the site's own uplink.
Questions
Can a router map a different public port to the panel's 9999?
A port map sends traffic that arrives on one public port to 9999 on the panel, so the client can dial the public number while the listener never moves. A plain forward adds no check on who connects, though: every address on the internet can reach the programming service just as a tunnel client would. That is why the map belongs on the VPN gateway, which checks the tunnel and the account before any packet reaches the panel subnet.
Which port does the panel's web browser connection use?
The port lists give no single answer: on some families the browser service has a documented default, on others the project sets it, and some panels serve no pages at all. Take the number from the panel's own documentation and give that service its own rule in the VPN, next to the rule for 9999. Dialing 9999 from a browser will not open the panel either way, because the port lists name 9999 for programming and project transfer only.
What if my laptop and the panel sit on different subnets on site?
The same mask arithmetic from the example decides it: different network numbers mean the traffic must cross a router. For a one-day job, set a spare address from the panel's subnet on the laptop and connect directly. For a permanent link, have the network administrator add a route between the subnets and permit the programming port across it. A direct connection on the panel's own subnet stays the quickest way to separate a panel fault from a path fault.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.