Resolving WinCC 7.3 S7 Communication Failures Across Routed

1. Problem Overview

When a Siemens WinCC V7.3 SCADA station cannot reach an S7 PLC even though ICMP ping replies succeed, the issue almost always lies in the layer between SIMATIC NET, the S7 Protocol Suite, and the Windows routing stack. The WinCC server application is reachable, the TCP/IP path is open, yet S7DOS / S7 Online drivers report failure and the HMI tags remain in "connection error" state.

This reference documents a specific field case: a pair of Windows Server 2012 R2 virtual machines running WinCC V7.3 SP1, redundant configuration, communicating with S7-300 / S7-400 PLCs on a physically separated subnet, with intermediate Cisco routed links. Ping returns < 1 ms round-trip time, but WinCC's connection diagnostics show the error code 0x42C2 (S7 protocol: "Object could not be opened / connection to partner could not be established").

2. Affected System Architecture

3. Symptoms and Observed Error Codes

WinCC displays the connection to the PLC in red, the @ prefix tags (@ConnectedToPLC) return FALSE, and the runtime logs populate with one of the following recurring codes:

4. Root Cause Analysis

After eliminating IP / DNS / physical layer as the issue (ping works across all three subnets), the residual failure space collapses to five categories. Apply this decision tree in order:

1. Logical device name vs. access point mismatch. The S7 Protocol Suite connection in WinCC Explorer references an "access point" (e.g. S7ONLINE). The access point must be bound to a logical device that actually points at a working CP (e.g. CP_TCPIP_1 → a real Intel / VMXNET3 adapter). If the access point is bound to a non-existent or disabled device, every connect attempt times out.
2. SIMATIC NET version mismatch. WinCC V7.3 SP1 was qualified against SIMATIC NET V13 SP1. Installing V12 with V13 in parallel corrupts the s7oiehsx.exe shim service and the OPC UA / S7 routing table. This is the most common cause of the 0x42C2 signature after a clean WinCC install.
3. Routed network — S7 protocol behavior. S7 communication over TCP uses ISO Transport (RFC 1006) on destination port 102. The S7 partner may have its connection resources exhausted if the PLC CP has fewer active connections configured than WinCC requests. Default on CP 343-1 is 8 connections; WinCC typically requests 2 (one for diagnostics, one for tag traffic). Verify the CP connection count in STEP 7 / TIA Portal hardware configuration.
4. Windows Firewall on Server 2012 R2. Server 2012 R2 ships with the firewall enabled. After the first reboot post-install, the previously allowed SIMATIC_NET_CP and s7oiehsx rules may be removed if SIMATIC NET was upgraded. Blocked inbound on TCP 102 manifests exactly as 0x42C2.
5. VM virtual adapter quirks. VMware vmxnet3, E1000, or Hyper-V synthetic adapters all behave correctly for ISO-on-TCP, provided promiscuous mode is not required and the physical switch port is set to trunk/access as expected. If the VM was migrated between hosts with different virtual switch MAC tables, ARP caches on the Cisco router may take 5–15 minutes to refresh.

5. Pre-Diagnostic Checklist

Before opening the WinCC Explorer or uninstalling software, verify the following. Each item takes under 60 seconds:

• ping <PLC_IP> -t from the VM host for 30 seconds — must show 0% loss, < 5 ms RTT.
• telnet <PLC_IP> 102 from the VM — must show a black screen and not "connection refused" or timeout. A blank Telnet window is the cleanest proof that the S7 transport port is reachable.
• On the PLC side, in STEP 7 / TIA, open CP Diagnostics → Connections and confirm the connection to the WinCC IP is established or incoming (not idle).
• Open Set PG/PC Interface (Start → Siemens Automation → Set PG/PC Interface) on the WinCC server. Confirm that S7ONLINE access point is bound to CP_TCPIP_1::<NIC_GUID> matching the NIC that has the routing default gateway.
• Verify SIMATIC NET version: Control Panel → Programs → "SIMATIC NET PC Software". It must read a version consistent with the WinCC compatibility matrix.

6. Diagnostic Procedure — Step by Step

