WinCC RT Advanced HMI Cross-Subnet Ping Failures: Troubleshooting

1. Problem Description

An industrial PC (IPC) running WinCC Runtime Advanced refuses to answer ICMP echo requests (ping) from devices on a different subnet, even though it responds correctly to pings from hosts on its own local subnet. The local network uses 10.10.141.0/24 with gateway 10.10.141.1, and the IPC itself is configured as 10.10.141.12. TIA Portal, the WinCC Runtime, and PROFINET communication all appear to function locally, but any SCADA host, engineering station, or remote PLC attempting to ping the HMI from a separate VLAN or routed network receives request timeouts.

This document walks through the root causes that produce this exact pattern and provides a step-by-step remediation procedure based on the actual diagnostic data extracted from ipconfig /all, route print, and the WinCC / TIA Portal runtime configuration. The discussion applies to PC-based RT Advanced stations running on Windows 10 IoT Enterprise LTSC 2019 / 2021, Windows Server 2016, and Windows Server 2019 deployed on SIMATIC IPC227G, IPC277G, IPC647D, IPC847D, or comparable industrial platforms with Intel I219-LM and Intel I210 Gigabit Ethernet adapters.

2. Symptom Analysis: Reading the Output of ipconfig /all

When the IPC is interrogated with ipconfig /all and route print -4, the picture is rarely as clean as the TIA Portal project tree suggests. In this case the active network adapter (an Intel I210 Gigabit Network Connection on an industrial motherboard such as SIMATIC IPC or a generic Kontron / Advantech platform) carries two IPv4 addresses simultaneously:

Two other Intel adapters are present and report Media State = Media disconnected:

The routing table enumerates routes with the interface metric 276 on all 10.x routes and a metric of 306 on the 127.0.0.0/8 loopback routes. The lower metric (276) is preferred and corresponds to a 100 Mbps link in the Windows automatic metric calculation (formula: metric = 10 + (link speed index); for 100 Mbps the index is 266, yielding 276). The crucial observation is that the secondary IP 10.255.255.242 has a /8 mask. The /8 mask (255.0.0.0) covers the entire 10.0.0.0 - 10.255.255.255 address space, which means this secondary address claims ownership of every "10.x" host the IPC could conceivably talk to.

Three ISATAP tunnel adapters (isatap.{...}) also appear with Media State = Media disconnected. ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is enabled by default on Windows for IPv6 transition but adds noise to interface listings and can confuse packet capture. They do not directly affect IPv4 routing, but they should be disabled in production.

3. Root Cause Analysis

Five distinct root causes converge to produce the local-ping-works / off-subnet-ping-fails pattern. Each must be verified and remediated before ping will succeed end-to-end.

3.1 Root Cause #1 - Overlapping IP Address Space (CIDR /8 versus /24)

The most damaging defect on this IPC is the secondary 10.255.255.242 address with a /8 mask. In IPv4, the longest prefix match rule dictates that the most specific route always wins, but Windows chooses the interface metric when multiple routes match with the same prefix length on the same physical adapter. The /8 route covers everything in the 10.0.0.0/8 supernet; the /24 route covers only 10.10.141.0/24. Both are bound to the same physical adapter, so the kernel's behavior for "off-subnet" traffic is governed by the lower-metric route, and the return path for the ICMP echo reply from the HMI is treated as if it originated from 10.255.255.242 rather than 10.10.141.12.

When the requesting host is on, for example, 10.10.142.0/24 (a separate routed network), the reply it expects back from 10.10.141.12 may be filtered, NAT-translated, or simply dropped because the source IP of the reply now looks like 10.255.255.242. The router at 10.10.141.1 sees a packet arriving from an address it never expected, and its stateful inspection or simple reverse-path check (uRPF) fails. From the operator's perspective, the HMI is "dead" off-net; in reality, the HMI is alive but unreachable because the wrong source IP is being stamped on the response.

Removing the offending address is the first priority. Use an elevated command prompt (Run as Administrator) and execute:

If the address reappears after a reboot or after restarting the WinCC Runtime, the secondary address is being injected by a Siemens service (see Section 3.5).

