How to set up a NAT network with subnets in Hyper-V

Today we're going to be looking at Network address translation (NAT) networking in Hyber-V Knowing how to do stuff like this is pretty much essential knowledge for any budding sysadmin. Both because regardless of where in IT you work and what you do - every IT professional needs to know basic networking

Besdies, you won't get anywhere with your homelab if you don't know how to get your VMs and/or bare metal devices talking to each other. 

This should particularly useful if you're coming from my quick 'n dirty homelab guides about setting up and Doman Joining the brand new Windows 10 and Windows Server VMs you set up Hyper-V!



Let's get going! So, what's NAT?

A public IP address is required to access the Internet, but we can utilize a private IP address on our private network. The goal of NAT is to allow many devices to connect to the Internet using a single public address. This necessitates the conversion of a private IP address to a public IP address.

In order to enable Internet connectivity to local hosts, one or more local IP addresses are converted into one or more global IP addresses and vice versa. It also does port number translation, i.e. masks the host's port number with another port number in the packet that will be forwarded to the destination. The NAT table is then updated with the relevant IP address and port number entries. A router or firewall is usually used for NAT.


How does this help me get my Hyper-V VMs talking with each other?

Now this isn't going to be a straight forward tutorial. I'm approaching this the same way I did years ago when I first started playing around with homelabing and trying to figure things out on my own. The reason I'm doing it this way is because I (personally) learn just as much from seeing how not to do things. 

If you're just interested in getting on with it, then scroll down to The "Real" Solution.

The first thing we need to figure out is how our Win10 client is going to be able to resolve the resolve not only our lab.int domain but also be able to resolve the Domain Controller at WINS2022.lab.int. "Luckily" (in part to my laziness), the DC also hosts the domains DNS service so we only need to remember one IP. 

But wait, hold on! Hyper-V This is a homelab setup so most likely you're using a hypervisor like Hyper-V! And Hyper-V has a funky way of approaching its networking where it auto assigns subnets (that can't be changed manually. Annoyingly enough) even if sharing the virtual NIC between VMs. Oh well. Let's see how far we get. 

First of all we need to see what we're actually working with so press Shift + F10 to open up a CMD prompt and run ipconfig /all.


OK so the Win10 client has been assigned a DNS server at 172.28.144.1.

Do the same on your Domain Controller. 


Our DCs (and remember, DNS server) IP is 172.17.55.113. Now let's see if we can ping it from our Win10 client VM. 

NoteBecause Windows computers block incoming ping requests by default, you may not receive a response from your virtual switch. That doesn't mean it's broken; it just means incoming ping (ICMP echo) packets aren't enabled. This has no bearing on network connectivity. Now that shouldn't be the case here but just keep that in mind in case you find yourself banging your head against a wall in frustration. 


D'oh.

See? I told you our VMs being assigned on different subnets was going to be an issue. So, what now? 


The "Real" Solution

We need to get both VMs on the same subnet and we do that by simply making a new subnet using Hyper-Vs Virtual Switch Manager


Select InternalCreate Virtual Switch.


Now on the Hyper-V host - that is your actual device that you're running Hyper-V on -  run ncpa.cpl and configure the virtual switch we just made in Hyper-V. Leave the gateway and DNS addresses blank. 


Add the new NIC as a Network Adapter in both the Win10 client and Windows Servers VMs. 




Launch ncpa.cpl on your Domain Controller and use the following settings:


Now do the same on the Win10 client VM:


WILL YOU LOOK AT THAT??? Now our Client can ping the our DC!


Now we can configure IP addresses on the virtual switch interfaces

Run ncpa.cpl to get into the Network Connections Control-Panel Stub file. Right click on Ethernet and select Properties. Assign the client an IP on the same subnet; same subnet mask. For the sake of simplicity, I'm assignig 10.0.0.2 to the Win 10 client. Don't assign an IP with such a "low" host address to a client in the real world 😝.

And type in the IPs for the Preferred DNS server so that it points to our DC/DNS server:


And Bob's your uncle! That should do it! If you've made it this far then the rest of the setup should be a cake walk. 


Well done, you!