Chapter 6: NAT network configuration
Build a simple NAT network, with one NAT gateway server on the public and private networks, and one NAT’ed server on the private network that accesses the Internet through the NAT gateway.
Last tested: NEVER
On this page
- Setting multiple networks on the NAT gateway
- Remoting to machines behind the NAT gateway
- Lab exercises and files
Setting multiple networks on the NAT gateway
The NAT gateway performs routing and NAT services between the
NATNET-CORP network and the public network.
RFC 1918 address ranges
When defining private networks, you should always follow the best practice of using RFC 1918 IP address ranges. For IPv4, these ranges are:
Of course, you are free to divide these up into sub networks.
In this chapter, we use only the
and leave the rest of the
10.0.0.0/8 network undefined.
Selecting a network range for use on
The only important concern for selecting which private IP address range to use in any scenario (including building a lab network in Hyper-V) is to ensure that it will not need to communicate with any other network that shares the same range.
For almost all cases, this means you should use a different network range than the one on your host’s local network.
For instance, if your Hyper-V host is attached to a WiFi network using
then it will have an IP address in the range
In this case, you can use any range in
or even another part of the
192.168.0.0/16 range that is not defined on your local network,
It’s also worth noting that if you wish to connect your lab VMs to an external VPN for some reason, you will also need to ensure that the network range of the VPN does not overlap with your private network range.
Your host is almost certainly behind a NAT network already,
which means that any machine on the private
NATNET-CORP network will be double-NAT’ed.
This makes protocols that rely on dynamic ports,
such as FTP,
hard to use behind the double NAT,
but for a lab this is probably OK.
This is an example network diagram that includes the host’s local network using
Multiple network switches for Lability VMs
You can connect a Lability VM to multiple switches by using a Powershell array for the value of
In our config here, we do so with a snippet in our configuration data like so:
For each switch in the array,
as stated previously,
if there is no existing Hyper-V switch with that name,
Lability will look in the
NonNodeData for a switch configuration
that can set what type of switch it is.
If none is found, Lability will create an Internal Hyper-V switch.
In the configuration data we use for this example (see below),
we define the
NATNET-CORP network to be an internal Hyper-V network.
This means that it’s only accessible to virtual machines which have an adapter on the network;
our host machine has no direct access to the network.
Furthermore, for each switch in the array,
Lability will create a separate virtual network adapter in the node;
one switch results in one network adapter,
two switches in two adapters, etc.
By default, Windows names these adapters
Ethernet 3, etc.
For more information about Hyper-V switch types, see Hyper-V switch types
Hyper-V network order is not predictable
However, unfortunately Hyper-V network adapters are not guaranteed to come up in any given order,
which means that in your configuration file,
Wifi-HyperV-VSwitch network could come up attached to the adapter named
NATNET-CORP network could come up attached to the adapter named
or vice versa, and that this can change every time you run
This causes problems,
because it doesn’t allow you to assume that either
Ethernet 2 is either network in particular
in your configuration document.
We work around this by assigning each adapter a certain MAC address,
then using that MAC address in the configuration document to rename the network adapter after the network
(so that the adapter on the
NATNET-CORP network is renamed to
and then finally using those new adapter names when we assign IP addresses
or do any other network configuration.
That looks like this in our configuration data:
And it looks like this in the configuration script:
This technique was found in the Lability examples:
and mentioned in a Lability issue as a solution for our problem:
Special considerations when assigning MAC addresses
There are two final items to keep in mind when manually assigning MAC addresses to Hyper-V NICs.
Hyper-V has a dedicated MAC address range of
00-15-5d-ff-ff-ff. You should make sure your MAC address falls within this range.
Ensure no duplicate MAC addresses exist on your public network.
When assigning a MAC address to an interface, it is important to ensure that it is not a duplicate of any other MAC address on the local network. On physical network interfaces, this assurance comes from the manufacturer, who is assigned a dedicated range of addresses and who commits to assigning a unique MAC address to each NIC it sells. Microsoft has also been assigned a range for Hyper-V NICs, and by default it generates a new NIC in that range for all the virtual NICs owned by each VM.
However, when we assign MAC addresses ourselves in this chapter, it becomes our role to ensure that no NIC on the local network is assigned the same MAC.
Remoting to machines behind the NAT gateway
We can use PS Remoting to issue commands to VMs behind the NAT gateway, but it is a bit tricky and inconvenient. See Powershell Remoting if you wish to do this.
Lab exercises and files
Deploy the lab with Deploy-NATNET.ps1
Log on to both the gateway machine (
EDGE1) and the machine behind the gateway (
Prove that each can talk to the Internet by pinging an address or visiting a website.
Compare the following from each VM:
- The list of network interfaces from
- The routing table from
- The traceroute to a host like CloudFlare’s 188.8.131.52 DNS servers from
Test-NetConnection -ComputerName 184.108.40.206 -TraceRoute
- The list of network interfaces from
Use Powershell Remoting to run commands against the
CLIENT1machine from your lab host
Add a server machine behind the gateway.
Add a Windows 2016 VM as
SERVER1, give it a different role such as
SERVER, modify ConfigurationData.NATNET.ps1 to include the
xSmbShareDSC resource, and modify Configure-NATNET.ps1 to configure the fileshare. (See documentation for
Redeploy the lab with this change, log on to the
CLIENT1machine, and connect to the SMB share you defined.