Configuring SIMATIC Software on VMware Workstation with Dual NIC

Overview

Running SIMATIC engineering software — TIA Portal, STEP 7 V5.x, WinCC Professional, or Startdrive — inside a VMware Workstation virtual machine is the standard Siemens-recommended pattern for engineering workstations. The most common deployment is a developer who needs:

• Direct Layer-2 access to an S7-1200, S7-1500, ET 200, or SINAMICS drive on the plant LAN through the engineering port
• Simultaneous access to the corporate Wi-Fi for the SIMATIC license server, intranet documentation, and Windows / Siemens update channels

VMware Workstation Player 12.5.x (and the later 15.x, 16.x, and 17.x Player builds) does not ship with the Virtual Network Editor (VNE) GUI that Workstation Pro provides. Without VNE, the free Player only exposes a single "Automatic" bridged adapter, which means a second physical NIC on the host cannot be deterministically bridged to a second VM NIC. The fix described below keeps Player as the hypervisor while restoring VNE as a standalone application harvested from a Pro installer.

This reference covers the dual-NIC configuration pattern, VNE restoration, adapter binding order, and SIMATIC-specific firewall and routing adjustments required for a stable engineering VM.

Prerequisites

• Host OS: Windows 10 (1809 or later) or Windows 11 Pro/Enterprise, administrator account
• Hypervisor: VMware Workstation Player 12.5.x, 15.5.2, 16.x, or 17.x installed and licensed
• Pro installer (temporary): VMware Workstation Pro 12.x / 15.x / 16.x / 17.x media — required only to harvest the VNE files; a Pro license key is not needed to run the standalone VNE
• Two physical NICs on the host: one wired Ethernet (Intel I219 / I225 / Realtek RTL8111) for the plant network, one Wi-Fi (Intel AX200/AX210, Realtek RTL8852) for the office network
• Guest OS: Windows 10 LTSC 2019/2021 or Windows Server 2019/2022, fully patched
• SIMATIC software inside the guest: TIA Portal V15.1 / V16 / V17 / V18, STEP 7 V5.6 SP2, WinCC Professional V17, or Startdrive V17/V18
• License path: Automation License Manager (ALM) reachable via the Wi-Fi path on TCP 4410 (ALM) or 28020 (legacy floating license server)
• Plant network: Static or DHCP IPv4 in the same subnet as the PLC (e.g., 192.168.0.0/24 with the S7-1500 at 192.168.0.1)

Network Architecture: Bridged LAN + NAT Wi-Fi

Two patterns solve the dual-network problem inside a Workstation VM. Pick one — do not mix bridged and NAT on the same VMnet.

Pattern A is the engineering default: the plant LAN behaves as if the VM is a physical device on that switch, while the office Wi-Fi is reached through VMware's NAT engine (the VMware DHCP Service assigns a 192.168.x.0/24 address to the guest NIC). License-server traffic stays on the NAT path, so the plant firewall does not need to permit licensing ports.

Restoring the Virtual Network Editor (Standalone)

VMware Workstation Player excludes VNE from the installation. The accepted workaround preserves the Player install while restoring VNE by extracting the relevant files from a Pro installer. This procedure is well-documented in the VMware community KB and works across Player 12 through 17.

1. Download the matching VMware Workstation Pro installer (e.g., VMware-workstation-full-17.5.2-23775571.exe) to C:\Temp\VNE. You do not need a Pro license.
2. Run the Pro installer normally and complete the install. Accept the EULA; do not enter a license key.
3. Copy the entire Pro install folder (default: C:\Program Files (x86)\VMware\VMware Workstation\) to a safe location such as D:\Tools\VNE\ or back to C:\Temp\VNE\. Required files: vmnetui.dll, vmnetcfg.exe (legacy), vnetlib.exe, vmnetbridge.dll, and the x64 subfolder.
4. Open Programs and Features, uninstall "VMware Workstation Pro".
5. Re-install VMware Workstation Player (the original) over the top, or repair the existing Player install.
6. Verify the standalone VNE launches by running the following from an elevated command prompt:

