A Hyper-V NAT network is one of the cleanest ways to give lab virtual machines internet access without handing them a seat on the same physical LAN as every other device in the building. The important distinction: NAT is not a special Hyper-V switch type. The working arrangement is an Internal virtual switch, an IP address assigned to the host-side virtual adapter, and a Windows NAT object that translates guest traffic through the host’s connection. It is a tidy little network border—less red carpet, more bouncer at the door.

This setup is ideal for testing software, building a Windows 11 lab, running an isolated Linux appliance, or experimenting with server roles without making each VM directly visible on the home or office network. Guest VMs can reach the internet through the host, communicate with the host and other VMs on the same internal switch, but do not receive an address from the physical LAN’s DHCP server.

Diagram showing an isolated Hyper-V lab subnet with outbound NAT internet access, separate from the physical LAN. Before You Start​

This guide applies to Windows 10 and Windows 11 hosts with Hyper-V enabled. Microsoft lists Hyper-V support on Windows 10 Pro or Enterprise and Windows 11 Pro or Enterprise; the Home editions do not include the installable Hyper-V role. The host also needs a 64-bit CPU with SLAT, hardware virtualization enabled in UEFI/BIOS, and sufficient RAM for Windows plus its guest machines.

Open PowerShell as Administrator for every host-side command below.

Before creating anything, inspect the host’s existing NAT configuration:

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix

This is not housekeeping for its own sake. Microsoft’s WinNAT documentation warns that Windows supports one internal NAT subnet prefix per host. Docker, Windows containers, and other virtualization tools may already use it. If a NAT already exists, do not casually remove it—doing so can break containers or development environments that depend on it. Plan a shared subnet carefully or use a different networking design.

Also choose a private subnet that does not overlap with your physical LAN, VPN, or another lab network. This guide uses 192.168.250.0/24; if your router, VPN, or a remote network already uses that range, pick another unused RFC 1918 subnet.

Create the Internal Hyper-V Switch​

The internal switch gives the VM network a connection to the host, but not directly to the physical network adapter. That is exactly what makes it the right foundation for a NAT lab.

Run:

Code: 
$Switch = "LabNAT"
$Gateway = "192.168.250.1"
$Prefix = 24
$Subnet = "192.168.250.0/24"

New-VMSwitch -Name $Switch -SwitchType Internal

Hyper-V will create a host-side adapter with a name similar to:

vEthernet (LabNAT)

Confirm that it exists and note its interface index:

Get-NetAdapter -Name "vEthernet ($Switch)"

An Internal switch differs from an External switch in one crucial way: it does not bind the VM directly to a physical Ethernet or Wi-Fi adapter. External switches are useful when a VM should participate on the LAN as a peer device; an Internal switch is the more controlled choice when the goal is NAT-based outbound access.

Assign the Host-Side Gateway Address​

The host’s virtual Ethernet adapter needs an address that will serve as the default gateway for the VMs.

Code: 
$ifIndex = (Get-NetAdapter -Name "vEthernet ($Switch)").ifIndex

