The VM boots fine, Windows loads, and then nothing — no browsing, no updates, no network at all. Meanwhile the host it’s running on is online without a hitch. It’s one of the most common Hyper-V annoyances, and almost every case comes down to a handful of points along the path from the guest out to the internet.
That path has more links than people expect: the VM’s network adapter, the virtual switch it’s attached to, how that switch reaches the physical network, the host’s firewall, and finally DNS inside the guest. Break any one and the symptom looks the same. This guide walks them in the order that finds the fault fastest, so you’re not guessing.
How a VM reaches the internet
Before changing anything, it helps to picture the chain. A packet leaving your VM travels:
guest network adapter → virtual switch → (external NIC or host NAT) → your router → internet.
If the switch is a private or internal type, that chain is cut before it ever reaches the physical network — which is the single most common reason a VM has no internet. So that’s where to start.
Cause 1: The VM is on the wrong switch type
A VM attached to a private switch can only talk to other VMs. On an internal switch it reaches the host but not the wider network. Neither gives internet access on its own. For a guest to get online you need an external switch or the Default Switch (which uses NAT).
Check what the VM is using. In Hyper-V Manager, open the VM’s Settings → Network Adapter and look at the Virtual switch dropdown. Or from PowerShell:
Get-VMNetworkAdapter -VMName "MyVM" | Format-Table VMName, SwitchName, IPAddresses
Get-VMSwitch | Format-Table Name, SwitchTypeIf SwitchName points at a private or internal switch, that’s your problem. Repoint the VM at
an external switch or the Default Switch:
Connect-VMNetworkAdapter -VMName "MyVM" -SwitchName "Default Switch"If you don’t have an external switch yet, building one is a short job — see how to create an external virtual switch in Hyper-V. An external switch puts the VM straight on your LAN with its own DHCP address, which is the most reliable way to get it online.
Cause 2: The Default Switch has stopped handing out addresses
The Default Switch is convenient — it’s NAT, it needs no setup, and it survives network changes
on a laptop. But it’s rebuilt at every boot, and after some Windows feature updates it comes
back broken: VMs attach to it but never get an IP, or get a 169.254.x.x self-assigned address
that goes nowhere.
When that happens, try these in order:
- Restart the host. The Default Switch is recreated and often comes back healthy.
- If a reboot doesn’t help, restart the management service from an elevated prompt:
Restart-Service vmms- Confirm the VM picked up a real address afterward:
Get-VMNetworkAdapter -VMName "MyVM" | Select-Object VMName, IPAddressesIf the Default Switch keeps failing, stop fighting it. Build your own external or NAT switch that you control, and the problem stops recurring.
Cause 3: Set up a NAT switch you control
A NAT switch gives you the convenience of the Default Switch without its instability, because you define the subnet and it doesn’t get rebuilt behind your back. The catch: Hyper-V only supports one NAT network per host, so plan the subnet once.
Create an internal switch, give the host virtual adapter a gateway address, then attach a NAT network to that subnet:
# 1. Create an internal switch
New-VMSwitch -SwitchName "NAT-Switch" -SwitchType Internal
# 2. Find the new host adapter's ifIndex
Get-NetAdapter | Where-Object Name -like "*NAT-Switch*"
# 3. Assign the gateway IP to that host adapter (use its ifIndex)
New-NetIPAddress -IPAddress 192.168.50.1 -PrefixLength 24 -InterfaceIndex <ifIndex>
# 4. Create the NAT network on that subnet
New-NetNat -Name "NAT-Network" -InternalIPInterfaceAddressPrefix 192.168.50.0/24Then point your VM at NAT-Switch, and inside the guest set a static IP in that range with the
gateway as the default route:
In-guest settings for the NAT subnet above
| IP address | 192.168.50.10 (any free address in the range) |
|---|---|
| Subnet mask | 255.255.255.0 (/24) |
| Default gateway | 192.168.50.1 (the host adapter) |
| DNS server | Your router, or a public resolver like 1.1.1.1 / 8.8.8.8 |
Cause 4: The VM’s own network adapter
Sometimes the switch is fine and the guest’s adapter is the issue. Two things to check inside the VM:
- The adapter is disabled or unplugged. In the guest, open Network Connections and confirm the adapter is enabled. In the VM settings, make sure a network adapter actually exists and is connected to a switch.
- Generation 2 VMs and Secure Boot. Gen 2 VMs use a synthetic adapter that works out of the box for Windows and modern Linux. Some older or minimal Linux guests need the right driver or a legacy adapter. If a Linux VM sees no NIC at all, that’s the likely cause.
A quick way to rule the guest in or out: inside the VM, check whether the adapter even has a link and an address:
ipconfig /allNo adapter listed means a VM-config or driver problem. An adapter with 169.254.x.x means it’s
connected but getting no DHCP — back to the switch and DHCP path.
Cause 5: The host firewall or security software
On a NAT or Default Switch setup, the host forwards the VM’s traffic. That means a strict host firewall profile or a third-party security suite can quietly drop the forwarded packets even though the host’s own browsing works.
To test, temporarily relax the host’s firewall or the security product’s network filtering and re-check the VM. If that restores connectivity, add a rule rather than leaving protection off. Don’t forget the guest has its own firewall too — confirm outbound traffic isn’t blocked inside the VM.
Cause 6: DNS inside the VM
This is the case that fools people, because the VM looks connected. It has an IP, it can ping 8.8.8.8, but the browser still says it can’t find anything. That’s DNS — the VM has a route to
the internet but no way to turn names into addresses.
Inside the guest, check and fix the resolver:
# See current DNS servers
Get-DnsClientServerAddress
# Set a working resolver (example uses Cloudflare + Google)
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","8.8.8.8")
# Clear any stale cached lookups
ipconfig /flushdnsThen test name resolution directly:
nslookup microsoft.comIf nslookup returns an address but the browser still struggles, the route is fine and DNS is
fixed — recheck a proxy or local hosts-file entry.
The fast path
When a Hyper-V VM has no internet and you just want it working:
Connectivity troubleshooting order
- Inside the VM: ping 8.8.8.8 and ping google.com to split routing from DNS
- Confirm the VM is on an external or Default Switch, not private/internal
- If using the Default Switch, reboot the host or restart the vmms service
- Check the VM has a real IP (not 169.254.x.x) with ipconfig /all
- Relax the host firewall/security software briefly to test forwarded traffic
- If the IP works but names don't, set a working DNS server and flush the cache
Most cases are solved by step 2 or step 6. The switch type accounts for the dead-silent VMs; DNS accounts for the “connected but can’t browse” ones.
If the trouble started after you added another hypervisor to the same machine, the conflict may be lower down the stack — see the virtualization guides and the VirtualBox VT-x and Hyper-V conflict for how Windows hypervisors fight over the CPU and, sometimes, the network bindings.
Wrapping up
A Hyper-V VM with no internet is rarely mysterious once you follow the path. Start at the virtual switch, because a private or internal switch will never reach the network. Make sure the guest has a real IP, give it a NAT or external switch you control instead of relying on a flaky Default Switch, clear the host firewall as a suspect, and finish at DNS for the “has an address but can’t browse” cases.
Run the ping 8.8.8.8 then ping google.com test first every time. It tells you in two
commands whether you’re chasing routing or name resolution, and that decides everything else.