rundll32.exe vmnetui.dll VMNetUI_ShowStandalone

The VNE dialog opens in standalone mode. If the file is not in the system PATH, use a full path:

rundll32.exe "D:\Tools\VNE\vmnetui.dll" VMNetUI_ShowStandalone

Step-by-Step Dual-NIC Configuration

1. Configure VMnet0 as a Bridged Adapter

1. Launch VNE as administrator: rundll32.exe vmnetui.dll VMNetUI_ShowStandalone
2. Select VMnet0 from the list. Set "Type" to Bridged.
3. Uncheck "Bridged to: Automatic". Click the dropdown and select the host's wired Ethernet adapter (e.g., "Intel Ethernet Connection I225-V").
4. Click Apply. VMnet0 is now bound exclusively to the plant NIC.

2. Leave VMnet1 (Host-Only) Unchanged

VMnet1 is host-only by default and is not used for plant or office traffic. Leave it at its 192.168.x.0/24 default unless you have a deliberate host-only network.

3. Verify VMnet8 NAT Settings

1. Select VMnet8. Confirm Type = NAT.
2. Click NAT Settings. The default gateway is typically 192.168.81.2 with subnet 192.168.81.0/24. The guest's second NIC will receive an address from this range via the VMware DHCP service.
3. Click DHCP Settings. Confirm the lease range is enabled (default: 192.168.81.128 – 192.168.81.254).

4. Start the Required VMware Services

Player will normally autostart these, but after the Pro → Player swap, confirm they are running:

• VMware NAT Service — Service name VMnetNAT in older builds, VMware NAT Service in 16.x+
• VMware DHCP Service
• VMware Bridge Service (vmnetbridge) — needed for VMnet0 bridging
• VMware Authorization Service

Check from an elevated command prompt:

sc query VMnetDHCP && sc query VMAuthdService && sc query "VMware NAT Service"

5. Edit the Guest VMX to Add a Second NIC

Shut down the guest. Open the .vmx file in a text editor and confirm two Ethernet entries exist. If only one is present, add the second:

ethernet0.present = "TRUE"
ethernet0.connectionType = "custom"
ethernet0.vnet = "VMnet0"
ethernet0.virtualDev = "e1000"
ethernet0.addressType = "static"
ethernet0.address = "00:0C:29:11:22:33"

ethernet1.present = "TRUE"
ethernet1.connectionType = "custom"
ethernet1.vnet = "VMnet8"
ethernet1.virtualDev = "e1000"
ethernet1.addressType = "generated"

Set ethernet0.connectionType = "bridged" only if you want Player to auto-pick the wired NIC. "custom" with VMnet0 bound in VNE is the deterministic choice for production engineering stations.

6. Bring Both NICs Up in the Guest

1. Boot the guest. Open Device Manager → Network Adapters; you should see two VMware Accelerated AMD PCNet Adapter or Intel E1000 devices.
2. Open ncpa.cpl. Identify the bridged NIC (VMnet0) and the NAT NIC (VMnet8). The bridged NIC can be renamed "Plant LAN" and the NAT NIC "Office / License".
3. On the Plant LAN adapter, assign a static IP in the PLC subnet (e.g., 192.168.0.10 / 255.255.255.0, no gateway, no DNS). Leaving the gateway blank forces all non-plant traffic onto the NAT NIC.
4. On the Office NIC, leave DHCP enabled. VMware NAT will assign 192.168.81.x automatically; the gateway is 192.168.81.2.

7. Fix Windows Network Binding Order

Windows can route office traffic through the bridged NIC if the binding order is wrong. Force the NAT NIC to be the primary route:

1. Run ncpa.cpl → Alt+N → Advanced → Advanced Settings.
2. In Adapters and Bindings → Connections, move "Office / License" above "Plant LAN".
3. Confirm with route print: the 0.0.0.0/0 default route should point at 192.168.81.2 (NAT gateway), not the plant subnet.

SIMATIC-Specific Configuration

TIA Portal Project Transfer

