S7-1200 Accessible Nodes Search Over VPN: TIA Portal Workaround

1. Problem Description

When commissioning or maintaining a Siemens S7-1200 (e.g., CPU 1214C) fleet across a remote site connected through an OpenVPN tunnel, engineers frequently encounter a specific failure mode in TIA Portal: the "Search for accessible nodes" command returns no devices, even though the engineering station can ping every PLC IP address on the remote subnet. The same TIA Portal instance can still go online, download hardware configuration, and upload blocks once a direct connection is forced. This asymmetric failure is consistently reproducible when the engineering PC sits behind an OpenVPN bridge-mode tunnel and attempts to discover S7-1200 stations across that tunnel.

The error is observed across TIA Portal V11 SP2 and later versions. It is independent of the SIMATIC network interface card driver revision and is not a firewall or anti-virus issue, because ping and ISO-on-TCP/TCP port-based access to the PLCs work normally.

2. Root Cause: LLDP and the OSI Layer Boundary

The Search for accessible nodes function in TIA Portal is not a TCP/IP discovery. It is built on top of LLDP (Link Layer Discovery Protocol, IEEE 802.1AB), augmented with Siemens-proprietary DCP (Discovery and Configuration Protocol) frames. Both protocols operate at OSI Layer 2, the same layer that carries MAC addresses and Ethernet broadcasts.

LLDP uses destination MAC address 01:80:C2:00:00:0E and is transmitted as a link-local multicast that is intentionally not forwarded by IP routers. RFC 2922 and the IEEE 802.1AB-2016 specification explicitly state that LLDP frames are confined to a single physical or logical LAN segment, including 802.1Q VLANs. Routers, layer-3 switches, and IP-tunneling protocols (such as OpenVPN in routed/TUN mode) discard these frames at the network boundary.

The S7-1200 firmware (V4.0 through V4.6, and the current V4.7 line) embeds an LLDP agent that:

• Advertises the CPU's chassis ID, port ID, system name, and system description every 30 seconds (default txInterval = 30, txHold = 4).
• Responds to DCP Identify requests with its MAC address, IP, device name, and PROFINET role.
• Listens on UDP port 17464 (DCP) and the LLDP multicast group.

When TIA Portal's online-access tree is expanded, the Siemens SIMATIC Ethernet Device NDIS driver issues a DCP Identify broadcast on the bound interface. If that interface is a TAP-Win32/OpenVPN TAP adapter that is bridged to a remote subnet, the broadcast traverses the tunnel only if the far-end OpenVPN server is also configured in tap/bridged mode and the bridge is a single broadcast domain. UMTS (3G/4G) and many cellular routers drop or rate-limit the resulting multicast/L2 frames, breaking discovery even when bridging is technically enabled.

3. Protocol Stack Analysis

The asymmetry of the failure is fully explained by this stack: ping (ICMP) and Go Online (TCP/102) are layer-3 and higher, both routable through any IP tunnel. DCP and LLDP are layer-2, and an OpenVPN bridge only opportunistically transports them; it is not a guaranteed path, particularly over cellular links.

4. Why OpenVPN Bridged Mode Does Not Fully Solve the Problem

OpenVPN supports two virtual interface types:

• TUN (routed): IP-only virtual interface; broadcasts are not forwarded between endpoints.
• TAP (bridged): Emulates a full Ethernet NIC; broadcasts, multicasts, and arbitrary EtherTypes can traverse the tunnel.

To pass LLDP/DCP, the server dev tap directive and a real OS-level bridge (e.g., br0 on Linux, or Network Bridge on Windows) joining the TAP device with the physical LAN interface are required on the far end. Even with that configuration, the following field-proven caveats apply:

1. MTU clamping. LLDP frames fit inside the standard 1500-byte MTU, but OpenVPN's own UDP encapsulation adds ~70 bytes; an undersized tunnel MTU silently fragments or drops discovery frames.
2. Multicast suppression. Many UMTS/LTE routers default to disabling multicast and broadcast acceleration; an explicit multicast-enable may be required, and on some cellular firmware it is impossible.
3. Firewall on the engineering PC. Windows Firewall on the TAP adapter must allow inbound DCP/UDP/17464 and outbound LLDP multicast.
4. Driver binding. The TIA Portal "Online access" tree binds to a specific Windows NIC. If the TAP adapter is not visible there, the SIMATIC driver will not transmit the DCP Identify frame across the tunnel.

5. Workaround: Use Extended Go Online with an Explicit IP

The cleanest engineering fix is to bypass Layer 2 discovery entirely and connect directly to a known IP. TIA Portal supports this through the Extended go online / Extended download to device dialog, which is part of the standard online workflow as documented in the official Siemens online help.

5.1 Prerequisites

• You know the IP address, PROFINET device name, and (optionally) the rack/slot of the target S7-1200.
• The OpenVPN tunnel is established and the TAP adapter has a valid IP on the remote subnet.
• The S7-1200's PUT/GET or S7 communication is permitted in the CPU's protection settings (PLC properties → Connection mechanisms → Permit access via PUT/GET communication or equivalent in the protection tab).
• TIA Portal project is open or the user is working from the project overview / "Online access" tree.

5.2 Step-by-Step Procedure

1. In the TIA Portal project tree, expand Online access.
2. Right-click the TAP/OpenVPN-bound interface (e.g., "TAP-Windows Adapter V9") and choose Update accessible devices. (This step is informational; it will likely still return empty.)
3. Switch to the Project view and select the target device in the project tree (PLC_1, CPU 1214C, etc.). If no project exists for the target station, create a new project and add an Unspecified CPU 1200 matching the firmware version, then save the project.
4. Click the Go online button (the lightning-bolt-with-cable icon) on the toolbar.
5. If the standard Go Online dialog appears, click Go online to attempt TCP/102. If it fails, click Extended go online.
6. In the Extended go online dialog, set:
   • Type of the PG/PC interface: PN/IE
   • PG/PC interface: The TAP/OpenVPN adapter
   • Connection to target system: Directly at the slot 'X1' of the target station
7. Click Find — TIA Portal will issue a unicast DCP Identify to the specific IP/subnet you specify in Target station IP address (and, if your version supports it, a unicast LLDP request). Empty results are not a failure here; proceed to the next step.
8. Enter the target S7-1200's IP address in the IP address field.
9. Click Go online. The connection establishes over ISO-on-TCP (TCP/102), independent of LLDP/DCP.
10. Confirm the online state in the status bar (orange/yellow indicator on the device).

5.3 Alternative: Direct Address Entry in the Online Access Tree

For read-only online operations (e.g., Online & Diagnostics, watch tables, force tables) without a configured project, use the Online → Accessible devices (extended) path introduced in newer TIA Portal versions. Enter the IP address of the S7-1200 in the dialog and select PN/IE as the interface type. The connection then uses unicast TCP/102 and does not require LLDP/DCP success.

6. Long-Term Solutions

For multi-station sites where repeated IP entry is impractical, the following options scale better than manual entry per device:

6.1 Static Address Mapping on the VPN Router

Assign fixed IP addresses to the S7-1200 stations out of a documented scheme (e.g., 10.20.30.0/24 with the S7-1200 always at 10.20.30.50). Maintain a CSV or project-side address list and import it when needed.

6.2 SNMP-Based Asset Discovery

Many site routers expose an SNMP agent. Although SNMP will not enable online access on its own, it can confirm that the S7-1200 is reachable and report its PROFINET name. This pre-flights the connection before TIA Portal attempts online access.

6.3 Dedicated Maintenance VPN with Routed TUN