3.2 Root Cause #2 - Windows Firewall Profile Mismatch

The Windows Defender Firewall classifies every connected network into one of three profiles: Domain, Private, or Public. The classification depends on how the network was first seen, the presence of a domain controller, and whether the user actively toggled the profile. Industrial static networks (a /24 with no DHCP, no domain, no domain controller reachable) almost always fall into the "Public" profile by default because Windows cannot confirm that the network is trusted.

Several Siemens services install firewall rules that scope inbound ICMPv4, RPC, and SIMATIC S7 communication to the "Local Subnet" only. When the network is profiled as Public, the implicit deny rules are stricter and the Local Subnet scope shrinks to the host's own /32 address. ICMP echo replies can be generated by the kernel, but if the firewall hooks before the kernel reply (it does on Windows 10 / Server 2016 and later) and there is no explicit allow rule matching the inbound request's source subnet, the reply is silently dropped.

The default Siemens firewall rule set for WinCC Runtime Advanced typically opens the following ports, but only on Private / Domain profiles:

The fix is to either (a) reclassify the network as Private through the Settings app or PowerShell, or (b) add explicit ICMPv4-In rules scoped to the remote management subnets.

Set-NetConnectionProfile -InterfaceAlias "Local Area Connection" -NetworkCategory Private
New-NetFirewallRule -DisplayName "Allow ICMPv4-In (Remote SCADA)" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow -Profile Any -RemoteAddress 10.10.142.0/24,10.10.143.0/24

3.3 Root Cause #3 - Cable Connected to the Wrong NIC

The diagnostic data shows three physical NICs: one Intel I219-LM and two Intel I210 Gigabit adapters. Only one I210 is up. Industrial IPCs often have multiple LAN ports because they are intended for segregated automation networks (office LAN, control LAN, fieldbus LAN). If the Ethernet cable from the switch is plugged into the I219-LM (which is Media disconnected in this output, but the user may have moved the cable during diagnosis), the IP configuration assigned to that port will be irrelevant because no link is established, and the HMI appears unreachable even though the configuration looks correct.

Always verify the link state with the LED on the switch and the port on the IPC, and confirm that the active interface in Windows matches the port the cable is plugged into. Use Get-NetAdapter in PowerShell:

The output should show exactly one adapter with Status = Up and a LinkSpeed matching the negotiated speed (typically 100 Mbps or 1 Gbps). Compare that adapter's ifIndex against the interface index shown in route print -4 to confirm which adapter the 10.10.141.12 address is bound to.

3.4 Root Cause #4 - Default Gateway Metric Conflicts

The route table excerpt shows a metric of 276 on all 10.x routes and a metric of 306 on the 127.0.0.0/8 loopback routes. The lower metric (276) is preferred. On Windows, the automatic metric for an interface is calculated as 10 + (link speed index), and 276 corresponds to a 100 Mbps link. If the IPC has another interface that also has a default gateway with a lower metric, the reply path for ICMP echo can be sent out that other interface, never reaching the originating network. This is the classic asymmetric routing problem.

To inspect the metric on every active route:

The fix is to set a manual metric on the production interface to a low, unambiguous value:

Setting the metric to 10 makes the route definitively preferred without depending on link speed calculation. If multiple interfaces must coexist (one for the office LAN and one for the control LAN), ensure only the production interface carries a default gateway.

3.5 Root Cause #5 - Siemens Service Injects the Secondary Address

In WinCC Runtime Advanced projects that include the optional SmartServer component (used so that SmartClient panels can connect to the RT Advanced instance over the network), a background service can attach a secondary IP to the runtime adapter. This service writes a registry value under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID} and re-adds the secondary address on every adapter reset or service restart.

The operator reported that the secondary address "came straight back" after deletion, indicating a service-driven injection. To verify:

1. Open regedit and navigate to the active adapter's interface GUID.
2. Look for IPAddress (REG_MULTI_SZ). If it contains both 10.10.141.12 and 10.255.255.242, the Siemens service is the source.
3. Cross-reference with the WinCC project: if SmartServer is enabled, the secondary address is typically the redundancy partner address or the SmartServer binding address.

