AVD User session Traffic Flow
AVD client is available for all devices and operating system so that user can login to AVD desktop from anywhere. It is important to understand AVD client session flow to open required port/IP on network firewall and useful for session troubleshooting purposes.
Connecting from AVD client to your Host Pool (session hosts in Azure Infrastructure-As-a-Service) works differently with Windows Virtual Desktop. It uses Reverse Connect, which means that no inbound ports need to be opened on the session host (backend VM) to setup the AVD connection.
See below in more depth how the traffic flow works.
This diagram shows a typical AVD client flow to AVD session host.
- User launches RD client and enter credentials which connects to Azure AD for signs in and in case 3rd party MFA is enable then the authentication with go to the MFA. Clients get a token after successful authentication (flow 1A, 1B in above diagram).
- Client presents token to Web Access to determine resources authorized for user from the metadata (check ‘configure a location for the Azure Virtual Desktop metadata’ for current metadata locations).
- User presented with the authorized resources to select in RD client.
- User selects resource by clicking on the workspace name visible in the RD client.
- RD client connects to Gateway and gateway contact broker from the same region.
- Broker orchestrates connection from host agent to Gateway
- RDP traffic now flows between RD client and session host VM over connections 6 shown in above diagram (only if RDP shortpath is not enabled on AVD)
** if RDP Shortpath is enabled then RDP Shortpath establishes the direct connectivity between Remote Desktop client and Session Host. Direct connectivity reduces the dependency on the Azure Virtual Desktop gateways, improves the connection’s reliability, and increases the bandwidth available for each user session.
- Once the connection flow proceeds, bidirectional communication between your session hosts/host pool will go over port https (443).
AVD User session Traffic Flow with RDP Shortpath
RDP Shortpath needs direct line of sight to the session host from RD client. The direct line of sight means that firewalls aren’t blocking UDP port 3390 and the client can connect directly to the session host using RDP.
You can get a direct line of sight by using one of the following technologies:
- ExpressRoute
- Site-to-Site or Point-to-Site VPN
- Public IP address assignment on session host (I don’t recommend)
The diagram below gives a high-level overview of the RDP Shortpath network connection.
- AVD client authentication and selecting authorized resources flow is same with/without RD shortpath.
- The session host sends IPv4 and IPv6 addresses (private or public whichever applicable) to the client.
- The client starts parallel UDP-based transport connection directly to one of the host’s IP addresses (private or public whichever applicable).
- While the client is probing the provided IP addresses, it continues the initial connection establishment over the reverse connect transport to ensure no delay in the user connection.
- If the client has a direct line of sight and the all firewall configuration is correct, the client establishes a secure TLS connection with session host.
- After establishing the Shortpath transport, RDP moves all Dynamic Virtual Channels (DVCs), including remote graphics, input, and device redirection to the new transport.
- If a firewall or network topology prevents the client from establishing direct UDP connectivity, RDP continues with a reverse connect transport.