If Layer 2 bridging is unreliable, design a routed VPN (TUN mode) instead, with static routes to the S7-1200 subnet. The S7-1200 will not respond to DCP across the routed path, but the engineer can use the Extended Go Online unicast flow described in Section 5.

6.4 PROFINET Asset Discovery via Engineering Tool

For PROFINET-heavy plants, the TIA Portal Topology editor and Devices & Networks view allow reading the topology directly from a known online station. Once one S7-1200 is reached, the rest of the PROFINET subnet can be enumerated via the PROFINET controller's neighbor table and ARP cache — bypassing the LLDP/DCP broadcast entirely.

7. VPN Configuration Checklist for TIA Portal Discovery

8. TIA Portal Version Compatibility

The behavior is not version-specific to TIA Portal; it is a protocol-layer limitation. Later versions have a more discoverable "Online → Accessible devices (extended)" entry point, which is the recommended path in modern installations.

9. Verification

After applying the workaround, perform the following checks to confirm a stable remote maintenance link:

1. Round-trip latency: Issue ping -t <PLC IP> from a command prompt; document RTT for trend monitoring. Typical UMTS links run 150–400 ms; expect Go Online to take 5–15 seconds under such conditions.
2. TCP/102 reachability: From PowerShell, Test-NetConnection -ComputerName <PLC IP> -Port 102. A successful TcpTestSucceeded: True is the precondition for Extended Go Online.
3. Online state color: In TIA Portal, the device icon turns orange/yellow when online. The status line should report "Online — Read diagnostics".
4. Block consistency: Right-click the program blocks folder and select Compare offline/online. The two panes should be identical if you have the correct project, or all blocks should show a time stamp difference if you are uploading from the device.
5. Watch table test: Create a watch table with one input (%I0.0) and one output (%Q0.0). Toggle the input and confirm the value updates in the watch table within one second of the engineering command — this confirms a healthy online session, not a cached display.

10. Troubleshooting Matrix

11. Field-Proven Notes

• Don't trust "ping works, so engineering will work." A successful ping only proves Layer 3 is healthy. TIA Portal Go Online needs TCP/102 to be reachable on the remote PLC, which is a separate firewall and NAT consideration.
• Don't run two TAP adapters concurrently. Some OpenVPN versions ship multiple TAP-Win32 instances; if the wrong one is bound by TIA Portal, the search broadcast never reaches the tunnel. Confirm the active interface from Online access → [your interface] → Properties.
• Disable Windows Auto-Tuning on the TAP interface if you observe irregular fragmentation: netsh interface tcp set global autotuninglevel=disabled. This is rarely needed on modern firmware, but a useful diagnostic step on Windows XP / 7 hosts.
• On Windows XP Prof. SP3 (the configuration cited in the field report), TIA Portal V11 SP2 has known compatibility limitations with the TAP-Win32 driver shipped with newer OpenVPN builds. Pin the OpenVPN client to a 2.3.x release, or migrate the engineering host to Windows 10 / 11 with TIA Portal V17 or later for the best driver support.
• No "LLDP relay" exists for OpenVPN. Unlike CDP or EDP, LLDP has no standard IP-based relay (no LLDP-MED IP gateway is defined for this use case). The only correct architectural answer is to switch to unicast-based online access, as documented in Section 5.

12. Summary

"Search for accessible nodes" failing over a bridged OpenVPN tunnel is a Layer 2 protocol limitation, not a TIA Portal bug. LLDP and DCP are link-local protocols and are not designed to traverse IP tunnels, even when the tunnel uses TAP bridging. The supported Siemens workflow is to use the Extended go online dialog with an explicit IP address, which uses unicast TCP/102 and bypasses the L2 discovery step entirely. For remote sites with many S7-1200 stations, maintain a documented IP plan and standardize on a routed VPN (TUN) plus unicast online access for predictable maintenance. The official Siemens TIA Portal documentation for displaying accessible devices in V20 confirms the same unicast-based access path remains the recommended procedure.