Problem Overview
Remote commissioning of Siemens SIMATIC S7-1200, S7-1500, S7-300, and S7-400 PLCs through TeamViewer VPN is one of the most frequently attempted—but least understood—connectivity scenarios in industrial automation. Engineers consistently report a working ping from the local programming device (PG/PC) to the remote PC's TeamViewer VPN adapter, but a total failure to bring the target PLC online inside TIA Portal, STEP 7 V5.x, or WinCC. The connection is partially up: TCP/IP seems to be alive, but the S7 communication layer never negotiates, and the S7-Online node list returns nothing or hangs.
This article documents the underlying asymmetric-routing problem inherent to the TeamViewer VPN driver model, provides reproducible step-by-step remediation for TIA Portal V13 through V18, and lists the verification commands and registry keys required to confirm a working link before opening TIA Portal.
Typical Failure Symptoms
| Symptom | Reported By | Likely Layer |
|---|---|---|
TeamViewer VPN connects, both sides show a TAP adapter with 7.x.x.x or AAA.AAA.AAA.AAA address |
All | OS / driver |
ping <remote PC LAN IP> succeeds |
All | Layer 3 — local |
ping <PLC PROFINET IP> fails with "Destination host unreachable" or "Request timed out" |
All | Layer 3 — remote |
Reverse: ping from remote PC to local PG also fails |
Some | Routing |
| TIA Portal "Go Online" → no accessible nodes / "Cannot establish connection to target" | All | S7 protocol |
| STEP 7 V5.5 shows PLC icon with red X under Accessible Nodes | STEP 7 users | S7 protocol |
Network Architecture Reference
Three IP networks must coexist for the link to function. The TeamViewer VPN driver is a Layer 3 / TAP-Windows adapter that does not perform source NAT (SNAT). The remote PC and the local PC each receive a private address (commonly 7.x.x.x or 100.x.x.x depending on TeamViewer version), and the remote PC is the only router between the VPN network and the plant network where the PLC lives.
Local PG/PC <---> TeamViewer VPN tunnel <---> Remote PC <---> Plant LAN <---> PLC 192.168.100.99 7.0.0.x / 7.0.0.y 192.168.18.254 192.168.18.1 (prog device) (VPN link) (router host) (S7-1200 PN)
Where the Remote PC must act as an IP router between the VPN segment and the plant LAN. This requires:
- Two physical or virtual NICs (one bound to the plant LAN, one bound to the TeamViewer VPN adapter).
- Windows IP routing enabled (
IPEnableRouter=1in registry, ornetsh routingin older OS). - Correct static routes on the Local PG/PC pointing the plant subnet through the remote PC's VPN IP.
- No firewall on the remote PC blocking ICMP, TCP/UDP 102 (S7), TCP/UDP 34962/34963/34964 (PROFINET), and TCP 80/443 (Web Server of S7-1500).
Root Cause: Asymmetric Routing and Source Address Mismatch
The classic error is what forum users call "ping goes one way." When the local PG sends an ICMP echo to PLC IP 192.168.18.1:
- PG routing table resolves the destination
192.168.18.0/24to the remote PC's VPN IP (e.g.7.7.7.2) as the next hop. - Packet is encapsulated by TeamViewer VPN and reaches the remote PC's VPN adapter.
- Remote PC, acting as router, forwards the packet out the LAN NIC to the PLC because the plant subnet is directly connected.
- PLC sees a packet with source IP = local PG's VPN IP (e.g.
7.7.7.1), not a local subnet address. - PLC attempts to reply to
7.7.7.1. It has no route to the VPN subnet, so the reply is dropped, or the reply is sent to its default gateway, which also has no route to7.7.x.x.
Result: ICMP echo request is delivered, echo reply is lost. Ping fails, and TCP/UDP S7 handshake never receives SYN-ACK. TIA Portal reports "No accessible nodes."
7.0.0.0/8. Therefore, the only viable fix is to either (a) make the local PG use an IP from the plant subnet on its TeamViewer VPN adapter, or (b) place a router between the VPN and the PLC that performs source NAT. The most common field solution is (a): set the local PG's TeamViewer VPN adapter to a free address inside the plant subnet.Prerequisites
| Item | Specification |
|---|---|
| TeamViewer (Full or Host) | V13+ on both sides with VPN option licensed |
| Windows OS | Windows 7 SP1 / 10 / 11 / Server 2016+ |
| Remote PC NIC | One wired Ethernet on plant LAN, no proxy |
| Admin rights | Required on both PCs (route add, registry edit, firewall) |
| TIA Portal | V13 SP1 / V14 / V15 / V15.1 / V16 / V17 / V18 — same major version or compatible |
| Siemens PLC firmware | S7-1200 FW ≥ 4.2, S7-1500 FW ≥ 1.8 for fully reliable online diagnostics over VPN |
| PG/PC interface | S7ONLINE (STEP 7) or Intel/PROFINET with TCP/IP auto-detection |
Configuration Procedure (Authoritative Sequence)
Step 1 — Verify Plant LAN Reachability from the Remote PC
- On the remote PC directly connected to the PLC network, open a command prompt:
ping 192.168.18.1
If this fails, the PLC is unreachable even on the local network. The VPN layer is not the problem. Check cable, PLC power, X1 LED, and that the PLC has a valid IP (visible via the SIMATIC Automation Tool or the PLC's display on S7-1500).
Step 2 — Configure Static IP on the Remote PC's LAN Adapter
Set the remote PC's plant-facing NIC to a free, in-subnet address different from the PLC:
IP: 192.168.18.254
Subnet: 255.255.255.0
Gateway: leave blank if no upstream router
This address will become the default gateway on the PLC in a later step, and the target of the static route on the local PG.
Step 3 — Enable IP Routing on the Remote PC
Windows 10 / 11 / Server 2016+ does not auto-enable IPv4 forwarding. The setting is in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: IPEnableRouter
Type: REG_DWORD
Data: 1
After saving, reboot the remote PC. To confirm:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v IPEnableRouter
Expected output: IPEnableRouter REG_DWORD 0x1
Step 4 — Configure the PLC's IP and Default Gateway
In TIA Portal project, open Device View → PLC → Properties → PROFINET interface [X1] → Ethernet addresses.
| Field | Value |
|---|---|
| IP address | 192.168.18.1 |
| Subnet mask | 255.255.255.0 |
| Use router | ✓ enabled |
| Default router | 192.168.18.254 |
Compile the hardware configuration and download to the PLC (locally, not over VPN). Without the router entry, the PLC will refuse to send replies outside its /24.
Step 5 — Allow Protocols in Windows Firewall on the Remote PC
Open an elevated PowerShell and add the required inbound rules:
New-NetFirewallRule -DisplayName "S7-Comm 102 TCP" -Direction Inbound -Protocol TCP -LocalPort 102 -Action Allow
New-NetFirewallRule -DisplayName "S7-Comm 102 UDP" -Direction Inbound -Protocol UDP -LocalPort 102 -Action Allow
New-NetFirewallRule -DisplayName "PN RT 34962" -Direction Inbound -Protocol UDP -LocalPort 34962,34963,34964 -Action Allow
New-NetFirewallRule -DisplayName "ICMPv4" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow
Step 6 — Establish TeamViewer VPN
- On the remote PC, install TeamViewer Host, open Options → Advanced → Install VPN driver.
- Connect from the local PG using the remote PC's TeamViewer ID and the VPN password (Options → Security → Random password for incoming connections, or a personal password).
- After handshake, both sides show a new "TeamViewer VPN Adapter" in
ipconfig /all. Note the assigned IPs:
Local PG → TeamViewer VPN IP : 7.177.10.1
Remote PC → TeamViewer VPN IP : 7.177.10.2
Step 7 — Add Static Route on the Local PG/PC
Open an elevated command prompt on the local PG/PC:
route add 192.168.18.0 mask 255.255.255.0 7.177.10.2 metric 1
This forces traffic for the plant subnet through the TeamViewer VPN to the remote PC, where IP forwarding (Step 3) hands it to the LAN NIC.
metric 1 only when no better route exists. If the local PG has Wi-Fi on 192.168.0.0/24 and the plant is on 192.168.18.0/24, there is no overlap and the metric is irrelevant. If the local PG is on 192.168.18.0/24 directly (lab scenario), then the route conflicts—use a /32 host route to the PLC instead, or set the VPN adapter to a non-overlapping subnet like 10.255.255.0/30.Step 8 — Add Return Route on the Remote PC (if Required)
When the local PG is on a different physical subnet, the remote PC needs to know how to send replies back through the VPN. Normally, the VPN adapter's own subnet covers this, but if the local PG uses a /32 VPN IP and the remote has a /24, you may need:
route add 7.177.10.1 mask 255.255.255.255 7.177.10.1 metric 1
In most TeamViewer builds this is automatic.
Step 9 — TIA Portal: Set PG/PC Interface
- Open TIA Portal → Options → Set PG/PC Interface.
- Select S7ONLINE (STEP 7) → TCP/IP (Auto) → TeamViewer VPN Adapter.
- Click OK and restart TIA Portal.
Step 10 — Go Online
- Project tree → right-click the PLC → Go online.
- If prompted, select PN/IE as the subnet and enter the direct PLC IP
192.168.18.1. - TIA Portal will broadcast an S7 ISO-on-TCP / TCP ARP probe and discover the CPU within 2–5 seconds.
Verification Matrix
| Test | Command (from local PG) | Expected | Pass Criteria |
|---|---|---|---|
| VPN adapter presence | ipconfig /all | findstr "TeamViewer" |
Adapter listed with VPN IP | Non-empty output |
| Tunnel to remote VPN IP | ping 7.177.10.2 |
< 50 ms reply | 0% loss |
| Tunnel to remote LAN IP | ping 192.168.18.254 |
Reply from remote LAN | 0% loss |
| Tunnel to PLC | ping 192.168.18.1 |
Reply from PLC MAC | 0% loss, < 100 ms |
| ARP resolution | arp -a | findstr 192.168.18.1 |
PLC MAC listed, type dynamic | MAC present |
| S7 TCP port reach | Test-NetConnection 192.168.18.1 -Port 102 |
TcpTestSucceeded: True | True |
| PROFINET discovery |
PROFINET Discovery Tool from Siemens |
PLC node listed | Found |
| TIA online | Go Online button | CPU online icon (green check) | Online |
Why "Ping Fails But TIA Finds It" Sometimes Works
When the local PG and the PLC happen to share a /24 (for example, both on 192.168.18.x), the ICMP echo request reaches the PLC, and the PLC replies directly to the source IP. If the local PG is on Wi-Fi 192.168.18.50 but the local PG's TeamViewer VPN adapter is 7.x, the ICMP reply returns from the PLC to 7.x, which the PG's default route resolves through the VPN—but with a non-zero chance of asymmetric-path filtering on intermediate switches. TIA Portal can still succeed because the S7 transport is connection-oriented (TCP/102) and survives a few dropped SYN packets through retransmission, while ICMP gets a single shot.
Why "Ping Succeeds But TIA Fails" Happens
The opposite case—ICMP green, TIA red—indicates that either:
- The PLC's default gateway is misconfigured and the ICMP reply is being generated by the local NIC of the remote PC (proxy-ARP behavior), not the PLC itself. Fix: set the gateway correctly on the PLC.
- A Windows Firewall rule on the remote PC blocks TCP/102 inbound but allows ICMPv4. Fix: open TCP/102 explicitly as shown in Step 5.
- TIA Portal's PG/PC interface is still pointing at the local Ethernet adapter. Fix: re-select the TeamViewer VPN adapter.
- The remote PC's local network has a second router (e.g., a managed switch with Layer 3) that intercepts ARP for the PLC. Fix: set a static ARP entry on the remote PC's LAN NIC or disable proxy-ARP on the switch.
Why "Ping Fails from Remote PC Back to Local PG" Happens
The local PG often has its main network on a different subnet from the TeamViewer VPN adapter. The remote PC has no route to that subnet, so the PG's reply to the remote PC's ping dies at the remote PC's LAN. Solutions:
- Add a static route on the remote PC for the local PG's main subnet through the VPN IP of the local PG.
- Disable the local PG's Wi-Fi temporarily so only the TeamViewer VPN adapter has a route back.
- On the local PG, disable the "Register this connection's addresses in DNS" and the NetBIOS advertisements on the VPN adapter to avoid name-conflict broadcasts.
Working TIA Portal Online Mode Over VPN — What Actually Happens
- TIA Portal sends an ISO-on-TCP CR (Connection Request) to TCP/102 of the PLC.
- The S7-1200/1500 responds with CC (Connection Confirm).
- TIA Portal performs an S7 read of system status list (SSL) IDs 0x0011, 0x0012, 0x0013, 0x001C, 0x0131, 0x0132 to enumerate the CPU order number, module name, firmware, and protection level.
- If the CPU is password-protected, TIA Portal prompts for the password over the same secure S7 channel.
- On success, the project node turns green and "Go online" is sustained.
Each of these round-trips is unidirectional from the PG's perspective. If the return path is broken—even partially—the SSL reads time out and TIA Portal displays "Cannot establish a connection to the target module."
Common Pitfalls and Field-Proven Corrections
| Pitfall | Symptom | Fix |
|---|---|---|
| PLC gateway left at 0.0.0.0 | Ping fails, TIA offline | Set PLC default router to remote PC LAN IP |
| Remote PC firewall on | Ping OK, TIA offline | Open TCP/102, UDP 34962-34964 inbound |
| IPEnableRouter missing | Ping OK from remote, fails from local | Regedit + reboot |
| TeamViewer VPN driver not installed | Adapter not in ipconfig | Options → Advanced → Install VPN driver |
| Local PG has two IPs (192.168.0.60 and 7.x) | TIA confused, picks wrong adapter | Set PG/PC interface manually to TeamViewer VPN |
route add typo: mask 255.255.0.0 on a /24 network |
"The route addition failed: The parameter is incorrect" | Use 255.255.255.0 for /24, or 255.255.255.255 for a single host |
| PLC and remote PC swapped subnet | Ping to PLC from remote PC fails too | Recheck cabling and PLC's IP in project vs. online |
| Wi-Fi on remote PC and Wi-Fi on local PG share same SSID | Traffic hairpins through corporate AP, not VPN | Disable Wi-Fi on one side or bind TIA to VPN adapter only |
| PLC firmware < 4.2 (S7-1200) | Online slow, occasional disconnect | Upgrade FW via Siemens support: support.industry.siemens.com |
Alternative: Source-NAT Solution (No PLC Gateway Change)
If the PLC's gateway cannot be modified (locked project, third-party integrator), install a small Linux/OpenWrt router between the plant LAN and the VPN, or use the remote PC's Internet Connection Sharing (ICS) to perform source NAT. With ICS enabled, the VPN sees the PLC as 192.168.137.1—the ICS host address—rather than the original 192.168.18.1. TIA Portal then targets 192.168.137.1. The trade-off is that you can no longer access other devices in the plant LAN without separate NAT rules.
Alternative: Sinema Remote Connect or SCALANCE
For production environments, Siemens offers SINEMA Remote Connect, a server-based VPN with native integration into TIA Portal. It eliminates the TeamViewer dependency and supports certificate-based mutual TLS, audit logging, and IPsec tunnels. Reference: SINEMA Remote Connect Getting Started. For S7-1500 stations, a SCALANCE M87x/MUM85x router can be deployed in the field to terminate an IPsec tunnel from TIA Portal directly, with no intermediate PC. See Siemens Industry Online Support for the matching application example.
FAQ
Why can I ping the remote PC but not the PLC over TeamViewer VPN?
The remote PC replies using its directly connected TeamViewer VPN interface, so the return path is trivial. The PLC has no route back to the TeamViewer VPN subnet (7.x.x.x or 100.x.x.x). Set the PLC's default gateway in TIA Portal to the remote PC's LAN IP (e.g., 192.168.18.254) and enable IP forwarding on the remote PC via registry IPEnableRouter=1.
Do I need a static route on the local PG/PC?
Yes. Add route add <plant-subnet> mask <mask> <remote-PC-VPN-IP> metric 1 on the local PG so traffic for the PLC's subnet is forced through the TeamViewer VPN tunnel. Without it, the default route may send the packet out the local Wi-Fi and never reach the remote site.
TIA Portal shows "No accessible nodes" even though ping works—what now?
ICMP is allowed through the firewall but TCP/102 is not. On the remote PC add inbound firewall rules for TCP and UDP port 102, plus UDP 34962-34964 for PROFINET. Then re-select the PG/PC interface in TIA Portal to point at the TeamViewer VPN adapter, restart TIA Portal, and try "Go online → PN/IE" with the PLC's direct IP.
What does "The route addition failed: The parameter is incorrect" mean?
The subnet mask does not match the destination class or is invalid for the route command. For a /24 plant network use 255.255.255.0. For a single host (one PLC only) use 255.255.255.255. The mask and destination must agree in their bit boundaries.
Can I keep the remote PC's gateway empty on the PLC?
No. Without a default gateway, the PLC will not send any packet whose destination is outside its own /24 subnet. TeamViewer VPN addresses are outside that subnet, so all replies from the PLC to the local PG would be dropped. The gateway must point to a router that has a route back to the TeamViewer VPN subnet—that router is the remote PC acting as a Layer 3 forwarder.
Is there a Siemens-native alternative to TeamViewer VPN?
Yes. SINEMA Remote Connect provides a server-mediated VPN with certificate-based authentication, integration with TIA Portal, and granular access control. For permanent installations, SCALANCE M-800/MUM-850 industrial routers with IPsec are recommended. Both are documented on the Siemens Industry Online Support portal.