Where did the native NAT switch go in Windows 10 1607?

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
• Use Azure Storage for backup - Thu, Feb 23 2023
• Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023

In today's article, we extend 4sysops author Kyle Beckman's excellent article on configuring the NAT virtual switch that was included in pre-release and release-to-manufacturing (RTM) Windows 10:

Native NAT in Windows 10 Hyper-V Using a NAT Virtual Switch

Background information

One reason I've historically preferred VMware Workstation over client Hyper-V, even given VMware's license cost, is its native NAT virtual switch. Check out the following topology diagram I whipped up in Microsoft Visio:

How a NAT virtual switch works

The NAT virtual switch in VMware Workstation includes an on-board Dynamic Host Configuration (DHCP) server and a NAT device. The end result is that your hardware host computer resides on the same IP subnet as any VMs that are connected to the same virtual switch.

The following is a screenshot from my VMware Workstation Virtual Network Editor. You can see how robust the NAT and DHCP settings are.

NAT virtual switch in VMware Workstation

Depending on your Windows 10 version number, you may or may not have a (somewhat) similar NAT vSwitch capability. Here's a quick summary for you:

• Windows 10 Version 1507 (RTM): NAT vSwitch not present
• Windows 10 Version 1511 (November 2015 Update): NAT vSwitch present!
• Windows 10 Version 1607 (Anniversary Update): NAT vSwitch not present

As Kyle mentioned in his article, you still need an external DHCP server (like this cool freeware one) to bring the Hyper-V NAT vSwitch into general parity with VMware's offering.

The Microsoft Virtualization Team posted a blog entry titled "What Happened to the NAT VMSwitch" in which it explained the removal of the NAT switch in Windows Server 2016 Technical Preview (and, I presume, Windows 10 Version 1607) this way (slightly edited for clarity):

"Our users noticed a new Hyper-V virtual switch type—NAT—which was introduced to simplify the process of connecting Windows containers to the host using a private network. Additional users began to use this new VM switch type not only for containers but also for ordinary VMs to connect them to a NAT network. While this may have simplified the process of creating a NAT network and connecting containers or VMs to a vSwitch, it resulted in confusion and a layering violation in the network stack. The NAT vSwitch type has been removed to resolve this layering violation."

Interesting. So it looks like the team intended the NAT switch type only for Windows container-based VMs. Welcome to the world of continuous delivery, folks!

Workarounds

A number of astute 4sysops readers, including Cris Mooney, Mastaba, DavideDG, and John vdK, pointed out both the problem and a couple of workarounds. One idea involved installing the free VMware Player and hijacking its NAT virtual network interface card (vNIC). Specifically, you create an external switch in Hyper-V Manager that is linked to the VMware vNIC. Here's a tutorial from Thomas Vochten if you're interested.

The preferred workaround is reserved for Windows 10 Version 1607 computers. As is explained in the MSDN article "Set up a NAT network," we can define a reasonable NAT VM switch by performing the following three actions:

1. Create an internal Hyper-V switch.
2. Define a private IP network for NAT to use.
3. Assign the private network's default gateway address to the Hyper-V host's vNIC.

Let's work through each of those steps together.

Create an internal Hyper-V switch

Open up an elevated Windows PowerShell session and run the following command to verify your Windows 10 version and build number:

[System.Environment]::OSVersion.Version

Next, run New-VMSwitch to create the switch:

New-VMSwitch -SwitchName 'NATSwitch' -SwitchType Internal

Define the NAT network

Run Get-NetAdapter to find the interface index of your new NAT switch (mine is named vEthernet (NATSwitch) and has interface index 28).

We can use New-NetIPAddress to configure our NAT gateway. In the following example, I assign IP address 172.16.1.1/24 to the NATSwitch vNIC:

New-NetIPAddress -IPAddress 172.16.1.1 -PrefixLength 24 -InterfaceIndex 28

We then use New-NetNat to configure the NAT network. Because our NAT gateway has a 172.16.1.0/24 IP address, we'll use that as our NAT network address:

New-NetNat -Name 'NATNetwork' -InternalIPInterfaceAddressPrefix 172.16.1.0/24

The following screenshot sums up our configuration:

Our new NAT switch and virtual network adapter

Wrapping up

All that remains now is to attach your Hyper-V virtual machines to your new NAT switch. Because your hardware host has a vNIC on the same subnet, host-guest communications should proceed just fine. Here's an example using Connect-VMNetworkAdapter:

Connect-VMNetworkAdapter -VMName 'server1' -Name 'Internet' -SwitchName 'NATSwitch'

That is, host/guest communications will be just fine as long as your VMs have valid IP addresses. Sadly, you still need to rely upon a workaround (like Internet Connection Sharing) to hack DHCP into your NAT network.

Also, according to MSDN, multiple NAT networks are not supported on the same Hyper-V host. You and I both know that "not supported" doesn't mean that it won't work, but instead refers to whether Microsoft will help you if you get stuck.