SCALANCE S612 VPN Setup: Resolving IP Collision in Bridge Mode

The Siemens SCALANCE S612 (article number 6GK5612-0BA10-2AA3) is a security appliance designed to provide VPN-protected access between an internal (factory) network and an external (office) network. One of the most common field issues during commissioning is an IP address collision warning that appears on Windows clients when both sides of the SCALANCE are configured on the same IP subnet (for example, 172.16.13.0/24 on both the factory and office sides). This article explains the root cause, why bridge mode does not solve the problem, and the supported remediation paths.

1. Problem Description

A typical commissioning scenario looks like this:

• Office network: 172.16.13.0 / 255.255.255.0
• Factory network: 172.16.13.0 / 255.255.255.0
• SCALANCE S612 inserted between the two networks, configured for VPN tunnel only (no routing between sites except through the tunnel).

Symptom: As soon as the SCALANCE is brought online, Windows clients on the office network raise an "IP address conflict" pop-up, and clients on the factory side become intermittently unreachable. The VPN tunnel itself can still be established (certificates, IKE, and Phase 2 are all valid), but the LAN side of the device emits the conflict notification because it has learned the same MAC/IP pair from both directions.

If the engineer tries to switch the device to Routing mode to stop the broadcast bleed-through, the Security Configuration Tool (SCT) returns a download error such as:

Error: IP address range of internal and external interface overlap.
The configuration cannot be applied to the device.

This warning is generated client-side by the SCT before the configuration is even pushed to the SCALANCE, because the tool recognizes the overlapping subnets as a configuration error.

2. Root Cause Analysis

The collision is a direct consequence of Layer 2 transparency when bridge mode is enabled, combined with the duplicate IP address space on both sides of the device.

2.1 What Bridge Mode Does on the S612

In bridge mode, the SCALANCE S612 forwards Ethernet frames between the internal (P1) and external (P2) interfaces as if they were on the same segment. The IP addresses of the two interfaces are not used as gateway addresses — only as management endpoints. The bridge remains transparent to ARP, DHCP, and broadcast traffic. Any host that sends an ARP request on one side of the bridge is heard on the other side as well.

This means that if host 172.16.13.42 exists on the office side and another host 172.16.13.42 exists on the factory side, each host's ARP cache will be polluted by gratuitous ARP replies from the other side. Windows detects this and raises the IP conflict dialog. The bridge cannot be made "selective" — it does not understand which frames belong to the VPN tunnel and which do not, because the tunnel is a Layer 3 construct riding on top of the bridge.

2.2 Why Routing Mode Rejects the Same Range

In routing mode, the SCALANCE becomes a Layer 3 router with two distinct interfaces (for example, 172.16.13.1/24 on the internal side and 192.168.1.1/24 on the external side). Routing mode mandates that the two directly connected subnets be different — that is the definition of routing. If both interfaces are assigned 172.16.13.0/24, the device has no way to determine which interface a packet destined for 172.16.13.42 should leave on. Hence the SCT and the device firmware both reject the configuration.

This is consistent with the documented behavior described in the SIMATIC NET online help: "Error message when downloading the configuration" — incorrect device selection, incompatible firmware, and address conflicts are the most common causes of a failed download to a SCALANCE device.

3. SCALANCE S612 Hardware and Firmware Context

4. Bridge Mode vs. Router Mode Comparison

The table makes the core engineering constraint explicit: neither operational mode permits two directly connected subnets to share the same address range. The behavior is a property of TCP/IP itself, not a SCALANCE-specific bug.

5. Supported Solution Options

There are exactly three supported paths. Each one is fully described, with the trade-offs spelled out, so that the right choice can be made for the plant context.

5.1 Option A — Renumber One Network (Recommended)

Re-address either the office network or the factory network into a non-overlapping subnet. This is the only configuration that is unambiguously supported by the device firmware and that does not introduce any traffic filtering risk.

Typical re-addressing plan:

1. Choose a new /24 (or longer) prefix that is not in use on the other network — for example, factory stays on 172.16.13.0/24 and office moves to 10.20.30.0/24, or office stays and factory moves.
2. Update the DHCP scope or static assignments on the chosen side.
3. Update the SCALANCE S612 management IP on the affected side to the new subnet (e.g. 10.20.30.1/24).
4. Re-issue the VPN endpoint certificate with the correct SAN/IP, or re-enter the new peer address into the VPN peer definition.
5. Recompute any static routes, firewall rules, and DNS entries that reference the old range.

This is the long-term-correct solution. It eliminates the duplicate-IP problem and allows the SCALANCE to operate in either bridge or router mode without further workarounds.

5.2 Option B — Router Mode with NAT (1:1) on the Tunnel Side

If renumbering the office network is politically or operationally impossible, the factory network can be NAT-translated on the SCALANCE so that from the office side it appears to be a different subnet. For example:

• Office real subnet: 172.16.13.0/24
• Factory real subnet: 10.50.50.0/24 (renumbered to break the overlap)
• Factory presented subnet to office via VPN 1:1 NAT: 172.16.13.0/24

From the office side, hosts reach the factory using the original 172.16.13.x addresses, but the SCALANCE rewrites the source and destination addresses to the real 10.50.50.x range when crossing the tunnel. This still requires renumbering the factory network in reality — the only thing that changes is the addressing visible to office clients. It is therefore a more complex variant of Option A.

5.3 Option C — Insert a Dedicated Tunnel Subnet on the S612

Configure the SCALANCE in router mode and assign a small, dedicated subnet (e.g. 192.168.250.0/30 or /29) to the tunnel interface. Remote VPN clients are then given an address from this dedicated pool, and the host networks on both sides retain their original (but now non-overlapping) ranges. This pattern is the standard for road-warrior / telecommuter access rather than site-to-site, but it is the only topology in which the S612 can be left untouched on the LAN side.

