S7-1200 TCP Port 102: S7 Communication Behind NAT Router

Overview: The Port 102 Constraint in S7-1200 Remote Access

The Siemens SIMATIC S7-1200 CPU listens for engineering and S7 communication on TCP port 102. This port is hardcoded in the CPU firmware; it cannot be remapped through TIA Portal, STEP 7 Basic, or any online function. The same restriction applies to S7-1500, S7-1500T, ET 200SP CPU, and most S7-300/400 CPUs in their default configuration. When the S7-1200 sits behind a NAT router and the network administrator will not open port 102 on the public IP, the only paths forward are: (a) negotiate a single one-to-one NAT pinhole for port 102, (b) deploy a VPN tunnel through a SCALANCE S or equivalent security appliance, or (c) use an alternative protocol (Open User Communication or OPC UA) that lets the CPU listen on a non-standard TCP port. Each path carries a different security profile, address-management cost, and scalability characteristic that the integrator must evaluate before commissioning.

This reference consolidates the S7-1200 port architecture, the behavior of STEP 7 / TIA Portal when traversing a NAT router, the official Siemens recommendation for engineering across address translation, and the security characteristics of pinhole forwarding versus an IPsec-based VPN tunnel.

Why Port 102 Cannot Be Changed on the S7-1200

Port 102 is reserved by the ISO Transport Service Access Point (TSAP) mechanism that underpins S7 communication. The CPU implements the S7 protocol over ISO-on-TCP (RFC 1006) and standard TCP. In both cases the connection is initiated by the engineering station or HMI as a client, and the S7-1200 accepts the connection on a well-known server port. According to the official TIA Portal help documentation, "Port numbers must be unique. The connection configuration or a corresponding block call is rejected with an error if the port numbers are assigned twice." — this uniqueness rule applies to the local (active) partner; the S7-1200's passive listening port is fixed at 102 and is not exposed in the project tree.

Practical consequences:

• Every S7-1200 in the world answers S7 communication on TCP 102. There is no per-instance port offset like some other vendors offer.
• The engineering tool (STEP 7 Basic / TIA Portal) opens a high, ephemeral source port (typically 49152–65535) toward the CPU's destination port 102. The source port rotates with each session and cannot be pinned through the UI.
• Behind a one-to-one NAT, the public IP plus the public TCP/102 pinhole maps 1:1 to a single internal CPU. To reach a second CPU behind the same router, a second public IP is required (or a different mechanism such as an S7 routing gateway).

See the official TIA Portal reference page for the full set of restrictions on port assignment: Assignment of port numbers (S7-1200, S7-1500, S7-1500T) - STEP 7.

S7 Communication Protocol Stack and Port Allocation

The S7-1200 CPU implements the following passive (server) listening sockets at startup, on the integrated PROFINET interface:

Because S7 communication, PROFINET, and the web server are bound to fixed ports, a remote-access design that wants to avoid touching port 102 must either substitute a different protocol on a non-default port (Open User Communication or OPC UA) or terminate the connection at a security appliance that performs the translation.

NAT Router Port Forwarding Architecture for S7-1200

Network Address Translation (NAT) maps the plant's public IPv4 address to one or more private addresses. For an inbound engineering session to reach the S7-1200's port 102, the router must hold a static port forwarding rule of the form:

Public IP: <router public IP>        (e.g., 198.51.100.10)
Protocol:  TCP
External port: 102
Internal IP:  <S7-1200 IP>             (e.g., 192.168.10.20)
Internal port: 102

The rule is consumed 1:1: one public address, one external port 102, one private CPU. Two S7-1200s behind the same router cannot both be reached through TCP 102 of the same public IP without using a different public IP for each. Attempting to forward the same external port to two internal hosts produces a routing ambiguity that the firewall will reject.

Address visibility in the TIA project: the project stores the CPU's IP address as the target of every online operation. When the engineering station sits on the public side of the NAT, the IP address that resolves the CPU must be the router's public IP, not the CPU's private address. The CPU's private 192.168.x.x address is invisible across the internet and is not routable from the remote side. The official Siemens Knowledge Base article 109754922 - "How can you use the STEP 7 Online functions even when NAT (Network Address Translation) is being used or a remote subnetwork is to be reached?" documents the exact procedure for entering the public address as the accessible node in TIA Portal so that online functions such as download, online diagnosis, and trace resolve correctly through the pinhole.

Single-PLC Pinhole: Limitations

• Only one S7-1200 can be reached per public IP for engineering and S7 communication.
• The S7-1200's MAC address is not reachable for PROFINET device discovery (DCP) across the NAT — DCP is link-local and is not a routable protocol.
• No confidentiality: S7 payload is not encrypted, so anyone capturing the stream between the public IP and the engineering station can read the data with Wireshark dissectors (S7comm).
• No authentication of the engineering station by the CPU — any client that can route to the public IP and complete the TCP handshake is allowed to open an S7 connection provided the protection level permits it.

Security Implications of Direct Port Forwarding

A TCP 102 pinhole exposes the S7-1200 to the public internet in a manner functionally equivalent to the OT-recommended conduit model only when the network between the public side and the CPU is treated as untrusted. The following risks must be addressed before commissioning:

VPN-Based Remote Access with SCALANCE S

The Siemens-recommended long-term solution is to place a SCALANCE S612/S623/S627-2M security module on the trusted (plant) side of the NAT router. The SCALANCE S acts as an IPsec VPN gateway, terminates the tunnel, and re-presents the S7-1200's private IP to the engineering station. Once the tunnel is established:

• The remote TIA Portal continues to use the S7-1200's private IP (e.g., 192.168.10.20) — no public IP needs to be configured in the project.
• Authentication uses X.509 certificates loaded on both endpoints. Mutual authentication is mandatory.
• The tunnel payload is encrypted (typically AES-128/256 with SHA-2 integrity).
• Multiple S7-1200s behind the SCALANCE S are reachable through the same tunnel; the router does not need any per-PLC pinhole.
• The SOFTNET Security Client (Windows software counterpart) provides the dial-in endpoint on the engineering station.

Tunnel setup procedure (high level):

1. Install the Security Configuration Tool (SCT) on the engineering PC.
2. Generate or import the S7-1200's and SCALANCE S's X.509 certificates, signed by a common CA.
3. Configure the SCALANCE S internal interface (trusted side) with the S7-1200 subnet; configure the external interface with the router-facing address.
4. Define the tunnel group: local = SCALANCE S external IP, remote = engineering station's dynamic or fixed IP, IKEv2 with PSK or certs, ESP with AES-256/SHA-256.
5. On the engineering PC, install SOFTNET Security Client, import the engineering station's certificate, and define the matching tunnel to the SCALANCE S.
6. In TIA Portal, open the project and use the S7-1200's private IP (e.g., 192.168.10.20) for all online functions. Verify with "Go online" — the CPU's MAC should be reachable as if both devices were on the same Layer 2 segment.

Configuring TIA Portal to Reach a CPU Across NAT

When the engineering station must traverse a NAT pinhole (no VPN), the public address of the router must be entered as the S7-1200's online target. Per Siemens Knowledge Base 109754922:

1. In the project tree, right-click the S7-1200 CPU and choose Properties > PROFINET interface [X1] > Ethernet addresses.
2. Enter the public IP of the router (e.g., 198.51.100.10) in the IP address field. Keep the subnet mask as /32 (255.255.255.255) so that TIA Portal does not attempt to discover neighbors on the public network.
3. Confirm that the router's port forwarding rule points external TCP 102 to the CPU's private IP, internal TCP 102.
4. Compile and download the project from a machine on the plant network first; subsequent online changes from the remote side route through the pinhole.

Alternative: Open User Communication on a Custom Port

If the plant firewall will allow a non-standard TCP port (e.g., 2001, 25000), the S7-1200 can be configured with Open User Communication blocks that act as a passive listener on any port the integrator chooses. The TIA Portal instructions are TRCV_C (TCP receive), TSEND_C (TCP send), and TCON (connection establishment). For UDP, the corresponding instructions are TRCV and TSEND. For ISO-on-TCP, use TRCV/TSEND with connection type 12 (ISO-on-TCP) and a TSAP string.

Step-by-step setup:

