TIA Portal S7-1200 Remote Access: Fix Port 80 CCTV Conflict

Problem Statement

Field engineers regularly deploy SIMATIC S7-1200 CPUs (for example, CPU 1214C DC/DC/DC or DC/DC/RLY) at remote sites and reach them over a public IP from the engineering office using TIA Portal (V15 through V18+). In one common failure mode, a site already exposes an HTTP service on TCP/80 for a CCTV/DVR/NVR system, so the firewall administrator must assign a different external port and forward it to port 80 on the PLC. The engineer then finds that http://<public-ip>:82 opens the PLC's web server correctly, yet "Go Online" in TIA Portal fails, and there is no field in the TIA Portal "Go Online" dialog to change the port number.

This is not a TIA Portal bug. The misconception is that TIA Portal and the Web Server share the same transport. They do not. TIA Portal uses the S7 communication protocol stack (ISO-on-TCP / RFC 1006) on TCP/102, while the Web Server uses HTTP on TCP/80. Forwarding external port 82 → internal port 80 exposes the wrong service. The fix is to publish TCP/102 on a free external port and forward it to the PLC's internal IP on TCP/102.

Port Architecture of the S7-1200 Communication Stack

An S7-1200 firmware V4.x CPU exposes several TCP listeners. The relevant subset for engineering access is summarised below.

The S7-1200 system manual, entry ID 109751706, lists these ports in the section "Communication services and port numbers". Refer to that table as the authoritative reference for the firmware version installed on the CPU; Siemens occasionally retires or reassigns services between firmware lines (for example, V4.0 to V4.6).

Root Cause Analysis

The reported symptom has three contributing causes, all of which must be addressed:

1. Wrong service published. External port 82 is NAT-forwarded to internal TCP/80, which terminates on the Web Server. TIA Portal sends its initial S7 connection request to TCP/102. Because the firewall has no rule for 102, the SYN times out and "Go Online" reports "Cannot reach the target module" or "Online: Connection to the target system could not be established."
2. No way to set the TIA Portal port in the UI. The "Go Online" dialog exposes the target IP address and the slot of the CPU (for PROFIBUS: rack/slot; for PROFINET: IP + access password), but not a TCP port. TIA Portal always attempts 102. The only way to change the effective port is on the network path (firewall, router, VPN).
3. Possibly no public IP at all. As one responder pointed out, the PLC most likely sits behind a carrier-grade NAT (CGNAT) or a site firewall and shares one public IPv4 address with the CCTV NVR. The public address is therefore on the firewall, not on the PLC. The PLC's internal address (for example, 192.168.1.50) is the only stable destination.

Solution: Publish TCP 102 Through the Firewall

Ask the site firewall / router administrator to create two port-forwarding (DNAT) rules plus matching firewall filter rules.

Step-by-Step NAT Configuration (Generic Router)

1. Identify the PLC's internal IP (192.168.1.50 in this example). Confirm it is static, reserved by DHCP, or set on the device with the same IP shown in the project's device configuration.
2. In the firewall, create a Virtual Server / Port Forwarding entry:
   • Service name: S7-Remote-Eng
   • External interface: WAN (the one with the public IP)
   • External port: 50002
   • Internal IP: 192.168.1.50
   • Internal port: 102
   • Protocol: TCP
3. Create a matching firewall filter (inbound) that allows TCP/50002 from the engineering office's static public IP only. Reject everything else.
4. (Optional) Repeat for the Web Server on a different external port if remote diagnostic viewing is required. For HTTPS, prefer TCP/443 internally; expose 8443 externally. Browsers will not auto-negotiate 8443, so the engineer must type https://<public-ip>:8443.
5. Save and reboot the router only if the firmware requires it.

TIA Portal: Configuring the PG/PC Interface for Routing

TIA Portal uses the PG/PC interface assigned in the project tree to determine which network adapter handles the S7 connection. When the engineering PC is at home, this is typically the home router's WAN-side interface or a VPN tunnel interface.

1. Open TIA Portal and the project for the remote site.
2. Project tree → right-click the CPU (for example, PLC_1 [CPU 1214C DC/DC/DC]) → "Go Online" (or Project tree → Online → Accessible nodes).
3. If prompted, select the PG/PC interface: choose the network adapter that has the route to the public IP of the site. For a direct public-IP connection, this is the home NIC; for a site-to-site VPN, it is the VPN virtual adapter.
4. Confirm or set the target IP address to the site's public IP, for example 203.0.113.45.\li>
5. Set the slot to 1 (the S7-1200 CPU slot in a single-station PROFINET system).
6. If an access password has been configured on the CPU (Device configuration → Properties → Protection & Security → Connection mechanisms), enter it. Without the correct password, TIA Portal will negotiate the S7 connection but fail the user authentication step.
7. Click "Go Online". TIA Portal opens a TCP connection to 203.0.113.45:50002, the firewall NATs it to 192.168.1.50:102, and the CPU accepts the S7 handshake.

