Understanding Azure Virtual Desktop network connectivity
Azure Virtual Desktop provides the ability to host 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 below gives a high-level overview of the network connections used by Azure Virtual Desktop
Azure Virtual Desktop uses Remote Desktop Protocol (RDP) to provide remote display and input capabilities over network connections. RDP was initially released with Windows NT 4.0 Terminal Server Edition and was continuously evolving with every Microsoft Windows and Windows Server release. From the beginning, RDP developed to be independent of its underlying transport stack, and today it supports multiple types of transport.
Reverse connect transport
Azure Virtual Desktop is using 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 session host and Azure Virtual Desktop infrastructure.
Client connection sequence
Client connection sequence described below:
- Using supported Azure Virtual Desktop client user subscribes to the Azure Virtual Desktop Workspace
- Microsoft Entra authenticates the user and returns the token used to enumerate resources available to a user
- Client passes token to the Azure Virtual Desktop feed subscription service
- Azure Virtual Desktop feed subscription service validates the token
- Azure Virtual Desktop feed subscription service passes the list of available desktops and applications back to the client in the form of digitally signed connection configuration
- Client stores the connection configuration for each available resource in a set of .rdp files
- When a user selects the resource to connect, the client uses the associated .rdp file and establishes the secure TLS 1.2 connection to an Azure Virtual Desktop gateway instance with the help of Azure Front Door and passes the connection information. The latency from all gateways is evaluated, and the gateways are put into groups of 10ms. The gateway with the lowest latency and then lowest number of existing connections is chosen.
- Azure Virtual Desktop gateway validates the request and asks the Azure Virtual Desktop broker to orchestrate the connection
- Azure Virtual Desktop broker identifies the session host and uses the previously established persistent communication channel to initialize the connection
- Remote Desktop stack initiates the TLS 1.2 connection to the same Azure Virtual Desktop gateway instance as used by the client
- After both client and session host connected to the gateway, the gateway starts relaying the raw data between both endpoints, this establishes the base reverse connect transport for the RDP
- After the base transport is set, the client starts the RDP handshake
TLS 1.2 is used for all connections initiated from the clients and session hosts to the Azure Virtual Desktop infrastructure components. Azure Virtual Desktop uses the same TLS 1.2 ciphers as Azure Front Door. It's important to make sure both client computers and session hosts can use these ciphers. For reverse connect transport, both client and session host connect to the Azure Virtual Desktop gateway. After establishing the TCP connection, the client or session host validates the Azure Virtual Desktop gateway's certificate. After establishing the base transport, RDP establishes a nested TLS connection between client and session host using the session host's certificates. By default, the certificate used for RDP encryption is self-generated by the OS during the deployment. If desired, customers may deploy centrally managed certificates issued by the enterprise certification authority. For more information about configuring certificates, see Windows Server documentation.
- To learn about bandwidth requirements for Azure Virtual Desktop, see Understanding Remote Desktop Protocol (RDP) Bandwidth Requirements for Azure Virtual Desktop.
- To get started with Quality of Service (QoS) for Azure Virtual Desktop, see Implement Quality of Service (QoS) for Azure Virtual Desktop.