Does a Hyper-V VM Use the Host VPN? It Depends on the Switch

Install a VPN client on the Hyper-V host, open a browser there, and the exit address changes; open the same page inside the VM and it may show the old address, or nothing at all. The usual conclusion is that the VM is broken, or that split tunneling must be enabled. Neither follows. A VPN client is not a property of the machine; it is a set of routes, a virtual adapter and often a filter attached to specific interfaces. Whether guest traffic ever meets that machinery depends on the virtual switch the guest uses.

The myth, stated plainly

The belief is that a VPN installed on the host protects the whole machine, VMs included, because a VM is just a process running on that machine. It is a comfortable belief, since antivirus and host firewalls usually do behave that way. Network paths do not.

A guest's frame is only touched by the host's VPN stack if the host routes or filters it. Copy that sentence onto a sticky note, because every case below is a variation of it.

Three switch types, three paths

An external switch binds a virtual adapter to a physical NIC, and the guest sends frames through that binding with its own MAC address. The guest becomes a peer on the physical network, with its own DHCP lease, gateway and DNS servers. The host's VPN default route lives on the host stack and does not move those frames, because they are bridged rather than routed through the host. This is also why an external switch over a Wi-Fi adapter is a poor idea: most wireless drivers will not carry frames for a second MAC address.

An internal switch connects guests to a host virtual adapter. On its own it provides no internet exit; a NAT object on the host supplies translation, as described in the Hyper-V NAT guide. Now the guest's packets do enter the host's routing and NAT path, so the VPN client's routes and filters matter again. This is the arrangement where the VM really does follow the host VPN, and where a kill switch can cut the guest off entirely.

A private switch has no host adapter and no uplink. Guests talk to each other and to nothing else, so if a VM on a private switch has no internet, the missing router is the cause and the VPN is irrelevant.

The Default Switch is its own arrangement

Windows ships a Default Switch that combines an internal switch with NAT and a DNS proxy. Its subnet is picked by the host, can change after restarts, and is not the same object as a NAT network you create yourself. Rebuilding it as if it were a lab network is how people end up with two NATs and a guest that still has no route.

If the VM sits on the Default Switch, read the address the guest received and compare it with the host's NAT table before touching the VPN client. A mismatch between the guest's gateway and the NAT prefix explains more failures than any client setting.

Four facts that settle the question

Collect these before changing anything: the switch type and its uplink, the adapter attached to the VM, the guest's own address, gateway and DNS, and the host's NAT and default-route state. The read-only commands are Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, and Get-NetRoute -DestinationPrefix 0.0.0.0/0; inside the guest, ipconfig /all gives the rest.

Then decide what the guest is supposed to do. If it should stay outside the VPN, obtain the provider's supported exception for that exact path, because excluding a host executable does not exempt forwarded VM traffic. If it should use the VPN, confirm the client's documented handling of VM traffic instead of assuming a host browser test covers it.

A test inside the guest is the only evidence that counts. Check the exit address from the guest, resolve an internal name, reconnect the VPN and repeat. The host's browser result is not a proxy for any of that.

What the myth costs

People disable the kill switch, add static routes, or delete and recreate switches just to make a test pass. Each shortcut changes the failure mode: the guest may reach the internet through a path nobody intended, or the host may lose connectivity when an external switch rebinds its physical adapter.

Rebinding an external switch interrupts the host's own access, so keep an out-of-band path open and avoid deleting switches while you are still diagnosing. The correct outcome is the intended guest path, including how it reconnects and how it fails, not a green checkmark from one page load.

The durable answer is one line per VM in the inventory: which switch it uses and which component supplies its gateway. With that written down, the next VPN change is a lookup instead of an afternoon of guessing.