Hyper‑V external virtual switch bound to Wi‑Fi stops forwarding traffic after Windows 11 host resumes from sleep

Environment

Windows 11 Pro host running Hyper‑V; external Virtual Switch is bound to the laptop's Intel AX Wi‑Fi adapter; VMs use the external switch to obtain LAN access; host frequently sleeps/resumes.

Symptoms

After the host resumes from sleep, the Windows host regains internet access but Hyper‑V VMs cannot reach LAN or internet. VM NICs show as connected but traffic fails. Restarting the individual VM does not help; rebooting the host or restarting host networking services restores connectivity.

Observations

Event Viewer logs show the physical Wi‑Fi adapter driver reinitializing on resume. 'Get-NetAdapter' before sleep and after resume shows the adapter gets a new InterfaceIndex/ifAlias. The vEthernet adapter exists but packets from VMs do not appear on the physical interface (verified with Get-NetAdapterStatistics and netsh). Restarting 'Hyper‑V Virtual Machine Management' service temporarily restores forwarding without a full reboot in some tests.

Already attempted

Updated Wi‑Fi driver, disabled 'Allow the computer to turn off this device to save power' in Device Manager, toggled 'Allow management operating system to share this network adapter', created a new external switch bound to the same adapter (worked until next suspend), and tested with a wired Ethernet external switch (no issue).

Question

Why does Hyper‑V stop forwarding VM traffic over a Wi‑Fi adapter after resume, and what safe, reversible steps can I take to restore connectivity automatically without rebooting the host each time?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Wi‑Fi driver reinitializes on resume, changing adapter identity and breaking Hyper‑V vSwitch binding. 90%

Hyper‑V virtual switch binding code does not auto-rebind to a new adapter instance after driver reattachment. 90%

Wireless adapters do not fully support NDIS features Hyper‑V expects across power cycles, causing vSwitch binding loss. 75%

Summary

Wireless NIC drivers commonly reinitialize on suspend/resume and may present a new underlying adapter instance (new GUID/InterfaceIndex). Hyper‑V external switches are bound to the specific adapter instance; when the driver recreates the adapter, the binding becomes stale and the vSwitch no longer forwards traffic. Wired adapters tend to behave more stably across suspend/resume. This is a host-level binding issue rather than VM network stack fault.

Suggested Fixes

Diagnostic step 1

Collect adapter state before and after suspend: run 'Get-NetAdapter | Format-Table -Auto' and save output to compare InterfaceIndex, GUID and ifAlias; this will document whether the driver re-created the adapter.

Diagnostic step 2

Workaround: create a small PowerShell resume script that rebinds the vSwitch to the physical adapter using 'Remove-VMSwitch -Name "External"' followed by 'New-VMSwitch -Name "External" -NetAdapterName "Wi‑Fi" -AllowManagementOS $true' (disruptive to VMs while rebind runs — test during maintenance).

Diagnostic step 3

Less disruptive: restart the 'Hyper‑V Virtual Machine Management' service after resume (reversible and faster than full reboot): 'Restart-Service vmms' (note that stopping this service may briefly stop VM management but usually preserves running VMs).