Troubleshooting WinCC Flexible KTP600 Remote Transfer via Port

1. Problem Overview

A common commissioning scenario involves a Siemens KTP600 PN HMI panel (IP 192.168.0.10) connected to a S7-300 CPU 315-2 PN/DP (IP 192.168.0.2) on a remote Ethernet subnet, accessed over the public internet through a router that performs NAT and port forwarding. The user reports that the S7 CPU is reachable from a remote engineering station (PG) through forwarded TCP port 102, but WinCC flexible transfer of the HMI project to the KTP600 fails despite port-forwarding 2308 and 50523 to the panel.

This is one of the most frequently encountered issues when exposing Siemens HMI panels to the public internet. The root cause is rarely a missing forwarded port — it is typically a combination of:

• Missing S7 routing in the PLC's HW Config (the "Use router" / "Router is used" option).
• Asymmetric routing caused by NAT and the HMI's lack of awareness of the public IP address.
• Missing or misconfigured PG/PC interface assignment on the engineering station.
• Default HMI transfer-mode (passive-only) requiring the operator to press Transfer on the panel.
• Missing return-path rules for HMI-initiated connection attempts.
• Windows Firewall or third-party firewall blocking the inbound high ports.

2. Reference Network Topology

The typical topology exposed in this scenario is:

  Remote PG (Engineering Station)
        |
   [ Public Internet ]
        |
   Router A (WAN: public IP, e.g. 203.0.113.5)
   Router A forwards:
        TCP 102    -> 192.168.0.2   (CPU 315-2 PN/DP)
        TCP 2308   -> 192.168.0.10  (KTP600)
        TCP 50523  -> 192.168.0.10  (KTP600)
        |
   LAN 192.168.0.0/24
        |
   S7-300 CPU 315-2 PN/DP   192.168.0.2
   KTP600 PN                  192.168.0.10
   Default gateway             192.168.0.1

The CPU is reachable because port 102 is forwarded and S7 communication is unidirectional for the transfer handshake. The HMI panel, however, performs an active TCP connect back to the engineering station for certain transfer phases — and the panel does not know the public IP, which is the source of the failure.

3. WinCC Flexible / KTP600 Transfer Port Reference

Siemens documents the following ports as relevant to HMI transfer for WinCC flexible 2008 SP5 and later, and TIA Portal (WinCC Comfort/Advanced) when used against a KTP600 PN:

4. Root Cause: HMI Transfer Directionality

WinCC flexible performs an HMI project transfer using two distinct phases:

1. Discovery / announcement — the engineering station attempts to connect to TCP 2308 on the panel's IP (in this case the public IP of the router, NAT'd to 192.168.0.10).
2. Transfer handshake / start screen — the panel often initiates an outbound connection back to the PG, typically to TCP 50523 of the source IP it learned in phase 1. It uses the source IP that initiated the original TCP 2308 connection as the destination.

