Resolving TIA Portal PLC Discovery Failures Over VPN Networks

Problem Overview

When commissioning S7-1200, S7-1500, ET 200, or other PROFINET-capable Siemens controllers from outside the local plant network, the most common symptom reported by maintenance and commissioning engineers is that TIA Portal's Online > Accessible devices (formerly called the device scan or "scan and find different PLCs") returns an empty list, even when:

• The PLC responds correctly to ping from the engineering station.
• TCP/UDP port 102 (ISO-TSAP, ISO Transport Service Access Point) is open in both directions through the VPN tunnel.
• Broadcast traffic has been explicitly permitted on the VPN gateway and firewall.
• Antivirus software on the engineering workstation has been temporarily disabled for testing.
• The same TIA Portal project on the same PG/PC finds every device instantly when connected to the local plant LAN.

The mismatch between Layer 3 connectivity (ping succeeds) and device discovery (TIA scan returns empty) is the diagnostic signature of a Layer 2 protocol incompatibility across the VPN. The same symptom appears whether the tunnel is IPSec site-to-site, OpenVPN, WireGuard, Cisco AnyConnect, FortiClient, GlobalProtect, or a cloud-hosted SD-WAN appliance.

Root Cause: Why VPN Breaks the TIA Portal Scan

TIA Portal's Accessible devices scan is not a TCP-based service-discovery mechanism. It uses two PROFINET-defined Layer 2 protocols that ride directly on top of the Ethernet frame:

DCP is the protocol TIA Portal actually depends on for the scan. It is a PROFINET-specific protocol published as part of the PROFINET standard by PROFIBUS & PROFINET International (PI) and documented in the Siemens support entry 50203404 — "Why is the S7 station not found via the Accessible nodes?" and in the PROFINET specification on Discovery and Configuration Protocol. LLDP, standardized in IEEE 802.1AB, provides the topology graph shown in the Topology view tab of the Online & Diagnostics editor.

Why these protocols cannot traverse a standard VPN:

1. VPN tunnels operate at Layer 3. They encapsulate IP packets (TCP, UDP, ICMP) and forward them between routed networks. They do not forward raw Ethernet frames carrying DCP or LLDP multicast.
2. Even when the VPN is configured with a "full tunnel" that allows broadcast and multicast, the underlying transport (IPSec, SSL-VPN, WireGuard, etc.) does not natively replicate Ethernet multicast into IP multicast groups. DCP frames are sent to the PROFINET multicast MAC; they are never translated to an IP multicast group.
3. PG/PC interface selection in TIA Portal matters. If the PG/PC interface is bound to a physical NIC that has the VPN virtual adapter on a different routing table, DCP frames leaving the NIC never reach the remote subnet.

Diagnostic Procedure

Before applying any fix, run the following checklist. Each step takes < 60 seconds and eliminates a class of root causes.

Step 1 — Confirm Layer 3 reachability

Expected: replies with TTL > 0 and round-trip time consistent with the WAN link. If ping fails, fix routing, firewall ACLs, and VPN tunnel negotiation first. The HMS Networks support note "Why can't TIA Portal find my PLC?" states this ping-first rule explicitly.

Step 2 — Confirm S7 communication (Layer 4) using a non-discovery tool

Use one of the following to verify port 102 reaches the CPU:

• TestConnection from any PG/PC with a small S7 project already compiled against the target CPU.
• PRONETA (Siemens free diagnostics tool) — does not help over VPN for the same DCP reason, but its Network analysis tab can show MAC addresses if the VPN is bridged.
• tcping or psping to port 102 of the CPU.

Step 3 — Verify which PG/PC interface TIA Portal will use

Open Online > Online access > [interface] and confirm the bound NIC has a route to the remote subnet. On Windows, run:

The interface with the lowest metric to the remote subnet will receive the DCP frames. If the VPN virtual adapter is not the lowest-metric path, DCP requests will be sent on the wrong interface and never reach the remote PLC.

Step 4 — Capture DCP on both ends (advanced)