1. Capture the baseline log. Stop the WinCC Runtime, copy C:\Program Files (x86)\Siemens\WinCC\diagnose\SIMATIC_S7_PROTOCOL_SUITE_0x.LOG to a working directory. Clear or rename any older log.
2. Start Runtime with diagnostic verbosity raised. In WinCC Explorer, right-click the S7 Protocol Suite channel → "Channel Diagnosis" → enable "Extended Logging" (writes to the same file with extra detail).
3. Trigger the connection attempt. Re-start Runtime. Wait 30 seconds.
4. Read the error block. Open the log, search for 0x42C2. The three lines above the error contain: the access point used, the target IP, the slot / rack, and the connection resource ID. This is the single most useful data set in the entire diagnostic flow.
5. Validate the access point. Run Set PG/PC Interface and confirm the S7ONLINE access point is bound to the correct CP. If it is bound to a non-existent device, you will see something like (unbound) or a grayed-out NIC name.
6. Rebind if necessary. Select the correct access point → Properties → assign the real TCP/IP NIC. Click OK. No reboot is required for the binding change to take effect, but the SIMATIC NET service s7oiehsx must be restarted:

net stop "s7oiehsx.exe"
net start "s7oiehsx.exe"

7. Retest. Re-trigger the connection. If 0x42C2 persists, the access point is correct and the failure is downstream of the S7 shim — proceed to Section 7.

7. SIMATIC NET Configuration

SIMATIC NET provides the S7 DOS shim (s7dos.dll) and the s7oiehsx routing service. Both must be installed by the same SIMATIC NET version. The configuration console is the SIMATIC NET Configuration shortcut in the Start menu (also called "Commissioning" in older releases).

Verify the following entries exist in the configuration:

• PC station name matches the Windows computer name exactly (case-insensitive, but the match must be exact).
• Index 1: S7ONLINE access point is associated with the TCP/IP NIC used to reach the PLC subnet.
• OPC UA / S7 routing — if you only need native S7, the OPC UA service can be disabled. If OPC is in use, ensure the certificate store under C:\ProgramData\Siemens\Automation\certstore is not empty for the runtime user.

After any change in the SIMATIC NET Configuration, the Station Configuration Editor must be reopened and "Station -> Save and Compile" run. This regenerates the PCStation.xml consumed by the s7oiehsx service.

8. Logical Device Names and Access Points

The mapping below is the canonical source of the "access point not bound" failure. Pin it to the wall of the engineering room.

To rebind an access point:

1. Open Start → Siemens Automation → Set PG/PC Interface.
2. From the dropdown "Access Point of the Application", select S7ONLINE.
3. In the "Interface Parameter Assignment Used" list, pick the entry that reads CP_TCPIP_1 → <your NIC>. Do not select entries with greyed-out NIC names.
4. Click OK. A dialog confirms: "The interface was assigned successfully".
5. Restart the SIMATIC NET service: net stop s7oiehsx && net start s7oiehsx from an elevated command prompt.

For the official procedure, see the Siemens Knowledge Base entry "Why is the connection from WinCC to the S7 controller not established via TCP/IP?" in the Siemens Industry Online Support portal.

9. Network Routing Considerations for S7

WinCC does not require the S7 traffic to remain in a single broadcast domain. ISO-on-TCP (RFC 1006) is routable across L3 boundaries. The following must hold true for the routed path:

• The Windows routing table on the WinCC server must have a host route or a subnet route for the PLC IP, with the correct next-hop gateway. Verify with route print.
• All intermediate routers (Cisco L3 switches in this case) must permit TCP 102 in both directions. The Cisco ACL on the relevant VLAN interfaces must include a rule equivalent to:

permit tcp <wincc_subnet> <wincc_wildcard> host <plc_ip> eq 102
permit tcp host <plc_ip> eq 102 <wincc_subnet> <wincc_wildcard> established

• If NAT is in use (uncommon in industrial networks, but it occurs in brownfield integration with corporate IT), the S7 connection must be NAT-friendly. ISO Transport embeds the IP inside the S7 payload in some configurations, and NAT will break this. Use TCP (not ISO) variant of the S7 connection in NAT'd environments, configured in STEP 7 under the CP's "TCP Connection" rather than "ISO-on-TCP Connection".
• MTU: ISO-on-TCP has an overhead of ~120 bytes. If the path traverses a VPN or GRE tunnel with MTU 1400, fragmentation will cause the S7 handshake to drop silently. Test with ping -f -l 1400 <plc_ip> and adjust the router MTU if needed.

10. VM-Specific Considerations

