RDP Shortpath establishes a UDP-based transport between a local device Windows App or the Remote Desktop app on supported platforms and session host in Azure Virtual Desktop. By default, the Remote Desktop Protocol (RDP) begins a TCP-based reverse connect transport, then tries to establish a remote session using UDP. If the UDP connection succeeds the TCP connection drops, otherwise the TCP connection is used as a fallback connection mechanism.
UDP-based transport offers better connection reliability and more consistent latency. TCP-based reverse connect transport provides the best compatibility with various networking configurations and has a high success rate for establishing RDP connections.
RDP Shortpath can be used in two ways:
Managed networks, where direct connectivity is established between the client and the session host when using a private connection, such as Azure ExpressRoute or a site-to-site virtual private network (VPN). A connection using a managed network is established in one of the following ways:
A direct UDP connection between the client device and session host, where you need to enable the RDP Shortpath listener and allow an inbound port on each session host to accept connections.
A direct UDP connection between the client device and session host, using the Simple Traversal Underneath NAT (STUN) protocol between a client and session host. Inbound ports on the session host aren't required to be allowed.
Public networks, where direct connectivity is established between the client and the session host when using a public connection. There are two connection types when using a public connection, which are listed here in order of preference:
A direct UDP connection using the Simple Traversal Underneath NAT (STUN) protocol between a client and session host.
An relayed UDP connection using the Traversal Using Relay NAT (TURN) protocol between a client and session host.
The transport used for RDP Shortpath is based on the Universal Rate Control Protocol (URCP). URCP enhances UDP with active monitoring of the network conditions and provides fair and full link utilization. URCP operates at low delay and loss levels as needed.
Important
- Azure cloud: RDP Shortpath for public networks via STUN and TURN is generally available.
- Azure cloud for Government: RDP Shortpath via STUN and TURN is available in public preview with **dedicated servers with IP range **20.140.236.0/22. Customers can try the feature for the session host in validation ring.
Key benefits
Using RDP Shortpath has the following key benefits:
Using URCP to enhance UDP achieves the best performance by dynamically learning network parameters and providing the protocol with a rate control mechanism.
Higher throughput.
When using STUN, the removal of extra relay points reduces round-trip time improves connection reliability and the user experience with latency-sensitive applications and input methods.
In addition, for managed networks:
RDP Shortpath brings support for configuring Quality of Service (QoS) priority for RDP connections through Differentiated Services Code Point (DSCP) marks.
The RDP Shortpath transport allows limiting outbound network traffic by specifying a throttle rate for each session.
How RDP Shortpath works
To learn how RDP Shortpath works for managed networks and public networks, select each of the following tabs.
You can achieve the direct line of sight connectivity required to use RDP Shortpath with managed networks using the following methods.
Having direct line of sight connectivity means that the client can connect directly to the session host without being blocked by firewalls.
Note
If you're using other VPN types to connect to Azure, we recommend using a UDP-based VPN. While most TCP-based VPN solutions support nested UDP, they add inherited overhead of TCP congestion control, which slows down RDP performance.
To use RDP Shortpath for managed networks, you must enable a UDP listener on your session hosts. By default, port 3390 is used, although you can use a different port.
The following diagram gives a high-level overview of the network connections when using RDP Shortpath for managed networks and session hosts joined to an Active Directory domain.
Connection sequence
All connections begin by establishing a TCP-based reverse connect transport over the Azure Virtual Desktop Gateway. Then, the client and session host establish the initial RDP transport, and start exchanging their capabilities. These capabilities are negotiated using the following process:
The session host sends the list of its IPv4 and IPv6 addresses to the client.
The client starts the background thread to establish a parallel UDP-based transport directly to one of the session host's IP addresses.
While the client is probing the provided IP addresses, it continues to establish the initial connection over the reverse connect transport to ensure there's no delay in the user connection.
If the client has a direct connection to the session host, the client establishes a secure connection using TLS over reliable UDP.
After establishing the RDP Shortpath transport, all Dynamic Virtual Channels (DVCs), including remote graphics, input, and device redirection, are moved to the new transport. However, if a firewall or network topology prevents the client from establishing direct UDP connectivity, RDP continues with a reverse connect transport.
If your users have both RDP Shortpath for managed network and public networks available to them, then the first-found algorithm will be used. The user will use whichever connection gets established first for that session.
To provide the best chance of a UDP connection being successful when using a public connection, there are the direct and relayed connection types:
Direct connection: STUN is used to establish a direct UDP connection between a client and session host. To establish this connection, the client and session host must be able to connect to each other through a public IP address and negotiated port. However, most clients don't know their own public IP address as they sit behind a Network Address Translation (NAT) gateway device. STUN is a protocol for the self-discovery of a public IP address from behind a NAT gateway device and the client to determine its own public-facing IP address.
For a client to use STUN, its network must allow UDP traffic. Assuming both the client and session host can route to the other's discovered IP address and port directly, communication is established with direct UDP over the WebSocket protocol. If firewalls or other network devices block direct connections, a relayed UDP connection is tried.
Relayed connection: TURN is used to establish a connection, relaying traffic through an intermediate server between a client and session host when a direct connection isn't possible. TURN is an extension of STUN. Using TURN means the public IP address and port is known in advance, which can be allowed through firewalls and other network devices.
If firewalls or other network devices block UDP traffic, the connection will fall back to a TCP-based reverse connect transport.
When a connection is being established, Interactive Connectivity Establishment (ICE) coordinates the management of STUN and TURN to optimize the likelihood of a connection being established, and ensure that precedence is given to preferred network communication protocols.
Each RDP session uses a dynamically assigned UDP port from an ephemeral port range (49152 to 65535 by default) that accepts the RDP Shortpath traffic. Port 65330 is ignored from this range as it is reserved for use internally by Azure. You can also use a smaller, predictable port range. For more information, see Limit the port range used by clients for public networks.
Tip
RDP Shortpath for public networks will work automatically without any additional configuration, providing networks and firewalls allow the traffic through and RDP transport settings in the Windows operating system for session hosts and clients are using their default values.
The following diagram gives a high-level overview of the network connections when using RDP Shortpath for public networks where session hosts joined to Microsoft Entra ID.
TURN relay availability
TURN relay is available in the following Azure regions with ACS TURN Relay (51.5.0.0/16):
- Australia Central
- Australia East
- Australia Southeast
- Brazil South
- Canada Central
- Canada East
- Central India
- Central US
- East US
- East US 2
- France Central
- Germany West Central
- Israel Central
- Japan East
- Japan West
- Korea Central
- Korea South
- Mexico Central
- North Central US
- North Europe
- Norway West
- South Africa North
- South Africa West
- South Central US
- Southeast Asia
- South India
- Spain Central
- Switzerland North
- Tawain North
- Tawain Northeast
- UAE Central
- UAE North
- UK South
- UK West
- West Central US
- West Europe
- West US
- West US 2
- West US 3
A TURN relay is selected based on the physical location of the client device. For example, if a client device is in the UK, the TURN relay in the UK South or UK West region is selected. If a client device is far from a TURN relay, the UDP connection might fall back to TCP.
Network Address Translation and firewalls
Most Azure Virtual Desktop clients run on computers on the private network. Internet access is provided through a Network Address Translation (NAT) gateway device. Therefore, the NAT gateway modifies all network requests from the private network and destined to the Internet. Such modification intends to share a single public IP address across all of the computers on the private network.
Because of IP packet modification, the recipient of the traffic will see the public IP address of the NAT gateway instead of the actual sender. When traffic comes back to the NAT gateway, it will take care to forward it to the intended recipient without the sender's knowledge. In most scenarios, the devices hidden behind such a NAT aren't aware translation is happening and don't know the network address of the NAT gateway.
NAT is applicable to the Azure Virtual Networks where all session hosts reside. When a session host tries to reach the network address on the Internet, the NAT Gateway (either your own or default provided by Azure), or Azure Load Balancer performs the address translation. For more information about various types of Source Network Address Translation, see Use Source Network Address Translation (SNAT) for outbound connections.
Most networks typically include firewalls that inspect traffic and block it based on rules. Most customers configure their firewalls to prevent incoming connections (that is, unsolicited packets from the Internet sent without a request). Firewalls employ different techniques to track data flow to distinguish between solicited and unsolicited traffic. In the context of TCP, the firewall tracks SYN and ACK packets, and the process is straightforward. UDP firewalls usually use heuristics based on packet addresses to associate traffic with UDP flows and allow or block it. There are many different NAT implementations available.
Connection sequence
All connections begin by establishing a TCP-based reverse connect transport over the Azure Virtual Desktop Gateway. Then, the client and session host establish the initial RDP transport, and start exchanging their capabilities. If RDP Shortpath for public networks is enabled on the session host, the session host then initiates a process called candidate gathering:
The session host enumerates all network interfaces assigned to a session host, including virtual interfaces like VPN and Teredo.
The Windows service Remote Desktop Services (TermService) allocates UDP sockets on each interface and stores the IP:Port pair in the candidate table as a local candidate.
The Remote Desktop Services service uses each UDP socket allocated in the previous step to try reaching the Azure Virtual Desktop STUN Server on the public internet. Communication is done by sending a small UDP packet to port 3478.
If the packet reaches the STUN server, the STUN server responds with the public IP and port. This information is stored in the candidate table as a reflexive candidate.
After the session host gathers all the candidates, the session host uses the established reverse connect transport to pass the candidate list to the client.
When the client receives the list of candidates from the session host, the client also performs candidate gathering on its side. Then the client sends its candidate list to the session host.
After the session host and client exchange their candidate lists, both parties attempt to connect with each other using all the gathered candidates. This connection attempt is simultaneous on both sides. Many NAT gateways are configured to allow the incoming traffic to the socket as soon as the outbound data transfer initializes it. This behavior of NAT gateways is the reason the simultaneous connection is essential. If STUN fails because it's blocked, a relayed connection attempt is made using TURN.
After the initial packet exchange, the client and session host may establish one or many data flows. From these data flows, RDP chooses the fastest network path. The client then establishes a secure connection using TLS over reliable UDP with the session host and initiates RDP Shortpath transport.
After RDP establishes the RDP Shortpath transport, all Dynamic Virtual Channels (DVCs), including remote graphics, input, and device redirection move to the new transport.
If your users have both RDP Shortpath for managed network and public networks available to them, then the first-found algorithm will be used, meaning that the user will use whichever connection gets established first for that session. For more information, see example scenario 4.
Network configuration
To support RDP Shortpath for public networks, you typically don't need any particular configuration. The session host and client will automatically discover the direct data flow if it's possible in your network configuration. However, every environment is unique, and some network configurations may negatively affect the rate of success of the direct connection. Follow the recommendations to increase the probability of a direct data flow.
As RDP Shortpath uses UDP to establish a data flow, if a firewall on your network blocks UDP traffic, RDP Shortpath will fail and the connection will fall back to TCP-based reverse connect transport. Azure Virtual Desktop uses STUN servers provided by Azure Communication Services and Microsoft Teams. By the nature of the feature, outbound connectivity from the session hosts to the client is required. Unfortunately, you can't predict where your users are located in most cases. Therefore, we recommend allowing outbound UDP connectivity from your session hosts to the internet. To reduce the number of ports required, you can limit the port range used by clients for the UDP flow. Use the following tables for reference when configuring firewalls for RDP Shortpath.
If your environment uses Symmetric NAT, which is the mapping of a single private source IP:Port to a unique public destination IP:Port, then you can use a relayed connection with TURN. This will be the case if you use Azure Firewall and Azure NAT Gateway. For more information about NAT with Azure virtual networks, see Source Network Address Translation with virtual networks.
We have some general recommendations for successful connections using RDP Shortpath for public networks. For more information, see General recommendations.
Where users have RDP Shortpath for both managed network and public networks is available to them, then the first algorithm found will be used. The user will use whichever connection gets established first for that session. For more information, see Example scenarios.
The following sections contain the source, destination and protocol requirements for your session hosts and client devices that must be allowed for RDP Shortpath to work.
Note
Microsoft has completed the transition from the previously shared 20.202.0.0/16 subnet to the new 51.5.0.0/16 TURN relay IP range across 39 Azure regions. This new range is dedicated exclusively to Azure Virtual Desktop and Windows 365, separating it from the Azure Communication Services infrastructure. The upgrade is designed to enhance RDP Shortpath for Public Networks (via TURN/Relay), delivering faster, more reliable connectivity and an improved user experience.
Note
TURN‑based connections are susceptible to connection drops during TURN relay updates. These updates typically occur during planned maintenance windows but may occasionally occur outside the planned window due to urgent Azure infrastructure fixes. In all of the above scenarios, the client automatically reconnects within a few seconds.
Session host virtual network
The following table details the source, destination and protocol requirements for RDP Shortpath for your session host virtual network.
| Name |
Source |
Source Port |
Destination |
Destination Port |
Protocol |
Action |
| STUN direct connection |
VM subnet |
Any |
Any |
1024-65535
(default 49152-65535) |
UDP |
Allow |
| STUN/TURN Relay |
VM subnet |
Any |
51.5.0.0/16 |
3478 |
UDP |
Allow |
Client network
The following table details the source, destination and protocol requirements for your client devices.
| Name |
Source |
Source Port |
Destination |
Destination Port |
Protocol |
Action |
| STUN direct connection |
Client network |
Any |
Public IP addresses assigned to NAT Gateway or Azure Firewall (provided by the STUN endpoint) |
1024-65535
(default 49152-65535) |
UDP |
Allow |
| STUN/TURN relay |
Client network |
Any |
51.5.0.0/16 |
3478 |
UDP |
Allow |
Important
The dedicated TURN relay IP range for Azure Government is 20.140.236.0/22. RDP Shortpath via TURN is currently in public preview in Azure Government. Customers can try the feature by using the validation ring.
Session host virtual network
The following table details the source, destination and protocol requirements for RDP Shortpath for your session host virtual network.
| Name |
Source |
Source port |
Destination |
Destination port |
Protocol |
Action |
| STUN direct connection |
VM subnet |
Any |
Any |
1024-65535
(default: 49152-65535) |
UDP |
Allow |
| STUN/TURN relay |
VM subnet |
Any |
20.140.236.0/22 |
3478 |
UDP |
Allow |
Client network
The following table details the source, destination and protocol requirements for your client devices.
| Name |
Source |
Source port |
Destination |
Destination port |
Protocol |
Action |
| STUN direct connection |
Client network |
Any |
Public IP addresses assigned to NAT Gateway or Azure Firewall (provided by the STUN endpoint) |
1024-65535
(default: 49152-65535) |
UDP |
Allow |
| STUN/TURN relay |
Client network |
Any |
20.140.236.0/22 |
3478 |
UDP |
Allow |
Teredo support
While not required for RDP Shortpath, Teredo adds extra NAT traversal candidates and increases the chance of the successful RDP Shortpath connection in IPv4-only networks. To learn how to enable Teredo on session hosts and clients, see Enable Teredo support.
UPnP support
To improve the chances of a direct connection, on the side of the Remote Desktop client, RDP Shortpath may use UPnP to configure a port mapping on the NAT router. UPnP is a standard technology used by various applications, such as Xbox, Delivery Optimization, and Teredo. UPnP is generally available on routers typically found on a home network. UPnP is enabled by default on most home routers and access points, but is often disabled on corporate networking.
General recommendations
Here are some general recommendations when using RDP Shortpath for public networks:
Avoid using force tunneling configurations if your users access Azure Virtual Desktop over the Internet.
Make sure you aren't using double NAT or Carrier-Grade-NAT (CGN) configurations.
Recommend to your users that they don't disable UPnP on their home routers.
Avoid using cloud packet-inspection Services.
Avoid using TCP-based VPN solutions.
Enable IPv6 connectivity or Teredo.
Connection security
RDP Shortpath extends RDP multi-transport capabilities. It doesn't replace the reverse connect transport but complements it. Initial session brokering is managed through the Azure Virtual Desktop service and the reverse connect transport. All connection attempts are ignored unless they match the reverse connect session first. RDP Shortpath is established after authentication, and if successfully established, the reverse connect transport is dropped and all traffic flows over the RDP Shortpath.
RDP Shortpath uses a secure connection using TLS over reliable UDP between the client and the session host using the session host's certificates. By default, the certificate used for RDP encryption is self-generated by the operating system during the deployment. Azure Virtual Desktop doesn’t support the use of a certificate issued from a certificate authority at this time.
Example scenarios
Here are some example scenarios to show how connections are evaluated to decide whether RDP Shortpath is used across different network topologies.
Scenario 1
A UDP connection can only be established between the client device and the session host over a public network (internet). A direct connection, such as a VPN, isn't available. UDP is allowed through firewall or NAT device.
Scenario 2
A firewall or NAT device is blocking a direct UDP connection, but a relayed UDP connection can be relayed using TURN between the client device and the session host over a public network (internet). Another direct connection, such as a VPN, isn't available.
Scenario 3
A UDP connection can be established between the client device and the session host over a public network or over a direct VPN connection, but RDP Shortpath for managed networks isn't enabled. When the client initiates the connection, the ICE/STUN protocol can see multiple routes and will evaluate each route and choose the one with the lowest latency.
In this example, a UDP connection using RDP Shortpath for public networks over the direct VPN connection will be made as it has the lowest latency, as shown by the green line.
Scenario 4
Both RDP Shortpath for public networks and managed networks are enabled. A UDP connection can be established between the client device and the session host over a public network or over a direct VPN connection. When the client initiates the connection, there are simultaneous attempts to connect using RDP Shortpath for managed networks through port 3390 (by default) and RDP Shortpath for public networks through the ICE/STUN protocol. The first-found algorithm will be used and the user will use whichever connection gets established first for that session.
Since going over a public network has more steps, for example a NAT device, a load balancer, or a STUN server, it's likely that the first-found algorithm will select the connection using RDP Shortpath for managed networks and be established first.
Scenario 5
A UDP connection can be established between the client device and the session host over a public network or over a direct VPN connection, but RDP Shortpath for managed networks isn't enabled. To prevent ICE/STUN from using a particular route, an admin can block one of the routes for UDP traffic. Blocking a route would ensure the remaining path is always used.
In this example, UDP is blocked on the direct VPN connection and the ICE/STUN protocol establishes a connection over the public network.
Scenario 6
Both RDP Shortpath for public networks and managed networks are configured, however a UDP connection couldn't be established using direct VPN connection. A firewall or NAT device is also blocking a direct UDP connection using the public network (internet), but a relayed UDP connection can be relayed using TURN between the client device and the session host over a public network (internet).
Scenario 7
Both RDP Shortpath for public networks and managed networks are configured, however a UDP connection couldn't be established. In this instance, RDP Shortpath will fail and the connection will fall back to TCP-based reverse connect transport.
Next steps