When the engineering station is on a private network behind a different NAT (or even on a corporate network), the HMI's outbound connection attempt goes to the PG's private IP (because that is what the panel saw in the packet header before the router's NAT). The router's NAT state for the inbound 2308 connection has been preserved, but the HMI's outbound 50523 connection has no matching state, and the destination IP is unreachable from the panel's perspective.

This is the single most common cause of "Connection could not be established" in this configuration.

5. Required Configuration: S7 Routing in HW Config

For a CPU 315-2 PN/DP to act as a router between two subnets (or to participate in cross-network HMI transfer), S7 routing must be enabled. Without it, the CPU will not forward S7 routing telegrams between subnets.

1. Open the S7 project in SIMATIC Manager (Step 7 V5.5 / V5.6).
2. Open HW Config and double-click the CPU 315-2 PN/DP slot.
3. Navigate to the Properties → Interface → Ethernet tab (or "PN-IO" tab on older versions).
4. Click the "Use router" / "Router is used" checkbox. This is the option that enables S7 routing through the CPU.
5. Confirm the IP address (192.168.0.2) and Subnet mask (255.255.255.0) are correct.
6. If a separate router exists on the network, check "Set MAC address / use ISO protocol" only if your network uses ISO transport — for a pure Ethernet/IP plant, leave it off.
7. Compile and download the HW Config to the CPU.

6. PG/PC Interface Assignment on the Engineering Station

WinCC flexible selects the network adapter through the Set PG/PC Interface tool. If the wrong adapter is selected, the engineering station will attempt to use a local subnet (e.g. 10.0.0.x) that is not reachable to the panel's 192.168.0.0/24 network.

1. Open Start → SIMATIC → STEP 7 → Set PG/PC Interface or Control Panel → Set PG-PC Interface.
2. Select TCP/IP(Auto) → <your physical network adapter> — do not select S7ONLINE or any virtual adapter.
3. In WinCC flexible, open Project → Transfer → Transfer Settings.
4. Set Mode to Ethernet.
5. Enter the panel's public IP (e.g. 203.0.113.5) and click Check.
6. Confirm the connection is reachable by using ping from a command prompt. If ping fails, the WinCC transfer will also fail — solve L3 reachability first.

7. Port Forwarding Rules and Firewall

The remote router must forward the following ports to the panel (192.168.0.10):

Additional rules that are frequently missed:

• Allow outbound from 192.168.0.10 to any on the LAN firewall — the panel must be able to initiate connections for the active phase of the transfer handshake.
• Allow outbound from 192.168.0.2 to any for S7 routing replies.
• Disable SIP ALG and any "SPI" / "Stateful Packet Inspection" feature in the router that aggressively reuses state tables. Some consumer routers (TP-Link, D-Link, Mikrotik default) drop or reset the HMI's outbound 50523 attempts because they see no matching inbound state.
• On Windows Firewall on the engineering station, allow inbound TCP 2308 and 50523 from any source (or at minimum from 192.168.0.0/24 and the public IP of the remote site if known).

8. Resolving the NAT Asymmetry (Hairpin / NAT Loopback)

Three workarounds address the NAT asymmetry depending on the remote router's capabilities:

8.1 Method A: Hairpin NAT (preferred)

If the remote site router supports NAT hairpin (also called NAT loopback), traffic from the LAN to the public IP of the same router is rewritten so it goes back into the LAN. On Mikrotik, enable srcnat with dst-address=public_ip/32 and action=masquerade. On Linux iptables use:

On consumer routers (e.g. ASUS, AVM FRITZ!Box), hairpin is usually enabled by default when NAT is on.

8.2 Method B: VPN (recommended for production)

Install an IPSec or WireGuard tunnel from the engineering station to the remote site. The PG receives an IP in the 192.168.0.0/24 range, and the HMI transfer proceeds without NAT. This is the factory-recommended method for remote commissioning per Siemens Support entry "Remote access to SIMATIC HMI panels" and avoids port exposure to the public internet entirely.

8.3 Method C: Static 1:1 NAT (DMZ equivalent)

Map the entire public IP to the panel's private IP. All traffic destined for the public IP is forwarded. This is wasteful and only practical for dedicated cellular SIMs with a single static IP. Combine with strict source-IP whitelisting on the router.

9. HMI Transfer Mode: Active vs Passive

The KTP600 PN ships in passive transfer mode by default. The operator must press Transfer on the panel before WinCC flexible can push a project. For unattended remote transfer:

1. On the KTP600, navigate to Control Panel → OP → Transfer.
2. Set Channel to Ethernet.
3. Set Remote Control to On (if present; only on firmware V13+ and Comfort Panels).
4. For full unattended transfer, set Auto-Transfer to Yes if available.

On WinCC flexible, ensure Project → Transfer → Transfer Settings → Ethernet → "Wait for transfer request" timeout is set to a value greater than the time required to manually press Transfer on the panel (default 60 s).

10. TIA Portal Alternative for Newer KTP600 Firmware

If the KTP600 PN runs firmware V13.0.1.0 or higher, the panel is programmable from TIA Portal V13+. TIA Portal introduces several improvements for remote transfer:

• Native HTTPS (port 443) transfer with optional certificate pinning.
• Secure S7 communication (port 102) over TLS using Secure PG/PC-HMI communication.
• Integrated TeamViewer remote access via Online → Accessible devices when the panel has the HMI SP license and a TeamViewer account configured.

The same routing and port-forwarding rules apply, with the addition that TIA Portal's first scan of the network will use UDP 69 (TFTP-style discovery) — this should be opened bidirectionally, or static IP entry should be used in the transfer dialog.

11. Step-by-Step Verification Procedure

After applying the changes, verify in this order:

1. From the remote PG, run ping <public_ip> — should respond.
2. From the remote PG, run telnet <public_ip> 2308 — should produce a blank screen (port open).
3. From the remote PG, run telnet <public_ip> 50523 — should produce a blank screen (port open).
4. From the remote PG, run telnet <public_ip> 102 — should produce a blank screen (port open, CPU).
5. Open WinCC flexible, Project → Transfer → Transfer. The status bar should read Connecting... then Connected.
6. Click Transfer in WinCC flexible. The status should read Compiling and transferring... followed by Transfer completed successfully.
7. The panel should reboot and run the new project.

12. Common Error Messages and Resolutions

13. Security Recommendations

Exposing an HMI panel on the public internet is a significant security risk. A direct port forward of 2308/50523 to a Siemens panel can be fingerprinted within minutes and exploited for unauthorized project upload, firmware changes, or used as a pivot into the OT network. Siemens security guidance "Security for SIMATIC HMI panels" recommends:

• Always prefer VPN over port forwarding for remote access.
• Restrict source IP ranges via firewall allow-listing at the router.
• Set a strong transfer password on the KTP600 (Control Panel → OP → Security).
• Disable unused services (Sm@rtServer, web server, OPC UA) if not required.
• Monitor logs of the router for repeated connection attempts on 2308 / 50523 — they are a known reconnaissance signature.

14. Field-Proven Best Practices

• Always perform the first project transfer on the local network before exposing the panel remotely. This isolates programming errors from network errors.
• Document the panel's IP, transfer password, and the engineer's public IP inside the project for repeatability.
• If multiple panels are deployed, use a mini-SCADA router (e.g. SCALANCE M876) with IPSec instead of consumer-grade port forwarding.
• For S7-300 systems, prefer CPU 315-2 PN/DP firmware V3.3 or higher; older firmware has known routing bugs documented in Siemens FAQ 23833950.
• Always test with Wireshark on the PG side filtering tcp.port == 2308 || tcp.port == 50523 || tcp.port == 102. The packet capture will show whether the SYN is going to the correct destination and whether a SYN-ACK is returned — this cuts troubleshooting time in half.

FAQ