A red offline-link LED reports one thing: the software's ICMP ping to the address you configured got no reply. A TCP port test to 9999 can pass while the LED stays red, and the transfer can still work once the router rules are right. Audit the rule, run the transfer, and record the red LED as the expected state when the site blocks ping.
A red offline-link LED and a passing TCP port test disagree because they measure different traffic. The software behind the LED sends an ICMP echo request to the address stored in the link entry and waits for a reply. The port test opens a TCP session to port 9999. A router can refuse the first and pass the second, and the router rules can still be the reason a project transfer fails. This article gives the order to check, the fields to read in the forwarding rule, and the test that ends the argument: a completed transfer. The color of an indicator is a report on one probe, and the plan below tells you when to act on it and when to write it down and move on.
What does a red offline-link LED mean?
A red offline-link LED means the software's own reachability probe failed, nothing more. With the link set up as an offline link, the program sends one ICMP echo request to the address you entered and shows red until a reply comes back.
The probe asks the device at that address a yes or no question, and the answer colors the marker. Verify it in a minute with a packet capture: filter for ICMP, trigger the link check, and watch the echo request leave with nothing coming back. The colors carry defined meanings in the maker's documentation; one HMI manual defines its network LED as green once the link is up and blinking yellow on activity, so read the LED table before acting on a color. What the marker never carries is the state of the transfer session, which is a separate conversation on a separate protocol.
Why does the TCP port test pass while the LED stays red?
Because the two checks use different protocols. A TCP test to port 9999 completes a three-way handshake. The LED waits for an ICMP echo reply, type 0, answering the type 8 request the software sent. A router can drop one and pass the other.
The TCP utility opens a session and closes it; tcping.exe is the usual command line tool for the job. The LED's question travels as echo request type 8 and needs echo reply type 0 back. Routers keep those doors separate. Forwarding rules pass TCP sessions through to an internal address, while a filter on the WAN side can drop echo requests on purpose, a common and deliberate choice on routers facing the internet. That is why enabling ping replies on the router turns the LED green and leaves every other fact in the setup unchanged, including a broken rule further down the chain. A completed handshake with the router is not proof that the session continued to the panel, which is why the port test result and the transfer result get recorded as two separate lines in the log.
Is the panel ignoring ping too?
Check the panel after the router. Some HMI panels ignore ping until ICMP replies are switched on, and one maker documents exactly that fix. In this layout the probe targets the router's WAN address, so the router answers first and the panel is never asked.
The silent panel is a documented case: a fix note for an HMI that ignores ping until ICMP replies are enabled walks through the setting that wakes the reply up. Test your panel from its own subnet: ping the panel's address from a laptop on the same switch. A reply there and silence from outside means the panel answers locally and the WAN filter drops the probe, which is policy. Silence on both sides points at the panel's network settings first, then the router. Each result names the next device to open.
What do I check in the router rules, and in what order?
Open the forwarding rule for port 9999 and read five fields in order: protocol, external port, internal address, internal port, and the enabled flag. Then read the security or access rules for anything that denies forwarded traffic.
- Confirm the panel's current address. Read it from the panel's network setup page. If DHCP assigned it, reserve that address in the router; a fresh address after a power cut leaves the rule aimed at a device that no longer exists.
- Read the forwarding rule's five fields. Protocol set to TCP, external port 9999, internal address equal to the panel's current address, internal port 9999, and the enabled flag actually on. One stale field explains a rule that looks right and delivers nothing.
- Read the security and access rules. A deny here blocks sessions the forwarding rule already accepted, and it is the most common place for a passing port test to sit next to a dead transfer. Look for a deny that catches forwarded traffic, a source list narrower than your test host, or a filter aimed at port-forwarded sessions.
- Change the narrowest thing. Edit the one rule that blocks the transfer path and leave the rest as it stands. Do not disable the router's firewall or open a range of ports to make a test pass; that swaps a warning light for a real exposure.
- Retest and record. Run the TCP test and the transfer again from the same remote host, and write down three results separately: the TCP test, the transfer, and the LED.
For the fuller walk through forwarding checks, HMI remote access port forwarding fails: test each step takes the same path one step at a time.
Which symptom pairs with which cause?
Read the pairs together. A red LED beside a passing TCP test points at blocked ICMP. A failing transfer beside a passing test points at the rules. A completed transfer beside a red LED is a healthy setup that deserves a line in the log.
- Red LED, TCP test passes, transfer completes: working setup. The site blocks echo requests by policy. Document the red state as expected and stop.
- Red LED, TCP test passes, transfer fails: the break sits between the router's WAN side and the panel. Audit the security rules; the forwarding entry is probably fine.
- Red LED, TCP test fails: the forwarding rule or the panel address is wrong. Work the five fields and confirm the panel's current address.
- Ping answers inside, silent from outside: the router drops echo on the WAN interface. Policy, not a fault.
- Transfer fails on a timeout value: a different question with its own answer; HMI project transfer timeout: seconds, not milliseconds covers the units mix-up.
What does a worked example of the fix look like?
A plant forwards TCP 9999 on router 198.51.100.10 to its panel at 192.168.10.50, and four recorded tests tell an ICMP dead end from a broken rule.
Setup: the panel listens on TCP 9999, rule entry 4 of 12 forwards 9999 to it, and the programming PC sits on an office network across the internet.
- From the office PC, tcping 198.51.100.10 9999 connects, round trip 38 ms.
- From the same PC, ping 198.51.100.10 sends echo request type 8 and gets nothing back.
- From a laptop on the panel's switch, tcping 192.168.10.50 9999 connects, so the panel service is alive.
- The transfer attempt stops partway with no completion screen.
Read the arithmetic: two passes, tests 1 and 3, clear both endpoints; one silence, test 2, is the router's echo policy; one failure, test 4, puts the break between the router's WAN handshake and the panel. The LED's red is explained by test 2 and is innocent. The audit reads all 12 rules and finds entry 4 correct on all five fields, then finds a security rule denying forwarded sessions. The narrow change: allow the forwarded TCP 9999 session from the office's source address. Retest: the transfer completes, 6.4 MB in 41 s, about 1.25 Mbit/s (6.4 MB is 51.2 Mbit, and 51.2 divided by 41 is 1.25), slow office link, job done. Ping is still silent and the LED still reads red, which is now the documented, expected state. Score: 12 rules read, 1 changed, 4 tests, transfer complete.
How do I confirm the repair worked?
The repair is confirmed when the project transfer completes end to end and the result is written down for the next shift. A green LED is optional, because a router that blocks echo requests on purpose will keep the marker red on a healthy path.
Re-run all four tests after the rule change and log each result with a date. Save the corrected router configuration so a firmware update or a replacement unit does not quietly restore the old rules. Recheck the five fields whenever the panel's address changes, the router is updated, or a rule edit lands from another project. If the transfer still fails with correct rules in place, run a packet capture during one transfer attempt and read the router's deny log or port counters. The capture shows whether the transfer's TCP packets reach the router, and the counters show whether they leave toward the panel. Those two facts, gathered during the failing transfer, name the next device to open.
Should I forward the port at all, or use a VPN?
If you control the network, put the remote link on a VPN router instead of exposing port 9999 to the internet. Where a forwarded port already exists, keep the rule narrow: one port, one internal address, and source addresses limited to the networks that need the panel.
For new remote links, put the transfer inside a tunnel: Set up a VPN router for remote PLC and HMI access shows the layout where the panel and the programming PC share a routed tunnel and no port faces the internet. Where forwarding stays, leave the echo policy decision to the site's security owner and keep the rule to TCP 9999, one internal address, and named source networks.
Recommendation: judge every link by a completed project transfer and treat the offline-link LED as a report on one ICMP probe. If the site blocks echo on the WAN interface, expect the red LED, write that expected state into the network notes, and skip the hunt for green. For new links, choose the VPN layout; keep port forwarding only where the router can narrow the rule to TCP 9999, one internal address, and named source networks, and re-run the four tests after any rule, address, or firmware change.
Questions
Can a project transfer work while the offline link shows red?
Yes, when the rules are right and the router blocks echo requests by policy. The LED reads the ping probe, the transfer rides TCP 9999. Note the expected red state in the link entry's name or comment field if the software offers one, and in the network log, so nobody chases green on the next visit.
Why does the software ping the router instead of the panel?
The probe goes to the address stored in the link entry. If that entry holds the router's WAN address, the ping asks the router and the panel is never involved. Keep the entry pointed at the same address the transfer uses, and expect a reply only from a device whose policy permits echo.
What should I collect before calling the panel or router vendor?
Bring the forwarding rule export or screenshots showing protocol, external port, internal address and internal port, the security rules that mention forwarded traffic, the TCP test result from outside with its address and port, a packet capture of one failed transfer, and the panel's IP setup. Timestamped together, they let support separate a rule problem from a panel problem in one pass.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.