The Azure Base Configuration test lab, the latest incarnation of the base configurations for the Test Lab Guide (TLG) initiative, is hosted in a cloud-only virtual network in Microsoft Azure, rather than on a Hyper-V server on an isolated subnet or connected to your organization intranet. Here is its configuration.
Advantages to running your test lab in Azure are ongoing connectivity to the Internet and the ability to more quickly add new servers. For more information, see New Base Configuration in Microsoft Azure!
In this post, I will explain how this networking environment works in the following ways:
Communication between virtual machines
All of the computers in the TestLab virtual network obtain an IP address from the 10.0.0.0/24 address space. Because DC1 is configured first and always started first, it gets the IP address 10.0.0.4. IP traffic between computers in the TestLab virtual network is delivered directly. This is facilitated by an Azure equivalent to Layer 3 switching.
The computers in the TestLab virtual network have the following DNS configuration:
Therefore, when communicating with each other:
Communication from virtual machines to the Internet
DC1 is not configured with forwarders. Based on default settings, the DNS Server service in Windows Server 2012 R2 will automatically query Internet root domain servers for names for which it is not authoritative. The list of Internet root servers and their IP addresses are on the Root Hints tab of the properties of the DNS server in the DNS snap-in.
Therefore, when a computer wants to communicate with another computer or service on the Internet:
Note that the DNS name resolution traffic in step 1 also goes through the Azure Load Balancer.
Remote desktop connections
When you connect to an Azure virtual machine from the Virtual Machines screen of the Azure portal, your computer downloads an RDP file with the correct DNS domain name for the cloud service containing the virtual machine and the correct randomized port number of the RDP service on the destination virtual machine.
The Azure portal automatically configured this randomized TCP port as an endpoint when you created the virtual machine. An endpoint instructs the Azure Load Balancer to forward unsolicited, incoming traffic to the TCP or UDP port number of the configured virtual machine, changing the port number if needed. In the case of incoming RDP traffic, the cloud service changes the destination TCP port number from the randomized port number to 3389, the well-defined port number on which the virtual machine is listening for remote desktop connection traffic.
Therefore, when you initiate a remote desktop connection with the downloaded RDP file: