S7-1200 VPN Access via Scalance M874-3: Firewall Fix

Overview

The S7-1200 CPU 1215C is frequently deployed in remote sites that must be commissioned, monitored, or reprogrammed over a public or cellular backhaul. The SCALANCE M874-3 (Siemens order number 6GK5874-3AA00-2AA2, variants exist for UMTS and LTE) is a compact industrial cellular router with integrated IPsec VPN endpoint, designed for exactly this use case. A common fault symptom is that ICMP ping between the engineering station and the CPU succeeds through the tunnel, yet TIA Portal cannot go online, the program cannot be loaded, and the Web server of the CPU returns no page. The root cause in nearly every case is not the VPN tunnel itself (which is implicitly proven by working ping) but a combination of (a) firewall rules inside the SCALANCE M874-3 and Windows firewall on the engineering station, (b) IP subnet boundary mismatches that block the higher-layer protocols, and (c) the CPU's Web server and S7 communication ports not being explicitly allowed through the Security settings of the cellular router.

This reference walks through the layered troubleshooting path, presents the exact TCP/UDP port matrix that must be permitted, and shows how to verify each protocol path independently. The same logic applies to the S7-1500 family; the official TIA Portal documentation on creating a VPN tunnel between S7-1500 stations describes the conceptual model that this article extends to the S7-1200 with the SCALANCE M874-3.

Reference Architecture

The reference deployment described in the source case has the following topology:

• Remote site (Server side): CPU 1215C → Ethernet → SCALANCE M874-3 (configured as VPN server, IPsec endpoint, public/operator-supplied SIM address). The CPU's PROFINET interface and the M874-3 LAN port are in the same /24 subnet (e.g. 192.168.1.0/24). CPU default IP: 192.168.0.1 or a project-assigned address inside that subnet.
• Engineering site (Client side): Engineering PC → Ethernet → SCALANCE M874-3 (configured as VPN client). The PC and the M874-3 LAN port are in a second subnet (e.g. 192.168.2.0/24).
• Transport: Cellular (UMTS/LTE) bearer, IPsec ESP tunnel in tunnel mode, IKEv1 or IKEv2 with PSK or certificate authentication.

The IPsec tunnel terminates on the WAN (mobile) side of each M874-3, while the engineering traffic is carried inside the encrypted tunnel to the remote LAN. The reference VPN setup model for S7-1500 stations documented in the TIA Portal manual collection uses an analogous CP 1543-1; the M874-3 substitutes the same role with a different configuration UI (Web Based Management, WBM).

Prerequisites

1. Firmware on M874-3: Use the latest released firmware for 6GK5874-3AA00-2AA2 from the Siemens Industry Online Support. Older firmware versions had bugs in IPsec NAT-Traversal that prevented ESP-UDP encapsulation when both peers were behind mobile NAT.
2. CPU 1215C firmware: V4.2 or later is recommended to match TIA Portal V16+ project settings; the Web server functionality is present from firmware V2.0 onward.
3. TIA Portal: V15.1 or later on the engineering station, matching the project version used to program the CPU.
4. Valid SIM and APN: With public APN, the M874-3 receives a dynamic WAN IP. With private APN, the operator provides a static or pseudo-static IP; document the IP plan before commissioning.
5. Web server activation in the CPU: In TIA Portal, project tree → CPU → Properties → Web server, tick Enable Web server on this module, choose HTTP only (port 80), HTTPS only (port 443), or both, and assign user rights to at least the Read role. Compile and download the configuration; the Web server is only active after the new hardware configuration is loaded.

Step 1: Verify the IP Plan and Subnet Boundaries

The first observation in the field report was that the original 255.255.255.0 subnet mask forced two distinct subnets to be routed explicitly. While the M874-3 does support static routes, a far simpler architecture is to keep both LAN segments inside a common 255.255.0.0 (/16) or to define explicit routes in both M874-3 instances.

Once the IP plan is fixed, the M874-3 must contain a static route from the client subnet (192.168.2.0/24) to the tunnel interface, and vice versa. In the M874-3 WBM this is configured under Layer 3 → Static Routes; the gateway for the remote subnet is the tunnel's virtual IP (assigned inside the IPsec configuration as the "Remote virtual IP" or "Inner IP").

Step 2: Build the IPsec Tunnel

