Azure Private Link with Azure Virtual Desktop

  • Article

You can use Azure Private Link with Azure Virtual Desktop to privately connect to your remote resources. By creating a private endpoint, traffic between your virtual network and the service remains on the Azure network, so you no longer need to expose your service to the public internet. You also use a VPN or ExpressRoute for your users with the Remote Desktop client to connect to the virtual network. Keeping traffic within the Azure network improves security and keeps your data safe. This article describes how Private Link can help you secure your Azure Virtual Desktop environment.

Azure Virtual Desktop has three workflows with three corresponding resource types to use with private endpoints. These workflows are:

  1. Initial feed discovery: lets the client discover all workspaces assigned to a user. To enable this process, you must create a single private endpoint to the global sub-resource to any workspace. However, you can only create one private endpoint in your entire Azure Virtual Desktop deployment. This endpoint creates Domain Name System (DNS) entries and private IP routes for the global fully qualified domain name (FQDN) needed for initial feed discovery. This connection becomes a single, shared route for all clients to use.

  2. Feed download: the client downloads all connection details for a specific user for the workspaces that host their application groups. You create a private endpoint for the feed sub-resource for each workspace you want to use with Private Link.

  3. Connections to host pools: every connection to a host pool has two sides - clients and session hosts. You need to create a private endpoint for the connection sub-resource for each host pool you want to use with Private Link.

The following high-level diagram shows how Private Link securely connects a local client to the Azure Virtual Desktop service. For more detailed information about client connections, see Client connection sequence.

A high-level diagram that shows Private Link connecting a local client to the Azure Virtual Desktop service.

Supported scenarios

When adding Private Link with Azure Virtual Desktop, you have the following supported scenarios to connect to Azure Virtual Desktop. Which scenario you choose depends on your requirements. You can either share these private endpoints across your network topology or you can isolate your virtual networks so that each has their own private endpoint to the host pool or workspace.

  1. All parts of the connection - initial feed discovery, feed download, and remote session connections for clients and session hosts - use private routes. You need the following private endpoints:

    Purpose Resource type Target sub-resource Endpoint quantity
    Connections to host pools Microsoft.DesktopVirtualization/hostpools connection One per host pool
    Feed download Microsoft.DesktopVirtualization/workspaces feed One per workspace
    Initial feed discovery Microsoft.DesktopVirtualization/workspaces global Only one for all your Azure Virtual Desktop deployments

  2. Feed download and remote session connections for clients and session hosts use private routes, but initial feed discovery uses public routes. You need the following private endpoints. The endpoint for initial feed discovery isn't required.

    Purpose Resource type Target sub-resource Endpoint quantity
    Connections to host pools Microsoft.DesktopVirtualization/hostpools connection One per host pool
    Feed download Microsoft.DesktopVirtualization/workspaces feed One per workspace

  3. Only remote session connections for clients and session hosts use private routes, but initial feed discovery and feed download use public routes. You need the following private endpoint(s). Endpoints to workspaces aren't required.

    Purpose Resource type Target sub-resource Endpoint quantity
    Connections to host pools Microsoft.DesktopVirtualization/hostpools connection One per host pool

  4. Both clients and session host VMs use public routes. Private Link isn't used in this scenario.

Important

  • If you create a private endpoint for initial feed discovery, the workspace used for the global sub-resource governs the shared Fully Qualified Domain Name (FQDN), facilitating the initial discovery of feeds across all workspaces. You should create a separate workspace that is only used for this purpose and doesn't have any application groups registered to it. Deleting this workspace will cause all feed discovery processes to stop working.

  • You can't control access to the workspace used for the initial feed discovery (global sub-resource). If you configure this workspace to only allow private access, the setting is ignored. This workspace is always accessible from public routes.

  • IP address allocations are subject to change as the demand for IP addresses increases. During capacity expansions, additional addresses are needed for private endpoints. It's important you consider potential address space exhaustion and ensure sufficient headroom for growth. For more information on determining the appropriate network configuration for private endpoints in either a hub or a spoke topology, see Decision tree for Private Link deployment.

Configuration outcomes

You configure settings on the relevant Azure Virtual Desktop workspaces and host pools to set public or private access. For connections to a workspace, except the workspace used for initial feed discovery (global sub-resource), the following table details the outcome of each scenario:

Configuration Outcome
Public access enabled from all networks Workspace feed requests are allowed from public routes.

