Resolving Duplicate PLC IP Addresses via SCALANCE NAT and WinCC

1. Problem Statement: Two PLC Networks, One Duplicate Address Space

A common field situation in brownfield plants and machine retrofit projects: two (or more) independent Siemens automation cells were commissioned years apart by different integrators, and both ended up using the same default IPv4 address range — typically 192.168.0.0/24, 192.168.1.0/24, or 10.0.0.0/24. Individual CPUs and ET200 stations even share the same node address (for example, 192.168.0.1 on both S7-1500 CPUs).

When an operator or engineer wants to consolidate the visualization on a single PC running WinCC Professional (TIA Portal V17 or higher), the operating system's TCP/IP stack can no longer disambiguate the two physical destinations. ARP requests return whichever device answers first, S7 connections fail with 0x0000 / 0x80A1-class errors, and HMI tags go out-of-service.

Because the PLC hardware configuration is frozen (or because both machines cannot be taken down simultaneously), the addressing inside HW Config cannot be edited. The fix must therefore live in the network infrastructure between the PC and the two cells, not in the PLCs themselves.

2. Why Subnet Mask Tricks and Multi-Homed NICs Will Not Save You

A frequently proposed workaround is to widen the PC's subnet mask to 255.255.0.0 so that two different third-octets both appear "local" and the OS will ARP for both. This trick does not resolve the duplicate-address problem because:

• The duplicate conflict is on the full host address, not on the subnet boundaries. Two CPUs at 192.168.0.10/24 and 192.168.10.10/24 can coexist on a PC whose mask is 255.255.0.0, but two CPUs both at 192.168.0.10/24 cannot, regardless of mask.
• WinCC's S7 communication channel opens ISO-on-TCP (RFC 1006) connections to a single configured partner IP. The driver does not load-balance across two physical media for one tag — it needs one unambiguous destination per logical connection.
• Multi-homed Windows hosts with two NICs will sometimes round-robin or default-route traffic unpredictably, producing intermittent SF (system fault) LEDs on the S7 CPUs and HMI Connection Failure events in the WinCC alarm log.

Industrial NAT at Layer-3 is the deterministic answer.

3. Prerequisites

4. Solution Architecture: 1:1 NAT at the Cell Boundary

The reference topology places one SCALANCE S615 between each PLC cell's managed switch (e.g. SCALANCE XC206) and the plant backbone that carries the WinCC PC. The S615 performs 1:1 bidirectional Network Address Translation: every internal IP is mapped to a unique external (plant-side) IP, so the WinCC PC sees two completely independent address ranges.

Internal Cell A: 192.168.0.0/24 (unchanged, untouched in HW Config)
External Cell A as seen by WinCC: 10.10.10.0/24

Internal Cell B: 192.168.0.0/24 (also unchanged)
External Cell B as seen by WinCC: 10.10.20.0/24

The PLCs themselves are unaware of the translation. They believe they are still talking to 192.168.0.50; the S615 rewrites the source/destination on every packet.

5. SCALANCE S615 Hardware and Firmware Notes

The SCALANCE S615 (article number 6GK5615-0AA00-2AA2) is a DIN-rail security/NAT router with five Gigabit ports, hardware-encryption offload, and a hardened metal housing rated −40 °C to +70 °C. The relevant firmware train for NAT is:

• FW V2.0 — first release to fully support 1:1 NAT with overlapping subnets.
• FW V2.2 — adds Connection Tracking improvements for S7-1500 PUT/GET.
• FW V2.5+ (current) — recommended for new deployments; supports NAT, NAPT, and port-restricted NAT simultaneously.

Verify the running firmware under System > Information in the Web Based Management. Always upgrade to a current stable release before commissioning; firmware files are published under SIOS entry 109751656.

6. Configuring 1:1 NAT on the SCALANCE S615

1. Connect a service laptop to the SCALANCE S615's P1 port (the leftmost port, default DHCP server on 192.168.200.0/24).
2. Browse to https://192.168.200.1 and accept the self-signed certificate.
3. Navigate to Layer 3 > NAT > 1:1 NAT.
4. Create one mapping row per PLC CPU that must be reached from the WinCC PC. The column meanings are:

5. Enable Connection Tracking under Layer 3 > Firewall > Connection Tracking so return packets from the PLCs are translated back to the WinCC-visible external IPs. Without this, the S7 handshake completes (TCP SYN/ACK) but the first PUT/GET frame fails with W#16#80A1.
6. Under Layer 3 > IP > Interfaces, assign two IP addresses to the external (plant-side) interface: the gateway of the cell (10.10.10.254/24) and, if you require management access, a secondary 10.10.10.250/24.
7. Click Commit and export the configuration as a .conf backup.

7. WinCC Professional: Configuring Two S7 Connections

1. Open the HMI project in TIA Portal. Right-click HMI Tags > Show HMI Connections.
2. Add a new connection HMI_Connection_CellA:

3. Repeat for HMI_Connection_CellB, but use 10.10.20.1 as the partner IP.
4. Compile the HMI project. TIA will surface a warning if the two connections share the same Access Point — this is informational, not an error.
5. Download the WinCC Runtime to the target PC. The Runtime will open two independent ISO-on-TCP connections on port 102, one to each external IP.