TIA Portal uses the PG/PC interface to talk to the PLC. With two NICs, the interface selection in TIA Portal → Options → Set PG/PC Interface must be set to the bridged NIC's TCP/IP stack:

• Select Intel(R) Ethernet ... TCP/IP -> Auto on the Plant LAN adapter
• Avoid the VMware Accelerated AMD PCNet Adapter selection — that points to the NAT path and will fail to discover PROFINET devices
• For S7-1500, ensure the CPU's PROFINET interface [X1] has a configured IP in the same subnet as the bridged NIC (e.g., 192.168.0.1 / 24)

Automation License Manager (ALM) Path

ALM 6.0+ (shipped with TIA V16 and later) communicates with floating license servers on TCP 4410. From the guest's NAT NIC this traffic leaves through the host's Wi-Fi. Verify:

telnet license-server.corp.local 4410

If the host Wi-Fi is not in the same domain as the ALM server, the guest's NAT path will translate the source IP to the host's Wi-Fi IP. The license server must therefore permit the host's Wi-Fi MAC/IP. Most corporate policies allow this for engineering laptops.

STEP 7 V5.6 and S7-300 / S7-400

STEP 7 V5.6 SP2 is supported inside VMware per the SI-VaaS reference. Use the same Set PG/PC Interface pattern, but select the ISO protocol on the bridged NIC:

• PC internal (local) — do not use for plant traffic
• TCP/IP (Auto) — bridged NIC for S7-1200/1500 via TIA
• ISO Ind. Ethernet — bridged NIC for S7-300/400 with CP cards (older installations)

HMI Panels and WinCC Runtime

If the engineering VM is also used to download to a Comfort / Unified Panel over Ethernet, place the panel on the plant subnet (192.168.0.0/24). Transfer settings: IP 192.168.0.50 (example), TIA Portal's Transfer → Ethernet mode.

Firewall and Security Considerations

VMware Player installs three firewall rules in the host. Do not disable them:

• VMware Bridge Service — required for VMnet0 bridging
• vmnetdhcp.exe inbound — required for guest DHCP on VMnet8
• vmnetnat.exe inbound/outbound — required for NAT translation

On the guest, the Windows Defender firewall is sufficient. Open only TCP 102 (ISO-TSAP) and TCP 4410 (ALM) inbound for TIA. Disable any third-party firewall from interfering with VMnet0 bridged traffic — this is a common cause of "TIA Portal cannot reach the PLC" with all other settings correct.

Verification Procedure

1. From the guest, ping the plant CPU: ping 192.168.0.1 — must succeed from the bridged NIC
2. From the guest, ping the corporate gateway through the NAT path: ping 8.8.8.8 — must succeed
3. From the guest, resolve an intranet name: nslookup license-server.corp.local — must return the ALM server IP
4. Open ALM: confirm the floating license is visible in the ALM Search dialog
5. Open TIA Portal: Online → Accessible Devices — the S7-1500 must appear with its plant IP and PROFINET device name
6. Download the project to the CPU and confirm the run/stop transition completes in < 5 s for a typical S7-1500 program
7. Trigger a live watch on a tag (e.g., "DB1"."Motor_Speed) and confirm the value updates at the TIA default scan rate (250 ms)

Troubleshooting Matrix

Performance and Tuning Notes

• Adapter type: Use the Intel E1000 virtual NIC (ethernet0.virtualDev = "e1000") on the bridged side. The default AMD PCNet adapter does not support large L2 frames, which can degrade S7-1500 download throughput by 30–40% on large projects.
• MTU: For S7-1500 firmware V2.9+ you can raise the bridged adapter's MTU to 1500 (default) or keep it 1500; the PLC negotiates 1500 on PROFINET. Do not set jumbo frames on the VMnet side.
• CPU pinning: In .vmx, set sched.mem.pshare.enable = "FALSE" for engineering VMs that download large projects — it prevents TIA's compile step from thrashing across host cores.
• Snapshot policy: Do not snapshot the VM while a project download is in progress. Rolling back to a snapshot with a different bridged MAC can break PROFINET device name assignment.

FAQ