How to enable Internet and vNET connectivity for nested VMs in Azure

For a full walk-through of this setup, please watch the video at the end of this post.

Greetings readers,

Hyper-V nested virtualization in Azure has unlocked different scenarios and use cases such as sandbox environments, running unsupported operating systems or legacy applications that require specific features that are not natively supported in Azure, think about that application that has licenses tied to a MAC address for example.

In certain scenarios, you want those nested VMs to connect to the Internet or other VMs in Azure, however, due to restrictions on the network fabric, it is not possible to create an external switch and give VMs direct access to the host’s physical network. A solution to this is to configure NAT so that VMs can access the Internet with the host NATed public IP and also routing to enable connectivity to other VMs in Azure. In this blog post, I will walk you through the process of configuring nested VMs networking to achieve those goals.

Build the virtual network

We will need to build a vNet with two subnets, one for the host LAN traffic which may include other Azure VMs as well and another one for Internet traffic where we will enable NAT.

Example:

LabVnet – 10.2.0.0/16 (Main address space)

NAT Subnet – 10.2.0.0/24

LAN Subnet – 10.2.1.0/24

Later on, we will use 10.2.2.0/24 virtual address space for the nested VMs running inside the Hyper-V host.

Build the Hyper-V Host VM

• Create a new Azure VM that will be your Hyper-V host. Make sure you pick a size that supports nested virtualization and connect the first network adapter to the NAT subnet as you build the VM. It is important that the first adapter is connected to the NAT subnet because by default all outbound traffic is sent through the primary network interface.
• Once the VM is provisioned, add a secondary network adapter and connect it to the LAN subnet

• Enable IP forwarding on the newly created secondary interface

Configure the Hyper-V Host

Install the necessary roles for the next steps:

• Hyper-V
• DHCP
• Routing (RRAS)

DHCP will be used to automatically assign IP addresses to the nested VMs and RRAS will be used to route traffic between the nested VMs and other Azure VMs as well as provide NAT for Internet access.

Install-WindowsFeature -Name Hyper-V,DHCP,Routing -IncludeManagementTools -Restart

Create a virtual switch that will be used by the nested VMs as a bridge for NAT and Routing

New-VMSwitch -Name "Nested" -SwitchType Internal
New-NetIPAddress –IPAddress 10.2.2.1 -PrefixLength 24 -InterfaceAlias "vEthernet (Nested)"

Rename the network adapter names on the Hyper-V host to match the subnet names in Azure, this will make it easier to identify the networks when we are configuring routing. In this example, this is what the host network settings look like after creating the switch.

Configure DHCP

Create a DHCP scope that will be used to automatically assign IP to the nested VMs. Make sure you use a valid DNS server so the VMs can connect to the internet. In this example, we are using 8.8.8.8 which is Google’s public DNS.

Add-DhcpServerV4Scope -Name "Nested" -StartRange 10.2.2.2 -EndRange 10.2.2.254 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -DnsServer 8.8.8.8 -Router 10.2.2.1

Configure RRAS

First, we will enable NAT for Internet access. Open the Routing and Remoting Access console, use custom configuration, select NAT and Routing, once the service is started, navigate to IPV4 , right-click NAT and select New Interface. Now select the interface that matches your NAT subnet and enable NAT as follows:

We will now configure static rules to routes to allow traffic from nested VMs to other VMs connected to the Azure virtual network.

Under IPv4, right-click static routes, select new static route and create routes as follows:

This route is to allow the primary interface to respond to traffic destined to it out of its own interface. This is needed to avoid an asymmetric route.

Create a second route to route traffic destined to the Azure vNet. In this case, we are using 10.0.0.0/16 which encompasses our labvnet including the Hyper-V LAN subnet.

At this point, our host is ready to automatically assign IPs to the nested VMs, it can now also allow VMs to connect to the Internet with RRAS NATing the traffic.

Configure User-Defined Routes

The last step in the process is to configure UDRs in Azure to enable traffic to flow back and forth between VMs connected to the Azure vNet and nested VM’s in our Hyper-V host. We do so by telling Azure to send all traffic destined to our nested VMs, 10.2.2.0/24 in this example, to the LAN IP of our Hyper-V host where RRAS will route the traffic to the VMs via the internal switch created earlier.

#Create Route Table
$routeTableNested = New-AzRouteTable `
  -Name 'nestedroutetable' `
  -ResourceGroupName nestedvm-rg `
  -location EastUS

#Create route with nested VMs destination and Hyper-V host LAN IP as a next-hop
$routeTableNested  | Add-AzRouteConfig `
  -Name "nestedvm-route" `
  -AddressPrefix 10.2.2.0/24 `
  -NextHopType "VirtualAppliance" `
  -NextHopIpAddress 10.2.1.4 `
 | Set-AzRouteTable

#Associate the route table to the LAN subnet
 Get-AzVirtualNetwork -Name labvnet | Set-AzVirtualNetworkSubnetConfig `
 -Name 'lan' `
 -AddressPrefix 10.2.1.0/24 `
 -RouteTable $routeTableNested | `
Set-AzVirtualNetwork

After creating an additional Azure VM which we want to use to test connectivity from outside the host,  our final network topology is this:

 

Conclusion

We now have full connectivity to both the Internet and other VMs connected to the Azure vNet allowing the nested VMs to be reachable by other devices outside the Hyper-V host.

Refer to the video below for a full walk-through: