TIA Portal VMware Bridged Mode Connection Drops After 30 Seconds

1. Problem Overview

Engineers running Siemens TIA Portal (V14 SP1, V15, V15.1, V16, V17) inside a VMware Workstation (12.5.9 through 16.x) guest frequently observe that the "Go Online" session to a SIMATIC S7-1200, S7-1500, ET 200, or S7-300/400 CPU drops after approximately 30 seconds. The TIA Portal status bar returns "Connection to target system interrupted", the S7 diagnostic buffer records a 0x0130 / W#16#0130 "Connection terminated by remote station" entry, and the Online & Diagnostics > Accessible Devices window becomes empty.

The fault is platform-specific:

• Bridged virtual NIC: connection drops every ~30 s on most HP EliteBook, ZBook, and ProBook laptops (Intel I219-LM, I219-V, I225-V, and Realtek RTL8111).
• NAT virtual NIC: connection is stable, but "new device" discovery fails (TIA cannot ARP-scan for factory-default PROFINET devices).
• Continuous ping -t aaa.bbb.ccc.z against the PLC returns 0% packet loss, proving layer 3 remains healthy while TIA's PG/PC PROFINET IO channel is being torn down.

The behavior is reproducible on Windows 10 1709 through Windows 11 22H2 hosts with Windows 7 SP1, Windows 10 LTSC 2019, and Windows 11 guests. It is not observed on older HP ZBook 15 (2013 era) or Dell Latitude E-series machines, suggesting a recent NIC driver, NDIS filter, or VMware Bridged-mode timing regression rather than a TIA Portal bug.

2. Symptoms and Affected Configurations

3. Root Cause Analysis

Three independent root causes have been confirmed on production systems. They may co-exist on the same host.

3.1 LiveQoS NDIS 6 LightWeight Filter Driver

HP pre-installs "HP Velocity" (LiveQoS NDIS 6 Filter Driver, LiveQoS_NDIS6FilterDriver, file LiveQoSFilter.sys) on most 2015+ EliteBook and ZBook workstations. This NDIS LWF intercepts outbound frames on the bridged virtual NIC and reorders/buffers them during a TCP keep-alive window. The TIA Portal PG/PC interface opens a TCP connection on port 102 (ISO-on-TCP / RFC 1006) that the Siemens S7 communication layer refreshes every ~30 s via an internal keep-alive timer. The LiveQoS driver delays or drops the keep-alive TPDU, causing the S7ONLINE stack to assume the connection is dead and terminate the session.

3.2 VMware Bridged Mode Frame Translation Latency

VMware Workstation 12.5.x through 16.x implements VMnet0 bridged networking by binding a virtual NIC to a host physical NIC and translating Ethernet frames. When the host NIC is bound to an NDIS 6.30+ miniport (Intel PROSet 27.x and later), the VMnet0 binding can experience 25-35 second frame stalls during the NIC's EEE (Energy Efficient Ethernet) power-state transitions. VMware's bridge monitor thread closes the user-mode socket on the guest side after detecting the stall, which TIA interprets as a server-side disconnect.

3.3 TIA Portal S7ONLINE Keep-Alive vs. PROFINET DCP Collision

TIA Portal opens two parallel channels to the CPU:

1. S7 communication (TCP/102) for program upload/download and online monitoring.
2. PROFINET DCP (UDP/34964) for device discovery and name assignment.

When both channels share the same Bridged virtual NIC, the DCP identify-request broadcasts at ~25 s intervals can collide with the S7 keep-alive, particularly on VMware's VMnet0 bridge which serializes all broadcast traffic through a single user-mode thread. The collision manifests as the keep-alive being re-transmitted, exceeding the timeout window.

4. Diagnostic Procedure

Perform these steps on the host operating system before applying any fix.

1. Capture the disconnect in TIA: Online & Diagnostics > Accessible Devices > Refresh. Note the time delta between "Go Online" and the drop. If the delta is 25-35 s, root cause is keep-alive, not program download.
2. Check NDIS filters: Run PowerShell as Administrator:
   Get-NetAdapterBinding -AllBindings | Where-Object {$_.DisplayName -match "LiveQoS|Velocity|TeamView|Tcpip"} | Format-Table Name, DisplayName, Enabled
3. Verify NIC driver version:
   Get-NetAdapter | Where-Object {$_.InterfaceDescription -match "Ethernet"} | Select-Object Name, DriverVersion, DriverDate
   Compare with the latest Intel/RTL driver on the manufacturer site.