Workspace feed requests are allowed from private routes.
Public access disabled from all networks Workspace feed requests are denied from public routes.

Workspace feed requests are allowed from private routes.

With the reverse connect transport, there are two network connections for connections to host pools: the client to the gateway, and the session host to the gateway. In addition to enabling or disabling public access for both connections, you can also choose to enable public access for clients connecting to the gateway and only allow private access for session hosts connecting to the gateway. The following table details the outcome of each scenario:

Configuration Outcome
Public access enabled from all networks Remote sessions are allowed when either the client or session host is using a public route.

Remote sessions are allowed when either the client or session host is using a private route.
Public access disabled from all networks Remote sessions are denied when either the client or session host is using a public route.

Remote sessions are allowed when both the client and session host are using a private route.
Public access enabled for client networks, but disabled for session host networks Remote sessions are denied if the session host is using a public route, regardless of the route the client is using.

Remote sessions are allowed as long as the session host is using a private route, regardless of the route the client is using.

Client connection sequence

When a user connects to Azure Virtual Desktop over Private Link, and Azure Virtual Desktop is configured to only allow client connections from private routes, the connection sequence is as follows:

  1. With a supported client, a user subscribes to a workspace. The user's device queries DNS for the address rdweb.wvd.azure.cn (or the corresponding address for other Azure environments).

  2. Your private DNS zone for privatelink-global.wvd.azure.cn returns the private IP address for the initial feed discovery (global sub-resource). If you're not using a private endpoint for initial feed discovery, a public IP address is returned.

  3. For each workspace in the feed, a DNS query is made for the address <workspaceId>.privatelink.wvd.azure.cn.

  4. Your private DNS zone for privatelink.wvd.azure.cn returns the private IP address for the workspace feed download, and downloads the feed using TCP port 443.

  5. When connecting to a remote session, the .rdp file that comes from the workspace feed download contains the address for the Azure Virtual Desktop gateway service with the lowest latency for the user's device. A DNS query is made to an address in the format <hostpooId>.afdfp-rdgateway.wvd.azure.cn.

  6. Your private DNS zone for privatelink.wvd.azure.cn returns the private IP address for the Azure Virtual Desktop gateway service to use for the host pool providing the remote session. Orchestration through the virtual network and the private endpoint uses TCP port 443.

  7. Following orchestration, the network traffic between the client, Azure Virtual Desktop gateway service, and session host is transferred over to a port in the TCP dynamic port range of 1 - 65535.

Important

If you intend to restrict network ports from either the user client devices or your session host VMs to the private endpoints, you will need to allow traffic across the entire TCP dynamic port range of 1 - 65535 to the private endpoint for the host pool resource using the connection sub-resource. The entire TCP dynamic port range is needed because Azure private networking internally maps these ports to the appropriate gateway that was selected during client orchestration. If you restrict ports to the private endpoint, your users may not be able to connect to Azure Virtual Desktop.

Known issues and limitations

Private Link with Azure Virtual Desktop has the following limitations:

  • Before you use Private Link for Azure Virtual Desktop, you need to enable Private Link with Azure Virtual Desktop on each Azure subscription you want to Private Link with Azure Virtual Desktop.

  • All Remote Desktop clients to connect to Azure Virtual Desktop can be used with Private Link. If you're using the Remote Desktop client for Windows on a private network without internet access and you're subscribed to both public and private feeds, you aren't able to access your feed.

  • After you've changed a private endpoint to a host pool, you must restart the Remote Desktop Agent Loader (RDAgentBootLoader) service on each session host in the host pool. You also need to restart this service whenever you change a host pool's network configuration. Instead of restarting the service, you can restart each session host.

  • Using both Private Link and RDP Shortpath for managed networks isn't supported, but they can work together. You can use Private Link and RDP Shortpath for managed networks at your own risk. All other RDP Shortpath options using STUN or TURN aren't supported with Private Link.

  • Early in the preview of Private Link with Azure Virtual Desktop, the private endpoint for the initial feed discovery (for the global sub-resource) shared the private DNS zone name of privatelink.wvd.azure.cn with other private endpoints for workspaces and host pools. In this configuration, users are unable to establish private endpoints exclusively for host pools and workspaces. Starting September 1, 2023, sharing the private DNS zone in this configuration will no longer be supported. You need to create a new private endpoint for the global sub-resource to use the private DNS zone name of privatelink-global.wvd.azure.cn. For the steps to do this, see Initial feed discovery.

Next steps