How the Azure Base Configuration Test Lab works

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:

• How computers within the TestLab virtual network resolve each other's names and exchange traffic
• How computers within the TestLab virtual network resolve Internet names and exchange traffic
• How your computer accesses the computers in the TestLab virtual network with a remote desktop connection

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:

• DC1 is using itself as a DNS server to register and resolve names
• APP1, CLIENT1, and other computers are using the IP address of DC1 (10.0.0.4) as their DNS server to register and resolve names

Therefore, when communicating with each other:

1. A computer in the TestLab virtual network sends a DNS name query to DC1 at 10.0.0.4.
2. DC1 resolves the name to an IP address and sends it back to the requesting computer.
3. The computer initiates communication directly with the destination.

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:

1. It sends a DNS name query for an Internet resource to DC1.
2. After determining that it is not authoritative for the domain name, DC1 uses the DNS iterative query process—starting with an Internet root server—to resolve the name to an Internet IP address.
3. DC1 sends the resolved IP address back to the requesting computer.
4. The requesting computer then sends the traffic directly to the Internet destination. This traffic is forwarded by the Azure Load Balancer, which provides routing, traffic translation, firewalling, and load distribution services for traffic to and from the virtual machines in the TestLab virtual network. The Azure Load Balancer also changes the source IP address of the traffic to the IP address of the cloud service.
5. The response traffic from the Internet resource is received by the Load Balancer and forwarded because it is in response to the request from the TestLab computer. The Azure Load Balancer also changes the destination IP address to the virtual machine's IP address.

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:

1. Your computer resolves the IP address of the cloud service that contains the virtual machine.
2. Your computer sends the initial TCP connection request message, known as a TCP SYN segment, which the Azure Load Balancer receives.
3. The Azure Load Balancer examines the destination TCP port in the packet and checks for a match in the list of configured endpoints.
4. After finding a match, the Azure Load Balancer changes the destination TCP port number in the packet to 3389, changes the destination IP address to the IP address of the virtual machine, and then forwards the packet.
5. The Azure Load Balancer receives the response traffic from the virtual machine, which translates the source TCP port number and source IP address and forwards it to your computer.

Joe Davies