Resolving S7-1200 OPC UA Server WAN Connection Failures

Problem Overview

Connecting an OPC UA client (Kepware, UA Expert, TIA Portal, custom SCADA) to the embedded OPC UA server of a SIMATIC S7-1200 CPU across a WAN link is a frequent requirement for remote service, telemetry, and inter-site SCADA. LAN operation typically succeeds without manual intervention. Once the OPC UA client and the CPU are placed on different IP networks, however, the session fails during the TCP transport, ServiceHello, or OpenSecureChannel step even though local authentication works fine.

The most common cause is a missing Use IP router setting on the S7-1200 CPU. With this option disabled, the CPU treats the configured gateway as unreachable, will not forward any TCP traffic (including OPC UA on port 4840) outside its own subnet, and drops every inbound packet that arrives through the boundary router. A secondary layer of failures usually appears at the WAN router: NAT port-forwarding, SIP/ALG filtering, default-deny firewall rules, or missing outbound return routes. This article covers both layers and the security settings inside TIA Portal required for a stable remote OPC UA link.

OPC UA Server Capability on the S7-1200

The S7-1200 OPC UA server is a licensed, firmware-gated feature. Confirm the prerequisites before chasing a network problem:

The official Siemens documentation step for enabling the server is:

1. Select the S7-1200 CPU in the network view or device tree.
2. Open Properties > OPC UA > Server.
3. Activate Activate OPC UA server.
4. Select the runtime license (trial or purchased).
5. Configure security policy, authentication, and the exposed tag namespace.
6. Compile and download the project to the CPU.

Refer to the Siemens TIA Portal online help: Enabling the OPC UA Server (S7-1200).

Root Cause Analysis

The TCP/IP stack on the S7-1200 follows standard host behavior: a packet destined to an off-subnet address is forwarded to the configured default gateway. The CPU does not implement proxy ARP or automatic gateway discovery. If the Use IP router checkbox is not set in TIA Portal (and consequently the gateway IP is empty in the PROFINET interface), the following sequence occurs:

1. CPU receives a SYN on TCP 4840 from the boundary router (which has performed NAT/port-forwarding).
2. CPU inspects the destination IP (its own public-facing address, mapped to its private IP).
3. Stack determines the destination is reachable directly on the local subnet.
4. TCP handshake completes (in some firmware versions), but the response cannot be routed back through the gateway because no default route exists.
5. The OPC UA client never sees the ServiceHello ACK; the session times out.

When Use IP router is enabled and the gateway IP is correct, the CPU creates a default route, the SYN-ACK travels back through the boundary router, and the OPC UA handshake proceeds normally.

Network Architecture and Addressing

Use the following reference topology when commissioning a remote OPC UA link. The boundary router does double duty: it terminates the ISP-issued public IP and performs 1:1 NAT (or PAT) toward the S7-1200.

IP Plan Template

TIA Portal Configuration: Enabling the IP Router

This is the change that resolved the field case. The setting is hidden under the PROFINET interface properties of the CPU.

1. Open the S7-1200 project in TIA Portal (V17 or later).
2. Select the CPU in the device tree.
3. Open Properties > PROFINET interface [X1] > Ethernet addresses.
4. Expand IP protocol.
5. Tick the checkbox Use IP router.
6. Enter the Router address field with the LAN IP of the boundary router (in the example, 192.168.1.1).
7. Compile the hardware configuration and download to the CPU.
8. Power-cycle the CPU if the interface does not pick up the new route immediately on older firmware.

After download, verify on the CPU's web server (http://192.168.1.10) under Diagnostics > Routing table that a default route via 192.168.1.1 is present.

Boundary Router Configuration: Port Forwarding and NAT

The OPC UA server listens on TCP 4840. The boundary router must satisfy three conditions:

1. Allow inbound TCP 4840 from the public side (or from the client IP).
2. DNAT / port forward TCP 4840 to 192.168.1.10:4840.
3. Permit the return path; many consumer routers use connection tracking that handles this automatically once the DNAT rule exists.

Most ISP-grade routers expose a Virtual Server, Port Forwarding, or NAT/PAT page. The minimum rule set:

Service: OPC UA
External port: 4840
Internal host: 192.168.1.10
Internal port: 4840
Protocol: TCP
Source IP: <remote-client-CIDR> (optional, recommended)
Status: Enabled

If the OPC UA client is behind another NAT (e.g., a corporate proxy or 4G carrier-grade NAT), confirm outbound reachability with a quick test:

1. From the remote PC, run telnet 203.0.113.20 4840 or Test-NetConnection 203.0.113.20 -Port 4840 (PowerShell).
2. A successful banner / open socket proves the port forward works.
3. A timeout indicates either a missing forward, a stateful firewall, or an ISP blocking port 4840 (some carriers block low ports or unusual services).

OPC UA Endpoint and Security Settings

The WAN link does not change the OPC UA security model. Configure the server with at least Basic256Sha256 + SignAndEncrypt when exposing it across an untrusted network. The following table maps each setting to its WAN impact:

After TIA Portal compile/download, export the server certificate from the CPU web server (OPC UA > Certificates) or directly from TIA Portal, and import it into UA Expert under Settings > Certificate Manager > Trusted Clients / Trusted Servers. Kepware uses the Windows certificate store; install to Trusted People.

Firewall and Windows Configuration

Disable the Windows Defender firewall only as a last resort. A scoped inbound rule is more secure and equally effective:

New-NetFirewallRule -DisplayName "OPC UA Outbound 4840" \
  -Direction Outbound -RemotePort 4840 -RemoteAddress 203.0.113.20 \
  -Protocol TCP -Action Allow -Profile Any

The matching inbound rule is rarely needed because UA Expert/Kepware initiate as the client. If a SCADA is acting as both client and server (aggregation), add a corresponding inbound rule on the SCADA host.

On the boundary router, log dropped packets to confirm whether the firewall, NAT, or ALG is the offender. A 30-second trace is enough to see whether the SYN reaches the LAN side and whether the SYN-ACK leaves the CPU.

Verification Procedure

Run this checklist top-to-bottom. Each step has an expected outcome; if the outcome is not observed, the failure point is isolated.

1. Local ping. From a LAN PC, ping 192.168.1.10. Expected: reply < 5 ms.
2. CPU web server. Browse to http://192.168.1.10. Expected: S7-1200 web page loads.
3. OPC UA LAN connect. In UA Expert, connect to opc.tcp://192.168.1.10:4840. Expected: connected, tags browseable.
4. Routing table. On the CPU web server, Diagnostics > Routing. Expected: default route via 192.168.1.1.
5. Remote port test. From the remote client PC, Test-NetConnection 203.0.113.20 -Port 4840. Expected: TcpTestSucceeded: True.
6. OPC UA WAN connect. In UA Expert on the remote PC, connect to opc.tcp://203.0.113.20:4840. Expected: connected, same tag tree as LAN.
7. Sustained read. Add a tag to UA Expert's data view and confirm continuous updates for > 5 minutes. Expected: no disconnects; value updates > 0.5 Hz.
8. Security audit. With Wireshark on the remote side, capture the TCP 4840 session and confirm ApplicationUri, EndpointUrl, and certificate subject match the TIA Portal export.

Troubleshooting Matrix

Security Hardening Notes

Direct WAN exposure of an industrial protocol is acceptable when compensating controls are in place. The recommended baseline for an S7-1200 OPC UA server exposed on the public Internet:

• Use Basic256Sha256 / SignAndEncrypt only; remove None from the endpoint.
• Disable anonymous authentication; require username/password.
• Restrict the inbound rule to the specific remote client IP or ASN.
• Replace the default self-signed certificate with one signed by an internal CA; rotate annually.
• Enable intrusion detection on the boundary router and alert on TCP 4840 scans.
• Keep the CPU firmware current; OPC UA security fixes ship with firmware updates.

For long-term deployments, a VPN (IPsec or WireGuard) with split tunneling that carries only OPC UA is the most defensible architecture. The direct-WAN pattern documented here is appropriate for service windows, ad-hoc commissioning, or sites without managed VPN infrastructure.

Field Proven Caveats

• Some ISP CPE routers drop long-lived TCP sessions after 5 minutes of idle. Either reduce the OPC UA publishing interval or shorten the router's NAT entry lifetime.
• Carrier-grade NAT (CGNAT) prevents inbound connections from the public Internet. The remote client must be on a routable public IP, or you must deploy on a VPS / VPN concentrator.
• The S7-1200 CPU accepts only one default route. If the LAN has multiple VLANs, the gateway must be the inter-VLAN router address, not the workstation gateway.
• Firmware 4.4 has a known quirk where the IP router change requires a power-cycle to take effect. Firmware 4.5 and later accept the change online.
• If the OPC UA endpoint URL contains the CPU's private IP, regenerate it via TIA Portal's "OPC UA > Server > Endpoint configuration" before going live, otherwise clients will reject the URL mismatch with the certificate.

FAQ