1. Add a global DB to hold the connection description (e.g., DB100 "TcpRemote") of type TCON_IP_V4 (or TCON_Param for ISO-on-TCP).
2. Configure the connection:

   InterfaceId   := 64   // local PROFINET interface
   RemoteAddress := '198.51.100.10'   // or a symbolic name
   RemotePort    := 2001   // the port the firewall allows
   LocalPort     := 2001   // CPU also listens on 2001

3. Insert a TCON instruction in OB1 with REQ triggered on first scan or on a rising edge after a loss of connection. CONNECT is the connection DB.
4. Insert TRCV_C in the same cycle, with EN_R = TRUE. The receive instruction now opens TCP 2001 on the CPU as a passive listener.
5. Configure the router to forward external TCP 2001 to the CPU's private IP, port 2001.
6. From the engineering station, use a generic TCP client (e.g., a small script, a third-party SCADA, or tcping + a telnet-style test) to connect to the public IP on TCP 2001.

This path bypasses port 102 entirely, but it requires the integrator to define and implement a custom application protocol on both sides. It is well suited to data exchange with a third-party SCADA, to a custom HMI, or to telemetry push to a cloud gateway, but it is not a substitute for TIA Portal's online functions — those still need port 102 open.

Alternative: OPC UA Server for Cross-Network Data Access

S7-1200 CPUs with firmware 4.4 or higher (and S7-1500) expose an integrated OPC UA server. The default server port is 4840, and the port can be changed in the OPC UA server configuration. The firewall only needs to allow the chosen port:

1. Enable the OPC UA server in the CPU properties > OPC UA > Server.
2. Define a server endpoint with a non-default port (e.g., 4840 → 4900) and a security policy (None, Basic128Rsa15, Basic256, Basic256Sha256).
3. Authorize an OPC UA client certificate and an authentication token.
4. Open the corresponding port on the firewall; forward to the CPU's private IP.

OPC UA over the chosen port provides encryption and authentication, but it does not replace the engineering path. Downloading a new program still requires the S7-1200's port 102 or a VPN tunnel.

Router and Firewall Configuration Reference

Typical industrial NAT routers (SCALANCE M, M800, MOXA EDR, Cisco IR1101, Hirschmann EAG) require the following rules for an S7-1200 remote-access deployment:

Verification and Diagnostics

After commissioning the remote access, verify the path with the following checks:

1. From the remote engineering PC, run tcping <public IP> 102 (or Test-NetConnection <public IP> -Port 102 in PowerShell). A successful response confirms the pinhole is open.
2. From TIA Portal, select Online > Accessible nodes. Set the timeout to 30 s. The S7-1200 should appear with its PROFINET name and the public IP.
3. Establish an online connection: right-click the CPU → Go online. The diagnostic buffer should show a successful PG connection entry with the engineering PC's public IP as the source.
4. Read the CPU's diagnostic buffer via the web server (port 80/443 from inside the plant) and confirm the same session entry.
5. For VPN, disconnect the tunnel and attempt the same test — it must fail. This proves the path is not relying on the pinhole when the tunnel is up.
6. For Open User Communication, open a TCP listener on the remote PC on the chosen port (e.g., nc -l 2001) and trigger a TSEND from the S7-1200; the data should appear on the listener.

Troubleshooting Matrix

Field-Commissioning Checklist

• Confirm the CPU firmware version and verify which optional protocols are available (OPC UA requires FW 4.4 on S7-1200).
• Document the public IP, the public port, the internal IP, and the internal port in the network register before commissioning.
• Set the CPU's access level to Complete protection with a strong password before exposing the pinhole.
• Disable unused services on the CPU (web server, SNMP, PUT/GET for unknown partners) to reduce attack surface.
• Configure the router with explicit source-IP allowlisting; avoid <ANY> rules.
• Capture a baseline Wireshark trace from inside the plant to confirm only port 102 and the chosen Open User Communication port are in use.
• After commissioning, perform an external scan (e.g., nmap -sV -p 1-65535 <public IP>) from a non-engineering machine to confirm only the intended ports are visible.
• Plan for a VPN migration path even if the pinhole is the initial deployment — pinhole is a stopgap, not a long-term solution.

Frequently Asked Questions