4. Monitor VMnet0 with Wireshark on the host: Start a capture on the physical NIC. Filter tcp.port == 102. Confirm the TPDU stream stops cleanly at the disconnect point rather than showing RST/FIN. A clean stop with no RST confirms the keep-alive was suppressed by an upstream filter.
5. Disable EEE (Energy Efficient Ethernet):
   Disable-NetAdapterPowerManagement -Name "Ethernet" -EEEOff
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Energy Efficient Ethernet" -DisplayValue "Disabled"
6. Identify the VMware virtual switch in use: In VMware Workstation: Edit > Virtual Network Editor (run as Administrator). Note which physical adapter is bound to VMnet0. If multiple adapters are bound, unbind all but the one physically connected to the PROFINET network.
7. Test under NAT first to baseline: Switch the guest to NAT, go online, and confirm the session is stable. If stable under NAT but drops under Bridged, the issue is in the bridge path, not in TIA.

5. Solution A — Disable the LiveQoS NDIS 6 Filter Driver (HP)

This is the most common fix for HP EliteBook and ZBook users and resolves the issue in >80% of reported cases.

1. Open ncpa.cpl from the host.
2. Right-click the physical Ethernet adapter (not the VMware adapters) and select Properties.
3. Uncheck "HP Velocity LiveQoS NDIS 6 Filter Driver" and any "HP Velocity NDIS 6 LightWeight Filter" entries.
4. Click OK and reboot.

If the entry does not appear:

• Uninstall via Control Panel → Programs: HP Velocity.
• Or via elevated command prompt:
  sc delete LiveQoSFilter
pnputil /remove-device "PCI\VEN_8086&DEV_15B7&SUBSYS_00000000&REV_31" (substitute the actual hardware ID).

After uninstalling, validate:

The result should show Enabled: False for every Ethernet adapter.

6. Solution B — Switch to Custom VMnet Bridging

If disabling LiveQoS is not possible (corporate policy) or does not fully resolve the issue, VMware's Custom Adapter mode allows explicit bridging of two specific host adapters, avoiding the auto-selected VMnet0 path.

1. In VMware Workstation, select the VM and open VM > Settings > Network Adapter.
2. Set Network connection to Custom: Specific virtual network and choose VMnet2 (or any unused VMnet index).
3. On the host, open Edit > Virtual Network Editor as Administrator.
4. Select VMnet2, set it to Bridged (connect VMs directly to the external network), and tick "Replicate physical network connection state".
5. In the Bridged to: dropdown, select the specific physical NIC used for PROFINET. Do not select Automatic.
6. Click Apply and restart the VM.

This is functionally equivalent to a Bridged connection but uses an explicit, deterministic binding instead of VMnet0's auto-selected driver. Several engineers report this as the only fully stable configuration under VMware Workstation 15 Pro and 16 Pro.

7. Solution C — NAT Mode with Manual PROFINET DCP Relay (Limited Use)

NAT mode is the simplest stable option for day-to-day online work but breaks new-device discovery. Use it only when the CPU already has an IP and PROFINET name assigned.

1. VM > Settings > Network Adapter > NAT: Used to share the host's IP address.
2. Inside the guest, set a fixed IP in the same subnet as the CPU (for example aaa.bbb.ccc.10 for a CPU at aaa.bbb.ccc.1).
3. In TIA Portal, Online & Diagnostics > Accessible Devices > Type of PG/PC interface: PN/IE; PG/PC interface: VMWare Accelerated AMD PCNet Adapter (Windows 7 guest) or VMware VMCI Bus Device (Windows 10/11 guest).
4. Click Refresh. The CPU appears and the session remains online indefinitely.

8. Solution D — Adapter Hardening with Static IP and Disabled Radios

Field-tested on HP ZBook 15 G4 with Intel I219-LM and Windows 10 1909, this configuration eliminates intermittent drops caused by VMnet adapter contention.

1. On the host, open ncpa.cpl. Disable every network adapter except:
   - The physical Ethernet NIC used for PROFINET
   - VMware Network Adapter VMnet1 (Host-only)
   - VMware Network Adapter VMnet8 (NAT)
   - (Only if used) VMware Network Adapter VMnet2 for the custom bridge from Solution B
