Hyper-V Guest Loses DNS When the Host VPN Connects

The guest was fine this morning. Then the host brought up Cisco AnyConnect and the VM lost DNS, its domain trust and the shared folder, with nothing changed inside it. A host tunnel and a guest network are separate paths, and connecting one does not move the other. Work from inside the guest outward, and write down what you see before changing anything.

What the guest can still see

Record the address, the default gateway and the resolver in the VM, once before the host connects and once after. A guest that kept its address and lost only name resolution has a resolver problem. A guest that never had a route has a path problem, and the two need different work. From the host you cannot tell them apart, which is why the reading has to come from inside.

Those three readings, taken twice, are your baseline. Everything later is measured against them.

Which exit the guest is using

Hyper-V answers this with two commands: Get-VMSwitch lists the switches, and Get-VMNetworkAdapter -VMName TestVM shows the one the guest is attached to. The Default Switch is a NAT network that Windows manages; an external switch hands traffic to a physical adapter; an internal switch carries nothing until someone adds NAT or a router. VirtualBox presents the same three ideas as NAT, NAT Network and bridged.

The mode decides whether the host tunnel can matter at all. A NAT guest is translated by WinNAT and then forwarded by the host stack, so it follows the host route table; with a full-tunnel client its traffic is the traffic that enters the VPN adapter, and it is dropped when the client blocks the local subnet. A bridged guest on an external switch never reaches host routing at all: its frames leave the physical NIC directly, so it bypasses both the tunnel and the client local-LAN policy.

Sharing the host tunnel with Hyper-V

If the guest needs the tunnel and cannot run its own client, Windows can share the VPN connection. Open the VPN adapter's properties, go to Sharing, and allow other network users to connect through it. Point the home networking connection at the Hyper-V adapter, vEthernet (Default Switch), then test a fresh request from inside the guest.

Treat the arrangement as a lab fix, because it behaves like one. It has to be reapplied after a disconnect, a reconnect or a host reboot. On some Windows 11 builds the adapter is missing from the drop-down entirely, and then this route is closed.

Reinstalling the Hyper-V feature has rescued a few stubborn guests. Save that for last, and note the guest state first.

Port forwarding when the subnet is filtered

A host VPN that filters the guest NAT subnet breaks direct access rather than name resolution. The VM is running, yet ssh [email protected] hangs, while the hypervisor translation is still working. Forward the ports the work needs and connect to the host address instead. The Vagrantfile lines below cover SSH and one HTTPS service; both go in before the reload.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

Name resolution is a separate decision and deserves its own fix. Turn on the host resolver feature for that NAT adapter, or configure the internal DNS server inside the guest by hand. Pointing the guest at a public resolver makes browsing work and breaks every internal name, which is worse than the outage because it looks like success. Test a name that only the internal resolver knows.

The check that tells you it worked

After any of these changes, run a fresh request from inside the guest with the host VPN connected, not before it. Re-check the sharing after a reconnect and after a reboot, because a fix that survives only one of those is not a fix. Confirm that the guest resolver list matches the network its traffic really uses. Then test port forwarding from the host address, since testing it from the guest proves nothing. From inside the guest, two PowerShell checks cover the resolver and the forwarded port:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Record each switch or driver change with its undo step. The Microsoft Hyper-V NAT guide explains what the Default Switch actually is, and it is worth reading before you create a second NAT network that conflicts with it.