After setting up a NAT virtual switch in Hyper-V for Windows 10 Fall Update/1511, you may still need to access those VMs over the network for management purposes or to access applications running on those systems. In this article, I’ll show you how to access the VMs behind NAT.

One of the hidden gems in the Fall Update/1511 update for Windows 10 (and Windows Server 2016 TP4) is the ability to create a native NAT virtual switch for Hyper-V. This enables you to share a network connection to multiple virtual machines (VMs) without extra software or additional VMs to act as a router/gateway. This feature has been available in other virtualization products for some time and is a great addition to Hyper-V in Windows 10.

After setting up your NAT virtual switch, you may still need to access the VMs running on that host over the network. Because these machines are behind a single IP address on the host system, you may have to perform some additional setup depending on how you want to access them.

Using the local/host system ^

If you are using the local/host system, there's good news: you don't need to make any system changes to access the VMs on the NAT virtual switch. To access any of the VMs, simply use the IP address or DNS name of the machine. As you can see in the example below, I'm able to browse to the UNC name of a Domain Controller (DC) in my lab from the host system DESKTOPPC2:

Browsing to a virtual machine behind NAT on the host system
Browsing to a virtual machine behind NAT on the host system

If you want to browse by DNS name, your host computer will need to utilize a DNS server where the VMs have registered their DNS names. If your VMs are joined to the same Active Directory (AD) domain as the host system, there’s no additional configuration necessary. If you’re running a lab on the NAT network that uses a different namespace, you can configure the NAT virtual switch’s virtual Ethernet adapter with your lab’s DNS server. In my lab network, the DC is 10.0.75.250 and is running DNS locally.  In the GUI, you can see how I’ve configured this below:

Set the DNS server for the vEthernet NAT adapter in the GUI
Set the DNS server for the vEthernet NAT adapter in the GUI

You can also configure this on the host system using PowerShell: 

Set-DnsClientServerAddress -InterfaceAlias "vEthernet (NAT)" -ServerAddresses 10.0.75.250

Here’s how you would do it if you have more than one DNS server in your lab: 

Set-DnsClientServerAddress -InterfaceAlias "vEthernet (NAT)" -ServerAddresses ("10.0.75.250","10.0.75.251")

Accessing VMs from another system on the network ^

Accessing the VMs from another system on the network requires some additional setup using the Add-NetNatStaticMapping PowerShell cmdlet. In the example below, we’ll set up port forwarding so we can RDP into one of the systems behind NAT.

Add-NetNatStaticMapping –NatName NAT –Protocol TCP –ExternalIPAddress 0.0.0.0 -ExternalPort 43389 –InternalIPAddress 10.0.75.250 –InternalPort 3389

Here’s a little more information about the purpose of each parameter:

Subscribe to 4sysops newsletter!

  • NatName – This is the name of your NAT that we created based on my previous article. If you don’t remember what you named it, you can use the Get-NetNat cmdlet to find the name you used.
  • Protocol – TCP or UDP depending on the service.
  • ExternalIPAddress – For this parameter, I’m using 0.0.0.0. Most systems that are running client Hyper-V on Windows 10 aren’t going to have static IP addresses, especially if you’re using a laptop and floating between Wi-Fi networks or over to wired networks. Using this configuration allows you to use your forwarded port regardless of network, ensuring fewer headaches later.
  • ExternalPort – This is the public port that you’ll use. You’ll most likely want this to be something different than the original port that is used by the service.
  • InternalIPAddress – This is the IP address of the virtual machine that is behind NAT.
  • InternalPort – This is the port of the service hosted on your VM behind NAT. (Don’t forget to open the firewall on the VM!)
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account