6. Step-by-Step: Renumbering with Router Mode

The following procedure assumes that the office network is being re-addressed to 10.20.30.0/24 while the factory network stays on 172.16.13.0/24. Adapt as required for the chosen direction.

6.1 Prerequisites

• Security Configuration Tool V3.0 (HF1 or later) installed on the engineering station.
• SCALANCE S612 reachable on its current management IP (default 192.168.1.1 if factory-reset).
• Current project backup (.sct file).
• List of DHCP reservations, DNS entries, and any firewalls that reference the old office range.

6.2 Procedure

1. Open the project in SCT and verify the device firmware matches the article number. A mismatch is one of the documented causes of a download error per the SIMATIC NET download error documentation.
2. Switch the S612 to router mode in the project tree. The two interfaces must each carry a unique subnet.
3. Set the internal (factory-facing) interface to 172.16.13.1 / 255.255.255.0.
4. Set the external (office-facing) interface to 10.20.30.1 / 255.255.255.0.
5. Define the VPN tunnel as before, but update the local and remote endpoint definitions to the new management IP if the VPN endpoint is the management IP itself.
6. Save the project and trigger a download. The SCT should no longer raise the "overlapping range" error.
7. On the engineering station, change its own IP to a 10.20.30.x address on the office side and re-connect to https://10.20.30.1 to verify management access.
8. Reconfigure the office DHCP scope to hand out 10.20.30.100–10.20.30.200, with gateway 10.20.30.1 and DNS as before.
9. Reboot office clients or release/renew their DHCP leases.
10. Test the VPN tunnel by initiating a connection from a remote peer. The Phase 1 / Phase 2 SA should establish without re-authentication of certificates if the endpoints and IDs are unchanged.

6.3 Verification

1. From an office host on 10.20.30.x, ping 172.16.13.1 (the SCALANCE internal interface). The reply confirms router-mode routing is working.
2. From a factory host, ping 10.20.30.1. The reply confirms the reverse direction.
3. Establish the VPN tunnel and verify that traffic flows end-to-end by pinging a known factory host (e.g. 172.16.13.50) from a VPN client.
4. Check the S612 event log (Web UI → Information → Log Table) for the absence of duplicate-IP or ARP-flood entries.
5. Confirm on a Windows client that no IP-conflict pop-up is raised for at least 24 hours of normal operation.

7. Common Error Messages and Their Meaning

8. Why the VPN Tunnel Cannot Itself Separate the Subnets

A common misconception is that an IPsec VPN tunnel encapsulates traffic in such a way that the inner IP addresses are "hidden" from the local segment. This is only true for traffic that actually crosses the tunnel. Before a packet is encapsulated, it must already be routed to the SCALANCE's tunnel endpoint — which means the originating host has already resolved the destination via ARP on the local segment, and the SCALANCE's external interface has already performed routing on the outer header. If the SCALANCE and the peer on the local segment both claim the same IP, the host cannot tell which physical MAC corresponds to which logical IP. The collision is therefore observable regardless of whether the tunnel is in use.

This is why the SCALANCE cannot be configured to "block all traffic between internal and external except the VPN tunnel" while simultaneously leaving both networks on the same subnet. The VPN endpoint on the SCALANCE is itself a host on one of those subnets, and its address is therefore part of the local ARP space. The only way to keep the IP space clean is to keep the subnets clean.

9. Field Commissioning Checklist

1. Confirm the article number on the device label is 6GK5612-0BA10-2AA3 and matches the SCT project.
2. Confirm firmware version against the SCT version. Mismatches are a documented cause of download errors.
3. Plan the IP address scheme before the SCT download. Use a subnet calculator to confirm the two interfaces are non-overlapping.
4. Decide in advance whether the device will run in bridge or router mode. Bridge mode is acceptable only if the two segments are already on different subnets.
5. Back up the working project file. SCT project corruption is recoverable from a backup.
6. Export the device certificate and key (if used) to a secure location before any re-flash.
7. Document the management IP, the tunnel endpoints, the IKE proposal, and the Phase 2 selectors in a network diagram.
8. After the change, monitor the event log for 24 hours and confirm zero duplicate-IP or ARP-storm entries.

10. Best Practices for S612 VPN Deployments

• Always renumber the network before deploying a security appliance. Even if the appliance supports bridge mode, the underlying IP scheme must be unique per segment.
• Prefer router mode for any new deployment, even when both segments could technically be bridged. Router mode gives explicit control over what is and is not routable, and is the only mode that supports NAT.
• Use a dedicated tunnel pool (Option C) for road-warrior access, with strict firewall rules on the S612 to prevent tunnel clients from reaching segments they should not.
• Keep the SCT project and device firmware on a supported combination. When using Security Configuration Tool V3.0 (HF1) with pre-existing projects, regenerate the project rather than opening the legacy file directly, per the SCALANCE S612 product note.
• Avoid implicit NAT rules. Explicit 1:1 or N:1 NAT mappings are easier to audit and troubleshoot.

11. Summary

The SCALANCE S612 is behaving correctly when it refuses to operate in router mode with two overlapping subnets, and it is also behaving correctly when, in bridge mode, the duplicate IP is propagated to all hosts and triggers a Windows IP-conflict warning. The device does not have a configuration option that bypasses this fundamental IP-routing rule. The supported fix is to re-address at least one of the two networks so that the subnets on either side of the SCALANCE are unique, and to deploy the device in router mode. A dedicated tunnel subnet is the appropriate pattern for road-warrior or remote-maintenance access. Bridged deployments with duplicate IP ranges should be considered uncommissioned and remediated before the system is handed over to operations.