8. PLC-Side Gateway (When One Must Be Configured)

If the PLC must initiate connections to the WinCC PC (for example, the WinCC station is also an OPC UA server the PLC pushes alarms to), the CPU must know a default route. Since the cell-side addressing cannot be changed in HW Config, the gateway must be added as an additional IP route in the PLC's project:

1. In TIA Portal, open the PLC's device configuration.
2. Select the PROFINET interface > Ethernet addresses > IP protocol > Router.
3. Add a default router entry: 192.168.0.254 with mask 255.255.255.255. The .254 address is the SCALANCE S615's internal interface IP.
4. Recompile and download the hardware configuration. If the plant cannot be taken offline, perform the download via the S615's management tunnel using TIA's "Online > Accessible nodes" reachable through the plant-side IP.

If the PLC is purely a server (WinCC initiates all connections) — which is the normal case for HMI/SCADA topologies — the gateway entry is unnecessary; WinCC will reach the PLC through the S615's 1:1 NAT transparently.

9. Verification and Diagnostics

1. Ping the external IPs from the WinCC PC:
   ping 10.10.10.1 and ping 10.10.20.1. Both must reply with sub-millisecond latency to the SCALANCE S615 plus internal switch hop.
2. TIA "Accessible nodes" must show both CPUs under their translated addresses.
3. SCALANCE S615 diagnostics: Information > NAT > Connections should display two active S7 sessions, one per cell. If only one is listed, Connection Tracking is likely disabled.
4. WinCC Channel Diagnostics: enable the S7 channel trace via WinCC Explorer > Tools > Channel Diagnosis. Look for Connection established to AS 10.10.10.1 and Connection established to AS 10.10.20.1.
5. Wireshark on the WinCC PC: capture the external interface and confirm you see SYN to 10.10.10.1:102 and 10.10.20.1:102. The S7 driver must always use port 102 on both ends.

10. Alternative Topologies When NAT Is Not Acceptable

Some plant cyber-security policies forbid address translation in the OT path. In those cases the following alternatives apply:

• VLAN segmentation with VRF-style routing on the backbone: keep the cells isolated in separate VLANs and use a Layer-3 core switch to enforce "one broadcast domain per cell." The WinCC PC must still only see one cell's IP range per NIC, which effectively forces the same dual-NIC + dual-NAT pattern.
• Two physical NICs in the WinCC PC, each with one cell's address as primary, and a static route for the other cell's external range pointing to NIC 2. Workable, but loses the single-fault-domain benefit of NAT.
• S7 routing functions (S7-300/400 only) via the S7 Routing tab in NetPro. Useful when one CPU is the gateway for another; does not solve the duplicate-address problem on its own and is not supported on S7-1200/1500 in the same form.
• Renumber the cells: the cleanest long-term answer. Use TIA's Online > Accessible nodes > Assign IP and a maintenance window to migrate one cell to 192.168.10.0/24. Schedule this in the next planned outage.

11. Field-Proven Caveats and Edge Cases

• S7-1500 Access Protection: when the CPU security level is set to "Complete" (TIA V16+), PUT/GET from WinCC is blocked regardless of NAT. Configure Properties > Protection > Connection mechanisms > Permit access with PUT/GET on each CPU.
• Certificate handling on S7-1500 with TLS: if the CPU forces secure PG/HMI communication, the SCALANCE S615 must not deep-inspect the payload. The S615's "IPSec passthrough" mode is on by default — leave it enabled.
• OPC UA over NAT: OPC UA discovery uses reverse-connection URLs that contain the CPU's IP. After NAT the URL still shows the internal address; either disable discovery or hard-code the external IP in the WinCC OPC UA client.
• PROFINET DCP: PROFINET device discovery is multicast and crosses routers only with PROFINET-aware helpers. SCALANCE S615 supports DCP forwarding in firmware V2.0+; otherwise TIA "Accessible nodes" will not see the devices, but WinCC Runtime will still work because it uses configured (not discovered) connections.
• Time sync (NTP): both cells can keep their independent NTP servers on the inside; from the WinCC PC's perspective only the external IPs of the S615 NTP relay need to be configured. The S615 itself supports NTP forwarding.
• High-availability: if the plant requires redundant paths, deploy two S615 in parallel (Active/Passive via VRRP). The SCALANCE S615 supports VRRP from firmware V2.2; configure identical external IPs and a shared virtual MAC.
• CPU load on the S615: a fully loaded 1:1 NAT table with 5,000 entries begins to drop frames at line-rate gigabit. For cells with more than ~200 PLC nodes, segment the NAT per CPU subnet (e.g. one S615 per 64 nodes) or move to a SCALANCE SC646-2C with higher throughput.

12. Long-Term Recommendation: Renumber

1:1 NAT is a robust bridge solution. It is, however, an additional piece of network hardware that must be patched, backed up, and replaced when it fails. As soon as a maintenance window allows, migrate one cell to a non-overlapping subnet (192.168.10.0/24 is the typical choice) and remove the SCALANCE S615 from the topology. Until then, the configuration documented in Sections 4–9 will reliably run two cells with identical addressing side-by-side on a single WinCC station.

Frequently Asked Questions