When WinCC runs inside a virtual machine, three additional failure modes appear that are absent on bare metal:

Additionally, on Server 2012 R2, ensure the following Windows Firewall rules are present and enabled:

• Inbound: SIMATIC NET S7 Communication (or equivalent s7oiehsx.exe rule) — TCP, local port 102, profile: domain.
• Inbound: SIMATIC NET OPC UA — TCP, local port 4840 (only if OPC UA is used).
• Outbound: TCP remote port 102 to the PLC subnet.

To script the firewall rules for SIMATIC NET in an elevated PowerShell:

New-NetFirewallRule -DisplayName "SIMATIC NET S7 Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 102 `
  -Action Allow -Profile Domain,Private
New-NetFirewallRule -DisplayName "SIMATIC NET S7 Outbound" `
  -Direction Outbound -Protocol TCP -RemotePort 102 `
  -Action Allow -Profile Domain,Private

11. Resolution Procedure

Apply the steps in this order. Each step is independent and verified; do not skip ahead.

1. Bind the correct access point. Open Set PG/PC Interface, set S7ONLINE to the TCP/IP NIC with the route to the PLC. Restart the s7oiehsx service.
2. Remove the wrong SIMATIC NET version. If V12 is installed with V13, uninstall V12 completely, reboot, then run "Repair" on V13 SP1 via Control Panel.
3. Recompile the PC Station. Open SIMATIC NET Configuration → Station Configuration Editor → Station → Save and Compile. The output PCStation.xml must regenerate cleanly with no warnings.
4. Open the Windows Firewall ports. Apply the two PowerShell rules above (or use wf.msc with the GUI). Verify with Get-NetFirewallRule -DisplayName "SIMATIC NET*".
5. Validate the CP connection count on the PLC. In STEP 7 / TIA, open the CP properties → "Options" → confirm the S7 connection resource for the WinCC partner is set to "Active" (WinCC initiates) or "Passive" (PLC waits) and is not exceeding the CP's total connection limit.
6. Test with WinCC Channel Diagnosis. In WinCC Explorer → S7 Protocol Suite → right-click the connection → "Connection Status". Status should turn from red "Not Connected" to green "Connected".
7. Verify in Runtime. Start WinCC Runtime. The internal tag @ConnectedToPLC should report 1 for all configured PLCs within 30 seconds. The diagnose log will show 0x0000 (success) where 0x42C2 previously appeared.

12. Verification and Validation

Confirm the fix is complete and stable with the following checks. Run them at least twice, 5 minutes apart, to rule out transient flap:

• Open WinCC Channel Diagnosis → S7 Protocol Suite → the connection should be "Established, OK".
• From the WinCC server command line: telnet <PLC_IP> 102 still returns a black screen.
• Open the WinCC tag browser, force a read of a known-changing process tag (e.g. a counter incremented in the PLC). Value should update at the configured acquisition cycle, no "<BAD>" quality stamp.
• Restart the WinCC Runtime service. The connection should re-establish automatically within 30 seconds; no manual intervention required.
• Failover to the redundant WinCC server. The standby should promote to master and re-establish all PLC connections within the configured redundancy switchover time (default 60 s).
• Check the diagnose log size: a healthy system generates roughly 50–200 lines per hour. A spiking log (> 5,000 lines/hour) indicates retry storms — re-verify Sections 7 and 8.

13. Preventive Measures and Hardening

Once the immediate failure is cleared, lock the configuration against recurrence:

• Document the access point binding in the project's engineering backup. A change to the Windows network stack can silently rebind the access point to a NIC that no longer has the route.
• Pin the SIMATIC NET version in the project documentation. Reject any patch that crosses a major version boundary (V12 → V13, V13 → V14) without a regression test against the full tag list.
• Add a scheduled task on the WinCC server that runs netstat -an | findstr :102 every 5 minutes and logs the result. A missing entry means the S7 shim is not listening — your earliest warning of regression.
• For VM hosts, disable vMotion for the WinCC servers, or pin MAC addresses. The cost of vMotion downtime is rarely worth the gain for a 24/7 HMI.
• On the Cisco routed path, add an SNMP trap or syslog message for any ACL deny on TCP 102. This converts a future 0x42C2 into a 10-second fix instead of a 3-hour diagnostic session.

14. Related Configuration Reference

Quick reference for the values that are most often wrong in the field:

FAQ