Creating a Virtual Network for AVD – Implement and Manage Networking for Azure Virtual Desktop

Creating a Virtual Network for AVD

VNet and on-premises connectivity are important prerequisites for Azure Virtual Desktop. It is important to set up VNet correctly with the required subnet, DNS settings, and peering with a hub virtual network for on-premises connectivity (or hub shared service connectivity) so that users can use their domain credentials to log in to AVD and access their on-premises applications/services.

Follow these steps to create a VNet instance for AVD:

\ 1.\ Log in to the Azure portal and select the correct directory and subscription where you want to create the AVD host pool and desktops. Make sure you have correct permissions (contributor or owner) to create network resources. See Figure 4-2.

Figure 4-2.  Azure subscription selection

\  2.\  Search for virtual network in the top search bar. See Figure 4-3.

Figure 4-3.  Azure virtual network search

\  3.\  Click Create to create a new virtual network. See Figure 4-4.

Figure 4-4.  Azure virtual network creation

\ 4.\ Select the correct subscription and resource group names from the drop-down where you want to create the AVD desktops. If the resource group does not exist, then you can create a new resource group by clicking the Create New option. See Figure 4-5.

Figure 4-5.  Azure virtual network creation page

\ 5.\ Additionally, provide the virtual network name as per your organization’s naming standard and select the correct region (the same as AVD desktops). Click the Next button once, and enter all the information. See Figure 4-6.

Figure 4-6.  Azure virtual network creation, Basic tab

\ 6.\ Provide the IP address space/range for VNet on the IP Addresses tab. You must coordinate with the network team to get the correct IP address range for AVD VNet that does not conflict with an existing VNet or on-premises IP address range. See Figure 4-7.

Figure 4-7.  Azure virtual network creation, IP Addresses tab

\ 7.\ Additionally, create an appropriate subnet on the same IP Addresses tab. You can click the “Add subnet” option to add additional subnets. You must consider the number of session hosts/VMs you are planning to create under each subnet plus some buffer IP addresses for future use and create the subnet accordingly. Create the subnet, remembering that each host pool needs to be placed in different subnets if they belong to different business units and don’t want to share any user data. See Figure 4-8.

Figure 4-8.  Azure virtual network creation, add subnet

\ 8.\ You will get a subnet pop-up to enter additional subnet information like the name and IP address range. Make sure you are entering the subnet name as per your organization’s naming standards. Click the Add button to add the subnet. See Figure 4-9.

Figure 4-9.  Azure virtual network creation, adding a subnet detail

\ 9.\ Once you have entered all the IP address information, then click Next to go to the Security tab and verify whether you want to change anything as per your organization standards, or click Next to go to Tags. Make sure you are adding tags as per your organization’s standards and click Next. See Figure 4-10.

Figure 4-10.  Azure virtual network creation, Tags tab

\ 10.\ Finally, click “Review + create” and then click Create once the validation is completed. See Figure 4-11.

Figure 4-11.  Azure virtual network creation, creating and reviewing

\ 11.\ You will be able to see deployment progress on the same page, and you can go to the resource once the deployment is completed. See Figure 4-12.

Figure 4-12.  Azure virtual network creation, deployment status

\ 12.\ You can verify the VNet details on the Overview page. See Figure 4-13.

Figure 4-13.  Azure virtual network, AVD VNet details

\ 13.\ If you still want to add subnets, then you can go to the Subnet option in the left pane and click to add a subnet. See Figure 4-14.

Figure 4-14.  AVD virtual network, adding a subnet

\ 14.\ Once the subnet and VNet are ready, then the next step is to create a network security group (NSG), peering to a hub virtual network, and DNS settings. Create the NSG and click the Create option to create a new network security group. See Figure 4-15.

Figure 4-15.  AVD virtual network, creating a NSG

\ 15.\ Select the correct subscription and resource group for the network security group (the same as AVD VNet). Add the NSG name and select the correct region the same way as you did for the VNet and AVD desktops. See Figure 4-16.

Figure 4-16.  AVD NSG creation

\ 16.\ You will see the deployment status on the same page. Wait for the deployment to complete and then click “Go to resource.” See Figure 4-17.

Figure 4-17.  A AVD NSG creation, deployment status

\ 17.\ The NSG default rules will be visible on the Overview page. See Figure 4-18.

Figure 4-18.  AVD NSG, Overview page

\ 18.\ Make sure to add the AVD-specific IP/port in the outbound rules. The following are the recommended/required IP addresses/ ports for AVD. AVD does not require any inbound connection but definitely needs KMS, metadata, health monitoring IP addresses/ ports, and a few Azure service tags in case you don’t want Internet access on the VM. Refer to Table 4-1 for all AVD-specific port and IP details. See Figure 4-19.

Figure 4-19.  AVD NSG, Outbound security rules