New-NetIPAddress `
 -IPAddress $Gateway `
 -PrefixLength $Prefix `
 -InterfaceIndex $ifIndex

With a /24 prefix, the network uses subnet mask 255.255.255.0. The host is now reachable on 192.168.250.1 from machines attached to this virtual switch.

Verify the address assignment:

Get-NetIPAddress -InterfaceAlias "vEthernet ($Switch)" -AddressFamily IPv4

You should see 192.168.250.1 assigned to the vEthernet (LabNAT) adapter.

Create the Windows NAT Object​

Now add the component that allows guest traffic to leave the isolated subnet through the host’s network connection:

Code: 
New-NetNat `
 -Name $Switch `
 -InternalIPInterfaceAddressPrefix $Subnet

Confirm the result:

Get-NetNat -Name $Switch

At this point, the host side is complete. Windows has an Internal Hyper-V switch, a gateway address on that switch, and a NAT rule for the 192.168.250.0/24 network. Microsoft describes this arrangement as native NAT networking for Hyper-V on Windows 10 and Windows 11.

What You Have Created​

ComponentPurpose
LabNAT internal switchConnects the host and attached VMs on an isolated virtual Ethernet segment
192.168.250.1The host-side gateway address for the virtual subnet
192.168.250.0/24The guest network range
LabNAT NAT objectTranslates VM traffic so it can reach external networks through the host

One limitation catches many administrators: WinNAT does not act as a DHCP server for ordinary Hyper-V VMs. In plain English, connecting a VM to the switch does not automatically give it an IP address. Configure a static address in each guest, or deploy a DHCP server on that isolated network if the lab needs many machines.

Connect a VM to the NAT Switch​

Shut down the VM if necessary, then open Hyper-V Manager:

  1. Right-click the virtual machine and select Settings.
  2. Select Network Adapter.
  3. Under Virtual switch, select LabNAT.
  4. Select Apply, then OK.
  5. Start the VM.

The virtual adapter is now connected to the isolated NAT network. It still needs a valid address inside the selected subnet.

Configure the Guest Network Adapter​

For a Windows guest, assign a static IPv4 configuration such as:

SettingExample value
IP address192.168.250.10
Subnet mask255.255.255.0
Default gateway192.168.250.1
DNS serverYour preferred reachable resolver, such as the host’s approved DNS server or a public resolver permitted by policy

Do not use 192.168.250.1; that address belongs to the host. Assign each VM a unique address, for example .10, .11, .12, and so on.

From an elevated PowerShell session inside a Windows guest, an example configuration could look like this:

Code: 
New-NetIPAddress `
 -InterfaceAlias "Ethernet" `
 -IPAddress 192.168.250.10 `
 -PrefixLength 24 `
 -DefaultGateway 192.168.250.1

Set-DnsClientServerAddress `
 -InterfaceAlias "Ethernet" `
 -ServerAddresses 1.1.1.1,8.8.8.8

The adapter name may not be Ethernet; use Get-NetAdapter inside the guest first if the command reports that it cannot find the interface.

For Linux guests, configure the same four essentials through the distribution’s network manager or configuration files: a unique IP address, /24 prefix, default gateway of 192.168.250.1, and usable DNS servers.

Verify That NAT Is Working​

Work from the guest outward. This avoids the classic “the switch exists, therefore the network must work” assumption—a statement with roughly the same reliability as “the printer has plenty of ink.”

First, verify the guest received the expected settings:

ipconfig /all

Then test the gateway:

ping 192.168.250.1

If that succeeds, test external IP connectivity without relying on DNS:

Test-NetConnection 1.1.1.1 -Port 443

Finally, test name resolution:

Resolve-DnsName microsoft.com

A practical success pattern is:

  • The guest can reach 192.168.250.1.
  • A TCP connectivity test to an external IP succeeds.
  • DNS resolution returns addresses.
  • A browser in the VM can load an external site.

On the host, verify the three building blocks:

Code: 
Get-VMSwitch -Name $Switch
Get-NetIPAddress -InterfaceAlias "vEthernet ($Switch)" -AddressFamily IPv4
Get-NetNat -Name $Switch

Troubleshooting the Common Snags​

The VM has no IP address​

That is expected unless you configured one. WinNAT provides address translation, not automatic IPv4 assignment for conventional VMs. Set a static IP in the guest, or add a DHCP service to the lab network.

The VM can reach the gateway but not the internet​

Check that the host itself has internet access. Then confirm that the NAT object exists:

Get-NetNat

Also check that the guest’s default gateway is exactly the host-side virtual adapter address, 192.168.250.1 in this example.

The VM reaches an IP address but cannot open websites​

That is usually DNS, not NAT. Check the configured guest DNS servers, then test with:

Resolve-DnsName microsoft.com

New-NetNat fails or behaves unexpectedly​

Look for another NAT first:

Get-NetNat

The one-NAT-prefix limitation is especially relevant on systems that use Windows containers or Docker-related networking. Microsoft specifically warns that multiple NAT configurations can leave WinNAT in an unsupported or unpredictable state. Treat an existing NAT as something to understand, not something to bulldoze.

Safe Cleanup​

When the lab is finished, disconnect or shut down the VMs first. Then remove only the objects created for this guide:

Code: 
Remove-NetNat -Name "LabNAT"

Remove-NetIPAddress `
 -InterfaceAlias "vEthernet (LabNAT)" `
 -IPAddress 192.168.250.1 `
 -Confirm:$false

Remove-VMSwitch -Name "LabNAT" -Force

Check that the custom configuration is gone:

Code: 
Get-NetNat -Name "LabNAT" -ErrorAction SilentlyContinue
Get-VMSwitch -Name "LabNAT" -ErrorAction SilentlyContinue

Removing a NAT object terminates existing connections passing through it, so cleanup should be planned rather than performed mid-update or during an active test run.

A NAT-based Hyper-V network is not a replacement for a full firewall appliance, VLAN design, or enterprise segmentation strategy. It is, however, an excellent self-contained lab pattern: VMs get controlled outbound connectivity, the physical LAN stays out of the experiment, and a single set of PowerShell commands can build—or dismantle—the whole stage.

 

Click to expand...
You must log in or register to reply here.