Azure Virtual Desktop Networking Planning
Azure Virtual Desktop Implementation
The course is part of this learning path
The most fundamental component of any cloud solution is the network. It is networking that will provide connectivity and security to your applications and solutions. This is most critical with an internet-accessible solution like Azure Virtual Desktop, so we need to properly build it and secure it.
In this course, we will help you design your Azure Virtual Desktop network components so you can not only gain insight into those Azure services but also understand how they integrate and relate to the Azure Virtual Desktop service and help you to pass the Azure Virtual Desktop Specialty exam.
- Understand Azure virtual desktop networking requirements
- Recommend the correct solution for network connectivity
- Implement your Azure Virtual Desktop networking solution
- Manage connectivity to the internet and on-premises networks
- Implement and manage network security
- Manage Azure Virtual Desktop session hosts using the Azure bastion service
- Monitor and troubleshoot network connectivity
- Azure administrators with subject matter expertise in planning, delivering, and managing virtual desktop experiences and remote apps, for any device, on Azure
- Anyone looking to learn more about Azure Virtual Desktop
To get the most out of this course, you should have knowledge of the following:
- Azure networking
- Network security
- Network monitoring and troubleshooting
Security can take the form of permissions as well as controlling ingress and egress of your traffic. In Azure, this requires either network security groups or some kind of firewall. If you want to use the Azure firewall, then it must be deployed into your virtual network's subnet. If you are using a third-party firewall, there is no such requirement; I would still deploy it there to keep things isolated and identifiable unless the vendor specifically says to do otherwise.
In this deployment, we'll only deal with network security groups or NSGs. The NSG works on a five-tuple rule set; this means that it will be looking at the source IP, destination IP, source port, destination port and protocol. For example, your AVD users will log onto their session host and need to load their FSLogix profile. The session host, which has a source IP address of 10.0.4.10 will need to connect to your Azure file's storage that has a destination IP of 10.0.5.50. This connection will have a source and destination port of 445, which is the SMB port and the protocol is TCP.
Now you'll have to make a rule in the NSG to allow this traffic to flow. In the same resource group you just deployed your virtual network, click to add a new resource at the top, in the search box type, "network security group". The subscription and resource group should already be selected for you; if not, select the same ones that you used to deploy your virtual network.
Our NSG needs a name and a region, so I will use "NSG-AVD" and select the East US. Click next, add your tags, and I'll just use the same tags we used for our virtual network earlier so we can identify all of our resources together, and then click the review and create button to complete the build.
Now that the NSG is built, we need to make some rules. It's the rules that will control the flow of traffic into or out of your subnets. So the rules should be subnet specific, which means that the rules for your AVD subnet will look different than your identity subnet; for example, you'll have active directory rules that need to be allowed between them.
Your identity inbound rules should have whatever the outbound rules from your AVD subnet are so that the rules can match. On the left, start with outbound rules. There are five rules that we need to allow Azure virtual desktop to work, and you can find those in the AVD documentation. We need to allow port 443 outbound to the Azure virtual desktop service, as well as to the Azure cloud service. Then we will need port 1688, to Azure KMS, which is required for the multi-session activation. Then we will need two specific source IPs on port 80 for health monitoring.
Back in our NSG outbound rules, click add at the top, set your source as virtual network; the source port range should be asterisk, destination should be a service tag, destination service tag should be windows virtual desktop, and note that this may be changed to Azure virtual desktop in the future. The service can stay as custom, destination port range should be 443 and the protocol should be TCP, your action should be to allow and now we have the priority. You can start as low as 100 and as high as 4,096; the lower the number, the higher the priority.
Since there might be other rules in the future that may need a higher priority than this rule, I always like to start at 1,000. Then I will create the rules in the increments of 10, just in case I need to squeeze rules in between later on. Give your rule a name and click add, repeat this for the Azure cloud service exactly like we just did, and then these last three rules will be slightly different.
First, let's deal with the Azure KMS rule; if you do a quick internet search for Azure KMS, you will find this doc showing the different instances of the Azure KMS or different Azure clouds. The one that we want for this course is the Azure global address. Copy the IP address and let's start a new NSG rule. The destination will be IP address, paste in the KMS IP that you got, the port will be 1688 and the protocol is TCP. The rule should be allowed, give your rule a name and click add. Repeat this for the last two rules using port 80, and it should all look like this. Those are the only rules needed for Azure virtual desktop to work, you will need other rules in the future for active directory communication, as well as rules to Azure storage and whatever other services you need in your environment.
Let's take a look now at the inbound security rules, click to add a new rule at the top. On the right, your source will be an IP address; use your bastion subnet of 10.0.2.0/24. Source port range will be asterisk, destination is virtual network. For the service you'll want to use RDP, this will automatically select port 3390 and the TCP protocol for you. The action should be allowed, and since this is the first rule on the inbound side, we'll use 1,000. We'll name this "the bastion rule" and click add. Once you have finished adding all of your rules, click the subnets on the left, click associate at the top, select the VNET-AVD network. In the subnets box, select AVD, and that's it. Your rules are now associated with the AVD subnet, and these will apply to all of the VMs you put in that subnet.
Dean Cefola is a Principal Azure Engineer at Microsoft and has worked in the IT industry for over 20 years. Dean has been supporting Azure Virtual Desktop from the beginning and is the Microsoft FastTrack Global Leader for AVD.