Table 4-1.  AVD NSG: Outbound Security Rules Requirement

Table 4-1.  (continued)

Table 4-1.  (continued)

Table 4-1.  (continued)

Understanding Azure Virtual Desktop Network Connectivity – Implement and Manage Networking for Azure Virtual Desktop

Understanding Azure Virtual Desktop Network Connectivity

As an Azure Virtual Desktop admin, you must manage virtual desktops and their connectivity, so understanding virtual desktop network connectivity is important. Fundamentally, Azure Virtual Desktop utilizes Remote Desktop Protocol (RDP) to offer remote display and input capabilities over network connections. The connection data flow for Azure Virtual Desktop starts with a DNS lookup for the closest Azure datacenter. Figure 4-31 demonstrates the five-step connection process for Azure Virtual Desktop running in Azure.

\ 1.\ When authenticated in the Azure Active Directory, a token is returned to the Remote Desktop Services client.

\  2.\  The gateway checks the token with the connection broker.

\ 3.\ The broker queries the Azure SQL database for resources assigned to the user.

\ 4.\ The gateway and the broker select the session host for the connected client.

\ 5.\ The session host creates a reverse connection to the client by using the Azure Virtual Desktop gateway. Figure 4-31 shows Azure Virtual Desktop connectivity.

Figure 4-31.  Azure Virtual Desktop connectivity

When no inbound ports are opened, the gateway acts as an intelligent reverse proxy. The gateway manages all session connectivity, with nothing but pixels reaching the client. Azure Virtual Desktop hosts client sessions on the session hosts running on Azure. Microsoft manages portions of the services on the customer’s behalf and provides secure endpoints for connecting clients and session hosts.

Azure Virtual Desktop Network Connection

Azure Virtual Desktop hosts client sessions on the session hosts operating on Azure. Since Azure is a cloud-based service, Microsoft manages portions of the services on the customer’s behalf and offers secure endpoints for connecting clients and session hosts. Figure 4-32 shows a high-level summary of the network connections utilized by Azure Virtual Desktop.

Figure 4-32.  Azure Virtual Desktop Network connections

•\    Session connectivity: Azure Virtual Desktop uses Remote Desktop Protocol to provide remote display and input capabilities over network connections.

•\    Reverse connect transport: Azure Virtual Desktop is utilizing a reverse connect transport for establishing the remote session and for carrying RDP traffic. Unlike the on-premises Remote Desktop Services deployments, reverse connect transport doesn’t use a TCP listener to receive incoming RDP connections. Instead, it is using outbound connectivity to the Azure Virtual Desktop infrastructure over the HTTPS connection.

•\    Session host communication channel: Upon startup of the Azure Virtual Desktop session host, the Remote Desktop Agent Loader service establishes the Azure Virtual Desktop broker’s persistent communication channel. This communication channel is layered on top of a secure Transport Layer Security (TLS) connection and serves as a bus for service message exchange between the session host and Azure Virtual Desktop infrastructure.

How Can You Filter the Network Traffic? – Implement and Manage Networking for Azure Virtual Desktop

How Can You Filter the Network Traffic?

You can filter the network traffic between subnets using either or both of the options including Network Security Group (NSG), and application security groups. NSG’s can contain multiple inbound and outbound security rules that permit you to filter traffic to and from resources by source and destination IP address, port, and protocol. Another option is a network virtual appliance (NVA), which is a VM that performs a network function, such as a firewall, WAN optimization, or other network function.

How to Route Network Traffic in Azure?

Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the Internet, by default. You can implement a route table or Border Gateway Protocol (BGP) route. Both options override the default routes that Azure creates.

By using route tables, you can create custom route tables with routes that control where traffic is routed to for each subnet. If you connect your virtual network to your on-premises network using an Azure VPN Gateway or ExpressRoute connection, you can propagate your on-premises BGP routes to your virtual networks.

Virtual Network Integration for Azure Services

Integrating Azure services to an Azure virtual network enables private access to the service from virtual machines or compute resources in the virtual network. You can integrate Azure services in your virtual network with the following options:

•\   If deploying dedicated instances of the service into a virtual network, the services can then be privately accessed within the virtual network and from on-premises networks.

•\   Using a private link to access a specific instance of the service privately from your virtual network or from on-premises networks.

•\   You can also access the service using public endpoints by extending a virtual network to the service, through service endpoints. Service endpoints allow service resources to be secured to the virtual network.

No inbound ports are opened. In this version, the gateway acts as an intelligent reverse proxy. The gateway manages all session connectivity, with nothing but pixels reaching the client.

Azure Virtual Desktop hosts client sessions on the session hosts running on Azure. Microsoft manages portions of the services on the customer’s behalf and provides secure endpoints for connecting clients and session hosts. The diagram above (Figure 4-32) gives a high-level overview of the network connections used by Azure Virtual Desktop.