The remediation is to either disable the SmartServer feature in the WinCC project (Project → WinCC RT Advanced → Properties → Runtime → Services → SmartServer) or change the SmartServer's secondary binding address in the TIA Portal project to an address that does not collide with the production subnet.

3.6 Root Cause #6 - NetBIOS over TCP/IP and Name Resolution Confusion

NetBIOS over TCP/IP is enabled on the active adapter (the ipconfig /all output shows NetBIOS over Tcpip. . . . . . . . : Enabled). While NetBIOS does not directly affect ICMP echo, it can lead to name resolution side effects when the IPC and the remote SCADA host try to reach each other by hostname. If the remote host resolves foodmach-PC (the IPC's hostname) to the secondary 10.255.255.242 address through NetBIOS broadcasts, the connection fails even though the IP configuration looks correct.

For industrial networks with strict routing, disable NetBIOS over TCP/IP on the active adapter:

Or via the adapter properties dialog: uncheck Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced → WINS → Disable TCP/IP NetBIOS.

4. Diagnostic Procedure

Follow these steps in order on the IPC:

1. Capture the full ipconfig /all output. Look for multiple IPv4 addresses on a single adapter and note all subnets and metrics.
2. Run route print -4 and identify the lowest-metric route for 0.0.0.0/0. Confirm that this route uses the adapter carrying the production IP.
3. Run Get-NetAdapter and confirm link state, speed, and interface index on each NIC.
4. Check the Windows Firewall profile with Get-NetConnectionProfile. Note the NetworkCategory (Public, Private, Domain).
5. List active firewall rules related to Siemens services:
   Get-NetFirewallRule | Where-Object {$_.DisplayName -match "Siemens|SIMATIC|WinCC|S7"} | Format-Table DisplayName, Enabled, Profile, Direction, Action
6. Inspect TIA Portal PG/PC interface settings through the Start menu (Set PG/PC Interface). The active access point must point to the Intel I210 adapter with the correct TCP/IP parameters. Refer to the official Siemens KB article on configuring an S7 connection to WinCC RT Advanced over PROFINET.
7. Run Proneta to scan the local subnet for IP conflicts and unauthorized devices. Even if the production subnet shows no conflict, a duplicate 10.255.255.242 elsewhere on the routed path can produce identical symptoms.
8. Capture ICMP with Wireshark on the IPC while issuing a ping from the remote host. Observe whether the IPC receives the echo request and whether it generates an echo reply. If the reply is generated but never leaves the adapter, the firewall is the culprit. If the reply never generates, the routing table or the source IP selection is the culprit.

5. Solution: Step-by-Step Remediation

Apply each step in sequence. Each step is independently reversible.

Step 1 - Remove the Overlapping Secondary Address

If the address reappears, proceed to Step 5 to disable the Siemens SmartServer injection.

Step 2 - Disable and Re-Enable the Adapter

netsh interface set interface "Local Area Connection" admin=disable
netsh interface set interface "Local Area Connection" admin=enable

This forces the TCP/IP stack to re-evaluate the routing table and re-resolve the source IP selection.

Step 3 - Reclassify the Network as Private

Step 4 - Add Explicit Firewall Rules for ICMP and Siemens Ports

New-NetFirewallRule -DisplayName "Allow ICMPv4-In from Remote SCADA" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow -Profile Any -RemoteAddress 10.10.142.0/24
New-NetFirewallRule -DisplayName "Allow WinCC RT Advanced (TCP 2308) from Remote" -Direction Inbound -Protocol TCP -LocalPort 2308 -Action Allow -Profile Any -RemoteAddress 10.10.142.0/24
New-NetFirewallRule -DisplayName "Allow SIMATIC S7 (TCP 102) from Remote" -Direction Inbound -Protocol TCP -LocalPort 102 -Action Allow -Profile Any -RemoteAddress 10.10.142.0/24

Replace the RemoteAddress values with the actual subnets of the management network. Avoid -RemoteAddress Any for production deployments.

Step 5 - Disable SmartServer Secondary Binding

In TIA Portal, navigate to the WinCC RT Advanced device, open Properties → Runtime → Services, and disable SmartServer if it is not required. Recompile and download the project to the IPC.

If SmartServer is required, change the secondary binding IP to an address that does not collide with any production subnet. Refer to the TIA Portal documentation on HMI connection configuration for the exact property paths.

Step 6 - Lock the Interface Metric

Step 7 - Disable NetBIOS over TCP/IP

Step 8 - Reboot and Verify

After the reboot, capture ipconfig /all, route print -4, and Get-NetConnectionProfile again to confirm that the secondary address did not return and that the network is classified as Private.

6. Verification

Run the following checks from both a local host on 10.10.141.0/24 and a remote host on 10.10.142.0/24:

If the remote ping still fails after all remediation steps, capture Wireshark on the IPC and the remote host simultaneously and inspect the echo request / reply pairs. The reply will reveal which source IP the kernel is selecting for the return path. If the reply is stamped with 10.255.255.242, Root Cause #5 is still active. If no reply is generated, Root Cause #2 (firewall) is still active. If the reply is generated with 10.10.141.12 but never arrives at the remote host, Root Cause #4 (routing) or the upstream router's reverse-path filter is the culprit.

7. Prevention and Best Practices

• Single IP per adapter. Never assign more than one IPv4 address to a TIA Portal runtime adapter unless the second address is documented in the project (for example, redundancy). Document every secondary address in the project handover package.
• Lock subnet masks. Use /24 masks for industrial networks. Avoid /8 or /16 masks on adapters that have a default gateway pointing into a smaller subnet.
• Standardize firewall profiles. Use Group Policy or local policy to force all industrial network adapters to the Private profile. Do not rely on user-driven profile classification.
• Document NIC labeling. Label each physical port on the IPC with the intended network (for example, "CTRL_NET", "OFFICE", "FIELD"). Verify the label matches the IP configuration in ipconfig /all.
• Disable unused adapters. If a NIC is not used, disable it in Device Manager and remove its protocol bindings to eliminate them from the routing table.
• Use static configuration in TIA Portal. Define the HMI IP address in the TIA Portal project (HMI device → Properties → Communication → Connection → IP Address) and let the runtime apply it on startup rather than relying on Windows network settings alone.
• Use Siemens Proneta to audit the network at commissioning and after every change. Proneta will flag duplicate IPs and unauthorized devices.
• Plan for SmartServer. If SmartServer / SmartClient is a project requirement, dedicate a separate NIC for it and isolate it on a management VLAN.
• Disable ISATAP. ISATAP tunnel adapters add noise to interface listings and can confuse packet capture. Disable via Set-NetAdapterBinding -Name "isatap.*" -Enabled $false.

8. Related TIA Portal Configuration

When commissioning a WinCC RT Advanced HMI, the connection to the S7 controller is configured in TIA Portal under Devices → HMI → Connections → [new HMI connection]. The HMI connection requires three pieces of information: the S7 controller's IP address, the S7 controller's slot, and the HMI's own IP address. The HMI's IP address is entered in the HMI device properties under Communication → Ethernet address and must match the Windows adapter configuration exactly. Refer to the official Siemens KB article on configuring a connection between WinCC RT Advanced and an S7 controller over PROFINET for the exact menu paths and version-specific notes for TIA Portal V16, V17, and V18.

For PC-based RT Advanced stations, the IP address of the runtime is configured through TIA Portal and applied by the WinCC Runtime loader on startup. If the Windows adapter and the TIA Portal configuration disagree, the runtime will use one and the OS will use the other, leading to the exact "local-only ping" symptom described in this document. Always reconcile the TIA Portal project IP with the Windows adapter IP, and remove any conflicting secondary addresses before commissioning. The TIA Portal help library on configuring HMI connections documents the supported protocols (SIMATIC S7, OPC UA, Modbus TCP) and the corresponding port allocations.

9. Frequently Asked Questions