Run Wireshark on the engineering station and on the remote site (if you have a mirror port or a tap). Filter for the DCP multicast:

If you see DCP Identify Request frames leaving the PG but no Identify Response from the CPU, the VPN tunnel is dropping Layer 2 frames — confirming the root cause. If you see no DCP frames at all on the wire, the PG/PC interface selection or Windows firewall is the problem.

Solution 1: Direct PG/PC Interface Connection (Bypass Discovery)

The fastest fix when you already know the target CPU's IP address. This works on every TIA Portal version from V13 SP1 onward and is the supported workflow for remote engineering.

1. Open the TIA Portal project.
2. Navigate to Project tree > [CPU device] > Online & Diagnostics.
3. Set the PG/PC interface dropdown to the VPN virtual NIC (e.g., Intel(R) PRO/1000 MT Network Connection - VPN Tunnel or the TAP-Windows adapter).
4. Set Connection to interface/Subnet to the specific S7 subnet the CPU lives on, or select Directly at slot 'X' of the partner if the routing path is fixed.
5. Click Go online (Ctrl+Alt+O in TIA V16+, or the lightning-bolt icon in the toolbar).
6. Select the target CPU from the list (TIA will show Accessible target stations even when broadcast discovery fails, as long as S7 routing through the project is configured).

Solution 2: Configure Static S7 Routing in the Project

For projects with multiple CPUs across multiple subnets reachable through the VPN, configure S7 routing manually in the project. This avoids any discovery traffic entirely.

1. Open Devices & networks > Network view.
2. Right-click each CPU's PROFINET interface > Properties > PROFINET interface > Ethernet addresses.
3. Add the remote subnet as a Router entry with the next-hop IP (the VPN gateway address).
4. Save and compile the project.
5. Use Online > Accessible devices > [interface] with the appropriate subnet selected — TIA will then use the routed S7 path, not DCP discovery.

Solution 3: Deploy an Industrial VPN Gateway (Recommended for Permanent Installations)

For factory floors where multiple engineers need ongoing remote access, install a Siemens SCALANCE or compatible industrial VPN gateway at the remote site. These devices sit between the plant LAN and the WAN router and provide a managed, authenticated remote-access channel.

SINEMA Remote Connect is the Siemens-recommended platform for distributed machine builders. It establishes an OpenVPN-based tunnel between the SCALANCE gateway at the machine and a central SINEMA RC server. The engineering PG connects to the same SINEMA RC server; SINEMA then brokers the tunnel so the PG appears as if it is on the machine LAN. Because SINEMA uses a TCP-based OpenVPN, it is compatible with virtually any WAN — broadband, cellular, even NAT'd carrier networks — and DCP frames still will not flow natively, but the solution allows the engineer to use Online > Accessible devices > [SINEMA virtual NIC] against the SCALANCE virtual interface, where the SCALANCE acts as a PROFINET proxy or reflects DCP between the two tunnel endpoints.

Solution 4: Use a Layer 2 VPN (Site-to-Site Bridge)

When the network team is willing to configure it, an Ethernet over IP tunnel (also called L2VPN, EoIP, VXLAN, or EtherIP) will forward raw Ethernet frames — including DCP and LLDP — across the WAN. This is the only configuration in which the TIA Portal scan behaves identically to a local connection.

• MikroTik EoIP + IPSec: common low-cost option. The MikroTik site lists the EoIP protocol at help.mikrotik.com/docs/display/ROS/EoIP.
• Cisco OTv (Overlay Transport Virtualization): supported on Catalyst 9000 switches with DNA license.
• VXLAN on supported switches (Arista, Cisco Nexus, HPE Aruba CX).
• WireGuard + bridge: possible but requires Linux endpoint at both ends and a routed bridge; rarely deployed in production.

MTU is the operational gotcha. DCP frames are small (~60 bytes), but once encapsulated they must fit inside the WAN path MTU. Set the tunnel MTU to 1400-1450 bytes to avoid fragmentation; verify with:

