Networking Options for Hyper-V Virtual Machines in Windows 11

Hyper-V networking is easier to configure when you decide which connections the guest actually needs. A VM may need ordinary outbound internet access, its own presence on the physical LAN, communication with the host, or a network shared only with other VMs. These are different requirements.

What Each Switch Type Connects

• External: connects VM adapters to a selected physical network adapter and its network. The host can also share that adapter when the management-OS sharing option is enabled.
• Internal: connects VMs on the switch to each other and to a virtual network adapter on the host. It has no external connection by itself.
• Private: connects VMs attached to that switch on the same host, without a host-side virtual adapter on that switch.

These describe virtual network paths, not guarantees that a guest can reach a destination. IP addressing, routing, VLANs, network authentication and firewalls still apply. A VM on an external switch does not automatically inherit the host's VPN access or every network permission.

Microsoft explains the types in its virtual switch guide.

Consider the Windows Client Default Switch

For a typical guest that only needs outbound access, check whether Windows 11's managed Default Switch meets the need before creating another switch. It provides managed NAT and address assignment rather than placing the guest directly on the physical LAN as an external switch would.

The Default Switch's managed addressing is not a good foundation for an assumed permanent static subnet or a server that must be directly reachable from the LAN. An explicit external switch or a deliberately configured lab network may fit those requirements better. Do not edit or recreate managed networking just because an older tutorial starts with a different design.

An External Switch Does Not Guarantee Internet Access

Choose the intended active physical adapter and check whether the host can reach the required service. In the VM, verify the virtual NIC connection, address, subnet, gateway and DNS. Use DHCP if the physical network permits it, or the static configuration supplied for that network.

Wi-Fi adapters, drivers and enterprise authentication can introduce constraints. Testing with supported Ethernet can help identify a wireless-specific problem, but is not a guaranteed fix. Check VLAN settings only when the physical network requires them; do not guess a VLAN ID.

Creating or changing an external switch can briefly interrupt host connectivity. If the host must continue using that adapter, review Allow management operating system to share this network adapter before applying the change.

Internal Networking Can Be Extended with NAT

A plain internal switch does not provide internet access, but NAT, routing, Internet Connection Sharing or a router VM can provide an external path. It is therefore incorrect to say an internal switch can never reach beyond the PC.

For an explicitly configured WinNAT lab, follow Microsoft's NAT setup guide. A manually created internal switch and WinNAT object do not automatically supply a guest DHCP server. Configure guest IP, gateway and DNS as the design requires, or deliberately provide DHCP.

Choose a private subnet that does not overlap the host's LAN, VPN or other virtual networks. A /24 network is a convenient example, not a mandatory subnet size. Avoid modifying existing Docker, WSL or managed NAT networks to fit an unrelated tutorial.

Private Means a Limited Network Path, Not Zero Risk

A private switch has no host adapter or physical uplink of its own. However, a VM with a second adapter or routing software can connect that network elsewhere. Shared folders, clipboard/device redirection and other integration features are separate from the switch type.

Do not treat a private switch as a guarantee that malware testing is harmless. Select the network topology for its intended communication paths and account for all other guest-host connections. Microsoft’s Hyper-V security guidance also addresses host updates, access and VM security configuration.

For simple VM-to-VM communication, use addresses in the same subnet or a deliberately configured DHCP service. A switch itself is not an IP address server. Static addressing is one option, not the only possible design.

Create Only the Switches You Need

Open Hyper-V Manager > Virtual Switch Manager, select the required type and give the switch a clear purpose-based name. Then choose that switch under the VM's Network Adapter settings. You do not need one of every type merely to use Hyper-V.

Before changing an existing VM's connection, note its original switch, IP configuration and any VLAN requirements so you can restore them. A guest may need an address renewal or reconfiguration after a network change; rebooting every VM is not inherently required.

Troubleshoot by Layer

1. Confirm the intended VM adapters connect to the same expected switch.
2. Check link state, guest addressing and subnet compatibility.
3. Test the gateway or a known service, then test name resolution separately.
4. If ping fails, remember that ICMP may be blocked even when another service works.
5. Inspect narrowly scoped firewall rules on the actual active profile. Windows profiles are Domain, Private and Public; there is no general “Internal” firewall profile.
6. Investigate the physical adapter, VPN or upstream policy when only external access fails.

Do not disable the firewall globally. Enable MAC-address spoofing only for a documented requirement such as a specific nested-networking design, rather than as a routine connectivity fix.

Choose the simplest topology that provides the required access, and verify that access with a real service test before adding more complexity.