Open the WBM of the server-side M874-3 (default address https://192.168.1.1, default user admin). Navigate to Security → VPN → IPsec → Connections and create a new connection profile:

1. Connection type: Remote (client-to-site).
2. Authentication: Pre-Shared Key (PSK) for first commissioning, certificate for production. The PSK must be at least 32 characters of random data per RFC 4303 guidance.
3. IKE version: IKEv2 preferred (RFC 7296); fall back to IKEv1 only if the operator's APN interferes with IKEv2 cookie exchange.
4. Phase 1 (IKE SA): AES-256 / SHA-256 / DH group 14, lifetime 86400 s.
5. Phase 2 (ESP SA): AES-256 / SHA-256, lifetime 28800 s, perfect forward secrecy enabled.
6. Local ID / Remote ID: Use FQDN or User-FQDN ID type, not IP, because both peers are behind mobile NAT.
7. NAT-Traversal: Enabled (forces UDP encapsulation on port 4500).
8. DPD (Dead Peer Detection): Enabled, 30 s interval, 5 retries.

On the client-side M874-3, mirror the configuration: enter the server's public FQDN or IP as the remote gateway, paste the same PSK, and match every algorithm. Once saved, the WBM should report Phase 1 & 2 established within 10 s. Ping from the engineering PC to 192.168.1.10 will then succeed. If it does not, the problem is at the IPsec layer, not at the firewall layer, and you must check the operator's port restrictions: most cellular APNs allow only UDP/500, UDP/4500, and ESP (protocol 50). Some APNs block ESP entirely; in that case IPsec must operate in NAT-T mode exclusively.

Step 3: Configure Firewall Rules on the M874-3

This is the decisive step. By default, the SCALANCE M874-3 ships with a stateful firewall that blocks all inbound traffic from the VPN tunnel toward the LAN except for connections that match an explicit rule. The ping is permitted because ICMP echo is implicitly allowed by the default ICMP pass-through rule (a common SCALANCE default), but TCP services are not. You must add a dedicated firewall rule for each protocol the CPU must expose.

In the WBM, these rules live under Security → Firewall → IPv4 Rules. Apply rules in order of specificity (specific service first, generic deny last). Commit with Save → To device and survive reboot; live changes do not persist across power-cycles without this final commit.

Step 4: CPU Web Server and TIA Portal Reachability Settings

Even with the tunnel up and the M874-3 firewall open, the CPU itself performs a second layer of filtering:

1. In the CPU's properties → Protection & Security → Connection mechanisms, ensure Permit access with PUT/GET is enabled if you intend to use that mechanism; Web server access is independent.
2. In Web server → User management, define at least one user with the Read role (default user admin is preconfigured but with full rights; the password must be set, otherwise the Web server refuses all browser logins).
3. Set the CPU's Time of day synchronisation; the Web server HTTPS certificate validity is checked against the CPU clock and an out-of-range clock will block browser logins even when the page is reachable.
4. Under Web server → Automatic update, enable Enable automatic update of the Web pages only after the first successful page load; otherwise stale HTML can mask the underlying reachability status.

Step 5: Windows Firewall on the Engineering Station

TIA Portal's online services are split across several executables (S7PCT, S7WscanX, dotnet for OPC UA, the Siemens.Automation.Portal host). A default Windows 10/11 firewall profile can block the outbound side of the connection. Open Windows Defender Firewall with Advanced Security and add the following outbound rules:

• Allow %ProgramFiles%\Siemens\Automation\Portal V1x\bin\S7PCT.exe on TCP any.
• Allow %ProgramFiles%\Siemens\Automation\Portal V1x\bin\S7WscanX.exe on UDP/TCP any.
• Allow System on TCP 102 outbound (this is the channel S7Comm uses once the connection is established).

If the engineering station is on a corporate domain, group policy may override these rules; verify with gpresult /h gpresult.html and check the applied firewall policy.

Troubleshooting Matrix

Step-by-Step Verification Procedure

1. Layer 1 - Physical and link: On the engineering PC, ping -t 192.168.2.1 (the local M874-3). Should reply in < 1 ms. Loss ⇒ check Ethernet cable and PC IP.
2. Layer 2 - Tunnel: From PC, ping 192.168.1.1 (the remote M874-3 LAN). Should reply in 30-300 ms over LTE. Loss ⇒ check IPsec status in WBM.
3. Layer 3 - CPU reachability: From PC, ping 192.168.1.10. Should reply. Loss with step 2 ok ⇒ static route missing on the remote M874-3.
4. Layer 4 - S7 port: From PC, Test-NetConnection 192.168.1.10 -Port 102 (PowerShell) or telnet 192.168.1.10 102. TcpTestSucceeded: True ⇒ firewall open.
5. Layer 5 - Web server: From PC browser, navigate to http://192.168.1.10. The Siemens landing page should appear. If browser shows "connection refused" while step 4 succeeds ⇒ Web server is not activated or compiled into the CPU project.
6. Layer 6 - TIA Portal: Online → Accessible devices → show all accessible devices. The CPU should appear with its MAC and IP. Double-click to go online. If TIA reports "target device not reachable" while steps 1-5 all succeed ⇒ TIA Portal version mismatch with CPU firmware; upgrade TIA to match or, less preferably, downgrade the CPU firmware.

Advanced: Avoid Subnet Boundary Pitfalls

The contributor's observation about the subnet mask is technically a routing statement, not a firewall statement. If the engineering PC is on 192.168.2.0/24 and the CPU on 192.168.1.0/24, the PC's default gateway (192.168.2.1, the client M874-3) must know how to reach 192.168.1.0/24. The M874-3 achieves this with a static route entry of the form:

If the engineering PC itself is in the same /24 as the remote CPU (e.g. both 192.168.1.0/24) but the PC's adapter does not have a route to the remote LAN, TIA Portal will fail to discover the CPU. The most robust solution is to give each M874-3 a LAN address in a separate /24, configure static routes in each, and keep the engineering PC in its own /24 with a default gateway pointing to the local M874-3.

Advanced: Securing the Tunnel in Production

After the engineering channel is proven, harden the deployment:

• Replace the PSK with X.509 certificates issued by an internal CA; distribute via SCEP or by manual import.
• Restrict the M874-3 firewall source to the engineering station's static tunnel address, not to a subnet.
• Disable HTTP (port 80) on the CPU Web server; keep HTTPS only and install a CA-signed certificate into the CPU.
• Enable the CPU's Access protection (CPU properties → Protection → Know-how protection and copy protection) to prevent program extraction even if the tunnel is compromised.
• Enable logging on both M874-3 instances and forward to a central syslog server for audit trail.

Diagnostic Reference: Key Ports and Protocols