If you receive "Packet needs to be fragmented but DF set", lower the MTU by 10 bytes until the ping succeeds, then lock the tunnel MTU to that value.

Solution 5: Use a Third-Party Industrial Remote-Access Appliance

Several vendors sell industrial remote-access appliances purpose-built for PROFINET discovery across the WAN. Each presents a virtual PROFINET NIC to the engineering PG and proxies DCP/LLDP to the remote site.

Solution 6: Configure the VPN to Pass Multicast (Limited Usefulness)

Some enterprise VPN appliances can encapsulate IP multicast into GRE or have a "multicast over VPN" feature (Cisco DMVPN, Fortinet, Palo Alto). Even when enabled, this only helps if the engineering tool sends IP multicast — DCP sends Ethernet multicast, so this generally does not solve the TIA scan problem. Treat multicast-over-VPN as a low-yield configuration unless your network team has validated it end-to-end with Wireshark captures.

Common Pitfalls and Field Notes

Windows Firewall on the Engineering PG

The Windows Defender Firewall blocks outbound DCP/LLDP frames by default for non-domain networks. When the VPN virtual adapter is classified as Public, DCP is silently dropped. Fix by setting the VPN adapter profile to Private in Settings > Network & Internet > Properties, or by adding an explicit allow rule for %SystemRoot%\System32\svchost.exe on UDP 1740-1742 (LLDP) and the PROFINET IO-Base protocol.

Antivirus / EDR products

Some endpoint protection products (CrowdStrike, SentinelOne, Symantec Endpoint Protection) inspect raw Ethernet frames and quarantine multicast frames that match no application signature. Add an exception for the TIA Portal process (S7PCTIAO.exe and the Siemens automation executables in C:\Program Files\Siemens\Automation\).

Multiple NICs and metric conflicts

When the PG has wired Ethernet, Wi-Fi, and a VPN adapter, Windows selects the route with the lowest interface metric. To force DCP out the VPN adapter, run an administrative command prompt:

Then set all other interfaces to a higher metric. Verify with route print.

Split-tunnel VPN configurations

If the VPN is split-tunnel, only traffic destined for the corporate subnet is encrypted. Confirm the remote plant subnet is included in the tunneled route list on the VPN client. Symptom: ping fails partially, scan returns empty.

TIA Portal version compatibility

Older TIA Portal versions (V13, V14 SP1) handle the PG/PC interface dropdown differently from V16+. In V13/V14, the interface selection is global; in V16+ it is per-online-action. If your project is shared between engineers using different TIA versions, ensure the interface selection is reset for each session.

CPU firmware version and DCP support

S7-1200 CPUs require firmware V4.0 or later for full DCP support on PROFINET interface. S7-1500 CPUs from firmware V1.0 onward support DCP. Earlier ET 200S modules may need firmware updates to reply to Identify Request frames with the station-name index used by TIA V17+. Check the firmware compatibility list in the Siemens Industry Online Support portal.

Verification Procedure

1. From the engineering PG, confirm ping <PLC_IP> returns TTL > 0.
2. Open TIA Portal > Online > Accessible devices. With the VPN virtual NIC selected, the CPU should now appear within 5-10 seconds.
3. Click Go online. Confirm the project compiles online with the CPU and shows no "station differs from configured" alarms for the rack/slot.
4. Open Online & Diagnostics > Diagnostics. The buffer entries should be readable and the PROFINET interface should show OK.
5. Download a small change (e.g., a tag value) to confirm bidirectional S7 communication.
6. Run a 30-minute keep-alive test. Some VPNs drop idle TCP sessions; ensure the S7 keep-alive interval is set to < the VPN idle timeout.

Comparison of Solutions

Standards Reference

• PROFINET specification, IEC 61784-2 and IEC 61158 — defines DCP frame format and multicast MAC 01:0E:CF:00:00:00.
• IEEE 802.1AB-2016 — Link Layer Discovery Protocol (LLDP).
• ISO/IEC 8073 / RFC 1006 — ISO Transport over TCP, used for S7 communication on port 102.