Configuring S7-1200 CPU 1212 WebServer Remote Internet Access

1. Problem Overview and Engineering Objective

A typical remote-telemetry scenario places a Siemens SIMATIC S7-1200 CPU 1212 at an unattended station and a central engineering / operations PC in a different geographic location. The customer requirement is straightforward: render the PLC's integrated WebServer pages in a standard browser at the central station, exactly as if the browser were connected to the PLC's local Ethernet port.

The native S7-1200 WebServer serves diagnostics, tag values, watch tables, and (optionally) user-defined web pages authored in TIA Portal. It is bound to the PLC's IP address on TCP ports 80 (HTTP) and 443 (HTTPS), which the central station browser must be able to reach across the public Internet. Engineering access to TIA Portal itself uses ISO-on-TCP (S7 communication) on TCP port 102, which is a separate concern from the WebServer traffic.

This article consolidates the field-proven procedure for delivering that capability securely, starting with the recommended VPN topology and then covering port forwarding as a fallback when the customer cannot or will not deploy a VPN.

2. Network Architecture

The canonical topology is two IP subnets joined by the Internet:

• Remote station LAN: S7-1200 CPU 1212 (default IP 192.168.0.1 / 255.255.255.0) on a small Ethernet segment with a SOHO or industrial router (WAN uplink = public IP, e.g. dynamic DSL).
• Internet transit: IPv4 with possible carrier-grade NAT (CGNAT). If the ISP issues only a private WAN address, the techniques in this article will not work without an outbound-initiated tunnel — see Section 7.
• Central station LAN: PC with TIA Portal (V15 or later recommended) and a browser, on a separate private subnet.

For the WebServer traffic, the central PC needs only an HTTP/HTTPS path to the PLC's IP. The PLC's IP itself is not routable on the Internet — it must be reached through the remote router using either a tunneled overlay (VPN) or a NAT/port-forwarding rule on the router.

3. Security Model: VPN First, Port Forwarding Last

Siemens' published guidance, summarized in Siemens Support Entry 26662448, explicitly recommends an encrypted tunnel rather than direct exposure of the S7-1200 services. The reasoning is technical, not procedural:

• TCP/102 (S7COMM) has no authentication; an exposed CPU accepts any S7 read/write.
• CPU 1212 firmware V4.x added user-management for the WebServer, but firmware V3 and earlier accept any browser reaching port 80/443.
• Plain HTTP traffic leaks tag values and credentials in clear text on every hop.

Decision matrix for the two main options:

4. Prerequisites

Before configuring any tunnel or port rule, confirm the following on the remote station:

1. CPU 1212 with firmware V4.2 or later (user-management and HTTPS support are stable from this baseline). Older firmware can still serve HTTP but should be scheduled for upgrade.
2. TIA Portal project matching the installed firmware; the same project is used at the central station for online diagnostics.
3. A fixed or DDNS-resolvable public hostname for the remote station's WAN interface.
4. Router with VPN capability (IPsec / WireGuard) for the recommended path, or at minimum NAT/port-forwarding capability for the fallback path.
5. Central station with a static or near-static public IP (or its own VPN client).
6. Browser at the central station that supports modern TLS (Edge, Chrome, Firefox current versions).

5. Enabling the S7-1200 WebServer in TIA Portal

Open the CPU 1212 device configuration in the TIA Portal project and navigate to Properties > Web Server > General. The activation sequence is:

1. Check "Activate web server on this module".
2. Check "Permit access only with HTTPS" for any production deployment. This forces the CPU to listen on 443 only and reject cleartext on 80.
3. Under User management (firmware V4.0+), create at least one user with a strong password and assign the role Viewer for read-only WebServer access or Administrator if change-rights are required.
4. Compile the hardware configuration and download it to the CPU. The CPU will reboot once.
5. After the reboot, verify locally: from any PC on the remote LAN, open https://192.168.0.1 and accept the self-signed certificate. The standard S7-1200 diagnostics page must appear.

WebServer user administration is stored on the CPU; the same credentials are used by every remote browser once the network path is established. Credentials are hashed inside the CPU and never leave it, even on the wire.

6. User Management and Access Protection on the CPU

Firmware V4.0 and later replace the single global password with a real user table under Properties > Web Server > User management. Practical rules:

Passwords must be at least 8 characters and must be rotated on any personnel change. Account lockout is not configurable on the S7-1200 — restrict access at the network layer (VPN ACL or source-IP whitelist at the router).

7. Option A — Site-to-Site VPN Deployment (Recommended)

A site-to-site VPN places the central station and the remote station on the same logical subnet from the application's point of view. The S7-1200 WebServer is then reached at its native IP and port — no NAT, no port translation, no exposure to the public Internet.

7.1 IPsec (most common on industrial routers)

Configure the remote router as the IPsec responder and the central router (or central PC running a software IPsec client such as strongSwan) as the initiator. Minimum parameters:

• IKEv2 with PSK or RSA-Sig
• AES-256 encryption, SHA-256 integrity
• DH group 14 (2048-bit) or higher
• PFS enabled with group 14
• Tunnel inside IP range: e.g. 10.10.10.0/30
• Remote LAN proxy-id: 192.168.0.0/24 (CPU 1212 LAN)
• Central LAN proxy-id: 192.168.10.0/24