Firewall Rules and Security Hardening

Publishing any industrial protocol to the public internet is high risk. Harden the path as follows:

• IP allow-list. Restrict the inbound rule to the engineering office's static public IP. Block all other sources.
• Replace HTTP web server with HTTPS. On the CPU, go to Device configuration → Web server → Security and enable "Use HTTPS only" and "Allow access via HTTPS". Port 443 internally is then mandatory; do not expose port 80.
• Enable the CPU access password. Without it, anyone reaching the S7 service can read the project, change the operating mode, and write tags. Set Protection & Security → Access level to "Complete protection" for HMI write access, and require a password for "Read/write" of the PLC.
• Disable the Web Server if it is not used. This removes port 80 from the device entirely and eliminates a common reconnaissance target.
• Disable PUT/GET communication (Device configuration → Protection & Security → Connection mechanisms → "Permit access with PUT/GET communication") if it is not used by an HMI or third-party Modbus gateway.
• Use a VPN instead of port forwarding. A site-to-site IPsec VPN (for example, between two SCALANCE M routers) or a client VPN (WireGuard, OpenVPN) places the PLC on a private address and eliminates public exposure of TCP/102. This is the recommended architecture for any production system.

Verification Procedure

1. Test the NAT from the engineering office using PowerShell or telnet:

   Test-NetConnection -ComputerName 203.0.113.45 -Port 50002
   
   # or
   Test-NetConnection -ComputerName 203.0.113.45 -Port 80

   The first command should return TcpTestSucceeded : True. The second (CCTV) should also return True if CCTV is still on the standard port — this confirms the public IP is shared between services.
2. Test the web server separately by opening https://203.0.113.45:8443 in a browser. The PLC's standard web page should appear.
3. Run "Accessible nodes" in TIA Portal: Online → Accessible nodes. The CPU should appear in the list with its internal IP and a green status icon.
4. Perform a real "Go Online" and download the online snapshot. Verify the project tree shows the actual online blocks, not offline placeholders.
5. Cross-check the TIA Portal diagnostic buffer on the CPU: the most recent entries should be from the engineering PC's public IP. This confirms the path is correct.

Troubleshooting Matrix

Remote Desktop Bridging Scenario

Many engineers first establish a Remote Desktop Protocol (RDP) session from the office PC to a jump host on the customer LAN, then run TIA Portal on the jump host to reach the PLC. In this architecture, the S7 connection does not traverse the internet at all — only RDP does.

To change the RDP listening port on the jump host, follow Microsoft's documented procedure at Change the Remote Desktop listening port. After the change, restart the Remote Desktop Services service. The new external port on the site firewall must be opened (e.g., external 50001 → internal 3389).

This RDP+jump-host topology is the safest of the three options because the S7 service is never directly reachable from the internet. Combined with an SMB/CIFS share, it also lets the engineer transfer project archives without exposing any industrial port. The trade-off is that all engineering traffic is funnelled through one Windows box — that box becomes a single point of failure and a high-value target, so it must be patched and monitored.

Comparison of Remote Access Architectures

Standards and References to Verify Against

The following official documents underpin the port numbers and behaviours described in this article. Confirm against the latest revision when commissioning.

• Siemens Online Support entry ID 109751706: "S7-1200 programmable controller — System Manual" (section: Communication services and port numbers). The current edition covers firmware V4.x.
• Siemens Online Support entry ID 68011496: "S7-1200 / S7-1500 — List of communication services and port numbers" — the consolidated cross-platform reference used by Siemens support engineers.
• Siemens Online Support entry ID 109478121: "Security with SIMATIC S7-1200/S7-1500" — guidance on access levels, passwords, and the Web Server security configuration.
• RFC 1006 — ISO Transport Service on top of the TCP Version 3 — the encapsulation that defines TCP/102 as the S7 transport.
• Microsoft Change the Remote Desktop listening port — Windows-side procedure for non-default RDP ports.
• Microsoft Ports used by RDS — full list of TCP/UDP ports for Remote Desktop Services.