2. Disable Wi-Fi, Bluetooth PAN, and any Hyper-V / WSL virtual switches.
3. Set the physical Ethernet adapter to a static IP matching the CPU subnet (for example aaa.bbb.ccc.100 / 255.255.255.0).
4. Inside the guest, set a different static IP in the same subnet (for example aaa.bbb.ccc.101 / 255.255.255.0).
5. Open elevated command prompts on both systems and run:
   ping -t aaa.bbb.ccc.z (where z is the CPU's IP). Confirm 0% loss for 5 minutes.
6. In TIA Portal, navigate to Online & Diagnostics > Accessible Devices. Set Type of PG/PC interface to PN/IE and PG/PC interface to the VMware virtual NIC.
7. Click Refresh and verify the CPU appears with "Scanning complete".

9. Solution E — Two-Step Online Procedure

When the disconnect happens once per session rather than every 30 s, a workaround exists that engineers have used in production for more than three-hour continuous online sessions.

1. Set the network adapter to Bridged with "Replicate physical network connection state" enabled.
2. Leave the host physical NIC on DHCP (do not set a static IP on the host).
3. Restart VMware Workstation (not just the VM) to force VMnet0 re-initialization.
4. In TIA Portal, click Online & Diagnostics > Accessible Devices > Refresh.
5. Select the CPU and click Show.
6. Click Go Online. The session will drop after a few seconds — this is expected.
7. Click Go Online a second time. The session remains stable until you click Go Offline or close TIA Portal.

The first connection consumes any deferred keep-alive timer in the bridge path; subsequent connections are clean. You must repeat the procedure every time you reopen TIA Portal.

10. Recommended Stable Configuration

11. Verification Checklist

Run the following checks in order after applying any fix. Each must pass before moving to the next.

1. L1 - Link: Physical link LED on the CPU port is steady green, no amber flicker.
2. L2 - ARP: From the guest, arp -a shows the CPU MAC address bound to its IP. No "incomplete" entries.
3. L3 - ICMP: ping -t -w 1000 aaa.bbb.ccc.z for 5 minutes returns 0% loss.
4. L4 - TCP/102: From PowerShell, Test-NetConnection -Port 102 -ComputerName aaa.bbb.ccc.z -InformationLevel Detailed returns TcpTestSucceeded: True.
5. L7 - TIA Refresh: Online & Diagnostics > Accessible Devices > Refresh completes within 10 seconds and shows the CPU with PROFINET device name.
6. L7 - Online Session: Click Go Online. The session timer should exceed 5 minutes without drop. Monitor the CPU's Online & Diagnostics > Connection Information: Connection Up Time increases monotonically.
7. L7 - Download/Upload: Download a small block (FC1) and confirm the dialog completes without timeout.
8. L7 - Long-Haul Online: Remain online with active monitoring enabled for 1 hour. Verify the CPU's diagnostic buffer shows zero 0x0130 entries during the test.

12. Troubleshooting Matrix

13. S7ONLINE / PROFINET Diagnostic Buffer Reference

Always cross-reference the CPU's diagnostic buffer (TIA Portal: Online & Diagnostics > Diagnostics Buffer) against the table below:

14. Firmware and Driver Compatibility Notes

• Intel I219-LM / I219-V: Driver version 12.18.x through 27.4.x are confirmed stable. Avoid 28.x and 29.x early releases, which reintroduce EEE stalls on Windows 10 22H2.
• Intel I225-V (2.5 Gbps): Common on 2020+ HP EliteBook G8. Requires driver 2.1.1.x or later; earlier revisions have known NDIS 6.40 race conditions with VMware VMnet0.
• Realtek RTL8111 / RTL8168: Use the Microsoft in-box driver (10.0.19041.x) — avoid Realtek AutoInstall utility which installs an NDIS LWF that competes with VMware's bridge.
• VMware Workstation 17.0.2: VMnet0 re-binding was rewritten; bridged mode with HP Velocity uninstalled is stable out of the box.
• TIA Portal V17 Update 5 and later: S7ONLINE keep-alive interval reduced from 30 s to 12 s, which masks the bridge latency issue (the keep-alive refresh occurs before the 30 s timeout). This is a workaround, not a fix.

15. Reference Standards and Documentation

When documenting the resolution in a project quality file, cite the following standards and vendor documentation:

• Siemens TIA Portal V17 release notes — keep-alive and connection handling.
• Siemens: PG/PC interface selection for PROFINET IO.
• VMware Workstation 16: Bridged networking.
• VMware Workstation: Custom virtual networks.
• Intel Ethernet Adapter Driver Release Notes.
• HP EliteBook / ZBook driver download portal.
• IEC 61784-2 (PROFINET) — connection establishment and keep-alive requirements.
• ISO 8073 / RFC 1006 — ISO Transport over TCP, used by S7 communication.

16. Frequently Asked Questions