Once the tunnel is up, the central PC opens https://192.168.0.1 as if it were on the remote LAN. The certificate warning can be eliminated by installing the CPU's self-signed certificate (exported from TIA Portal under Web Server > Certificate) into the central PC's Trusted Root Certification Authorities store.

7.2 WireGuard (lightweight, modern)

WireGuard is an excellent choice when both endpoints are under your administrative control. Generate a keypair on the remote router, share the public key with the central peer, and define:

[Interface]
Address = 10.0.0.2/24
PrivateKey = <remote-private>

[Peer]
PublicKey = <central-public>
AllowedIPs = 192.168.10.0/24
Endpoint = central.example.com:51820
PersistentKeepalive = 25

Add a static route on the remote router so that traffic destined for 192.168.0.0/24 (the CPU's LAN) is reachable through the WireGuard interface. The CPU itself needs no WireGuard configuration; it simply answers on its native IP from the tunneled perspective.

7.3 CGNAT Workaround

If the remote ISP assigns a CGNAT address (no inbound reachability at all), the remote router must be the tunnel initiator connecting outbound to a VPS that has a public IP. The VPS then serves as the static endpoint for the central station. This is the only architecture that works under CGNAT.

8. Option B — Port Forwarding on a Consumer / SOHO Router

Where the customer refuses VPN, TCP ports can be forwarded from the router's WAN interface to the CPU. This is the only configuration in which the WebServer is directly reachable from the public Internet.

Required mappings:

9. Router Configuration Walk-Through (ASUS DSL-N10E)

The ASUS DSL-N10E used at the remote station is a representative SOHO DSL gateway. The exact menu labels differ from firmware revision to firmware revision, but the steps generalize to any router with NAT:

1. Log into the router's web interface (typically http://192.168.1.1).
2. Reserve a DHCP lease for the CPU's MAC address so that 192.168.0.1 never shifts.
3. Disable remote management of the router itself on port 80/443 — the management interface must not be exposed to the Internet.
4. Open the Virtual Server / NAT page and add rules as per the table above (external 8443 → internal 192.168.0.1:443, optional external 8080 → 192.168.0.1:80).
5. If the WAN address is dynamic, configure DDNS on the router (ASUS provides one natively) and use the resulting hostname in the central station browser.
6. Enable the router's SPI firewall and log dropped packets to syslog.
7. Apply, then verify from a phone on cellular data (which is on a different network than the LAN) that https://<DDNS-hostname>:8443 returns the S7-1200 login page.

10. Central Station Browser Configuration

At the central station, the browser address bar becomes the only application-level configuration required:

• VPN path: https://192.168.0.1 (or the CPU's actual LAN IP).
• Port-forwarded path: https://<DDNS>:8443

The browser will warn about the self-signed certificate. The warning cannot be permanently suppressed by browser policy without deploying the CPU certificate as a trusted root — do that on the central PC if the deployment is long-term. After login with the configured WebServer user, the standard S7-1200 WebServer pages are served exactly as on the local LAN.

11. Verification and Functional Test

After deployment, run the following sequence before sign-off:

1. Tunnel-up test (VPN): from the central PC, ping 192.168.0.1 through the tunnel. A reply confirms IP-layer reachability.
2. TCP probe: Test-NetConnection 192.168.0.1 -Port 443 (PowerShell) or nc -vz 192.168.0.1 443 must return TcpTestSucceeded : True.
3. TLS handshake: openssl s_client -connect 192.168.0.1:443 -servername s7-1200 must return a certificate chain anchored to the CPU's self-signed CA.
4. Login: the WebServer login page must render; an invalid credential must be rejected; a valid credential must reach the standard S7-1200 start page.
5. Tag visibility: navigate to a user-defined page or to Watch tables and confirm a known tag is showing its current value from the CPU.
6. Load: open 5 simultaneous browser sessions and refresh every 5 seconds for 15 minutes. The S7-1200 WebServer can sustain a small number of concurrent users; saturation is the most common field failure.
7. Failover: drop the tunnel (or the port-forward) and verify that the browser times out cleanly rather than hanging the workstation.

12. Troubleshooting Matrix

13. Field-Proven Caveats and Long-Term Operations

• Firmware upgrades require local access. Major firmware updates reset the WebServer certificate and user table; budget a one-time site visit.
• CPU load. The S7-1200 WebServer runs on the CPU itself; a high-frequency tag update interval competes with the OB1 cycle. Keep the update interval at 1 s or longer for any tag count above 50.
• Browser compatibility. Microsoft Edge and current Chrome/Firefox render S7-1200 standard pages correctly. Internet Explorer 11 (legacy) works only on firmware < V4.4 and is no longer supported by Microsoft.
• Audit. Enable the CPU's security event logging via TIA Portal > Web Server > Security events; forward the syslog to the central SIEM if one is available.
• Reference architecture. Siemens publishes the canonical S7-1200 WebServer description in the S7-1200 Programmable Controller system manual, available through the Siemens Industry Online Support portal; cross-check any feature against that document before commissioning.