Optimization of RDP traffic

Remote Desktop Protocol (RDP) traffic is critical for Windows 365 Cloud PC performance and reliability. To optimize connectivity, you must configure the network path on both the physical device and the Cloud PC. RDP traffic behaves like Teams media traffic: it's real-time, latency-sensitive, and high-volume with long-lived connections. Optimization methods therefore closely mirror those used for Teams.

While this guidance focuses on the following core RDP methods that work in all network environments, it's also applicable to any available option.

• TCP-based Reverse Connect

• Indirect RDP Shortpath via TURN

To learn more about the different RDP options available for Windows 365 and how they work, see Understanding Network Flows - RDP Connectivity.

If RDP traffic isn't optimized, the default network path for web-bound traffic in many enterprise networks can significantly affect the user experience. Common issues include:

• Reduced performance

• Frequent disconnects

• Disconnects during initial logon

• Slow input response

Optimization steps apply to both the physical client and the Cloud PC, with minor differences in implementation.

Key Optimization steps

1. Disabling TLS inspection

Inspection of RDP traffic is not supported. Disable TLS inspection for all required endpoints.

Why disable TLS inspection?

• Double encryption: RDP traffic uses nested encryption. A Transport Layer Security (TLS) 1.3 transport session carries an encrypted RDP session. Inspecting the transport session provides no security benefit but introduces significant negative impact.

• Dedicated infrastructure: TCP-based RDP via gateways and UDP via TURN relays use Microsoft-owned, globally distributed infrastructure. This infrastructure uses dedicated IPv4 space exclusively for Windows 365, Azure Virtual Desktop, and Devbox.

• No impact on security: RDP only connects the physical device to the Cloud PC. You can still inspect internet-bound traffic on both devices according to your normal standards.

Impact of inspection

• Adds jitter: Variation in packet arrival times reduces quality.

• Adds latency: Increased packet traversal time affects desktop responsiveness.

• Reduces throughput: Due to the nature of TLS inspection, it can significantly reduce throughput on the connection, impacting performance.

• Increases device load: RDP traffic is high-volume. Inspection is computationally expensive and may degrade other traffic using the device performing the inspection. Scaling to handle inspection adds cost without benefit.

2. Bypass VPN and Secure Web Gateway tunnels

Many Windows 365 and Azure Virtual Desktop (AVD) deployments use Virtual Private Network (VPN) or Secure Web Gateway (SWG) clients to provide secure access to on-premises resources and protected internet access. Using such configuration is especially common in the recommended Microsoft Hosted Network model, where Cloud PCs have direct, high-speed internet connectivity and where network controls applied can be almost identical to controls used for roaming users.

Modern SWG solutions align with Zero Trust principles and generally outperform traditional VPN approaches, which route internet traffic through on-premises proxies. However, these solutions still introduce challenges for latency-sensitive traffic such as RDP.

If VPN or SWG tunnels aren't configured correctly, users may experience:

• Increased latency and reduced performance

• Disconnects during initial logon

• Session drops when tunnels reset

• Frequent RDP disconnects

Example issue: RDP Connection drops on initial logon:

A common symptom of RDP traffic routed through a Secure Web Gateway (SWG) or VPN tunnel is a disconnect during the initial logon to the Cloud PC when user-based tunnels are enabled.

What happens

• The user starts a connection, and the Cloud PC responds. The logon screen appears as normal.

• After the user enters credentials, the client software builds user-based tunnels to the SWG or VPN.

• At this point, the logon screen freezes. The connection drops, and the client must reconnect to the Cloud PC.

• After reconnection, the session usually works without further problems. However, if the tunnel drops later, the remote session disconnects again.

This behavior creates a poor experience, especially during initial login.

Why the disconnect happens

User-based tunnels often route all internet-bound traffic through the SWG or VPN unless the endpoint is configured for bypass. This configuration is called a forced tunnel or inverse split tunnel, and the tunnel becomes the default path.

The initial login succeeds because the tunnel isn’t active yet. When the tunnel starts as the user logs in, RDP traffic is redirected into the tunnel, which forces a reconnection. If the tunnel drops and reconnects during operation, the RDP session must also reconnect inside the re-established tunnel.

The following diagram shows a simplified view of this indirect connectivity with a forced tunnel. RDP traffic traverses VPN or SWG resources before reaching the gateway. This routing is acceptable for general web traffic but isn’t optimal for latency-sensitive traffic such as Teams media or RDP. On the Cloud PC side, lack of optimization also means the RDP traffic may need to leave Microsoft's network and traverse back again from the SWG or VPN solution's location.

Diagram 1: Non-Optimized RDP traffic hairpinned via Secure Web Gateway

Solution: Bypass RDP traffic from VPN or SWG tunnels

Forced tunnel exceptions for RDP traffic are essential. This configuration ensures:

• Direct routing for latency-sensitive traffic to maintain consistent, high performance

• No dependency on tunnel state for reliable connectivity

On the Cloud PC side, traffic stays on the Microsoft network and doesn’t need to traverse the internet.

With the bypass in place, web-bound traffic still uses the SWG or VPN tunnel, but RDP takes the optimized path as shown in the following diagram.

Diagram 2: Optimized TCP based RDP traffic sent direct to Windows 365 Gateway

3. Local Network egress

Local egress is a key step in optimizing RDP traffic. It ensures traffic takes the most direct route to Microsoft’s edge network.

Cloud side

Local egress from Azure reduces round-trip time by avoiding unnecessary hops through remote locations. This approach improves session responsiveness and stability. When you locally egress RDP directly onto Microsoft's network, through a NAT Gateway, for example, traffic stays on Microsoft's network to the Gateway or TURN relay for its complete journey.

Physical side

Local breakout to the internet as close as possible to the user prevents traffic from backhauling through corporate networks, VPNs, Secure Web Gateways (SWGs). With this optimization, reaching the internet locally to the user, the nearest Gateway or TURN relay can be used, avoiding routing through non-local RDP Gateways or TURN relays which are nearer to the VPN or SWG's location, than the end user. Using these remote Gateways or Relays can add significant latency and reliability issues.

Benefits

By enabling local egress, you minimize latency, reduce packet loss caused by congested tunnels, and deliver a smoother, more reliable user experience.

When RDP traffic egresses locally, it connects to the nearest RDP Gateway or TURN relay, usually close to the user’s location. From there, traffic travels across Microsoft’s managed backbone to the Cloud PC and back. This means traffic is on the public internet only for a short distance, improving security and performance.

For more information on Microsoft’s globally distributed infrastructure for RDP optimization, see this article.

Implementing Optimization

How you implement these optimizations may differ slightly depending on which side of the connection you're configuring.

Physical Device-Side Optimization

Follow these steps to ensure RDP traffic takes the most direct, reliable, and high‑performance path.

1. Identify the key RDP endpoint information: This information is displayed in the following table, but is the same for both the physical and Cloud PC sides. Always refer to the Network Requirements documentation for the latest details.

ID	FQDN	IP	Protocol/Port	Purpose
1	*.wvd.microsoft.com	40.64.144.0/20 (covers RDP flow within the FQDN but not everything within the wildcard domain)	TCP/443	TCP Based RDP Connectivity
2	n/a	51.5.0.0/16	UDP/3478	UDP Based RDP via TURN

Note

The 40.64.144.0/20 subnet covers the RDP flow associated with *.wvd.microsoft.com but not every endpoint within *.wvd.microsoft.com

1. Bypass VPN and Secure Web Gateway (SWG) tunnels: Route RDP traffic directly to the internet. Avoid sending it through proxies, VPNs, or SWGs. Microsoft owns and manages both IP subnets listed in the table, and they’re dedicated to Windows 365 and Azure Virtual Desktop.

2. Enable local egress Ensure traffic exits the network as close to the user as possible. Avoid backhauling traffic across long distances before reaching the internet. Doing so allows the nearest Gateway or TURN relay to be used, which provides the highest performance.

3. Disable TLS inspection Don’t inspect RDP traffic at the egress firewall. TLS inspection introduces latency and degrades session quality while providing no benefit. Inside the TLS encrypted transport session, lies a nested TLS encrypted data session. For more information, see connection security documentation.

4. Prioritize RDP traffic Where applicable, prioritize RDP traffic within the network to maintain session responsiveness. Treat it similarly to how Microsoft Teams media traffic is handled.

Example Outcome:

Contoso used the RDP endpoint details in rows 1 and 2 to route traffic through an optimized path (shown as a dashed line). This path egresses locally to the internet via a direct route out of the corporate network. TLS inspection is disabled for this traffic at the firewall.

By following this approach, Contoso achieved:

• Lowest possible latency to the Windows 365 service

• Highest reliability of connectivity

• Maximum throughput for remote sessions

• Reduced load on proxy path

• Local RDP Gateways and TURN relays close to users, ensuring traffic enters Microsoft’s global backbone as early as possible for end-to-end performance

From the local gateway or relay, traffic travels across Microsoft’s backbone to the Cloud PC and back, reducing exposure to the public internet and improving stability.

Diagram 3: RDP Optimization from a corporate network

The following example shows Contoso’s mobile worker network configuration. The VPN software used by mobile workers is set to bypass RDP traffic from the forced tunnel VPN using the information shown (dashed line).

This optimization allows RDP traffic, like Teams media traffic, to use the user’s direct internet path to Microsoft instead of routing through the corporate network.

Diagram 4: RDP Optimization from a remote user

Cloud PC‑side optimization

The RDP endpoints used on the Cloud PC side are the same as those endpoints used on the physical device side, and they’re also outbound. With the correct configuration, RDP traffic from the Cloud PC stays on Microsoft’s backbone to the destination Gateway or TURN relay instead of traversing the public internet. This approach improves reliability and performance.

The steps to achieve this optimization on the Cloud PC side may differ slightly from the physical device side depending on the deployment option you choose.

Microsoft Hosted Network deployments

In the Microsoft Hosted Network model, which is the recommended deployment option, Microsoft preconfigures and optimizes the core connectivity on your behalf. You don’t need to make any additional configuration to deliver optimal connectivity to the underlying network.

When additional configuration is needed

If you install network software on the Cloud PC, such as a VPN client or Secure Web Gateway (SWG) agent, these components may alter the RDP traffic path so it doesn't use the provided underlying network directly. In this case, configuration is required to bypass RDP traffic so it routes directly into Microsoft’s network through the provided path, rather than through the VPN or SWG solution.

These endpoints match those required on the physical network and are listed in the following table:

ID	FQDN	IP	Protocol/Port	Purpose
1	*.wvd.microsoft.com	40.64.144.0/20 (Covers RDP flow within the FQDN but not everything within the wildcard domain)	TCP/443	TCP Based RDP Connectivity
2	n/a	51.5.0.0/16	UDP/3478	UDP Based RDP via TURN

Some Secure Web Gateway (SWG) vendors, such as Zscaler, provide simplified bypass options for RDP traffic. For more information, see the related Techcommunity post.

You also need to ensure that the following non-RDP endpoints aren’t sent through any Proxy, VPN, or SWG tunnel on the Cloud PC side. If this traffic is routed outside of Azure or blocked, the connection fails.

ID	FQDN	IP	Protocol/Port	Purpose
3	azkms.core.windows.net	20.118.99.224/32, 40.83.245.53/32, 23.102.135.246/32 (Check Azure KMS documentation for updates)	TCP/1688	Azure KMS traffic
4	n/a	169.254.169.254	TCP/80	Azure Fabric Communication
5	n/a	168.63.129.16	TCP/80	Azure Fabric Communication

Important

Ensure RDP traffic is bypassed for all tunnel types: VPN and SWG tunnels are normally user-based, but confirm that any machine-based tunnels also exclude the required RDP endpoints. This bypass is critical because outbound connectivity to these endpoints is required before the user signs in to the Cloud PC.

Azure network connection (ANC) deployments

For Azure Network Connection (ANC) deployments, where the Cloud PC uses your own Azure virtual network (VNet), configure an optimized egress path for RDP so traffic uses Microsoft’s backbone without unnecessary inspection or hair-pinning. Implement the following guidelines to ensure maximum performance and reliability:

• A User-defined route (UDR) for RDP traffic: Use a route targeting the WindowsVirtualDesktop service tag to 'Internet', ideally via a NAT Gateway associated with the subnet. This approach keeps RDP flows off Network Virtual Appliances (NVAs) while preserving a consistent outbound path.

• Network Security Groups (NSGs): Ensure NSGs allow outbound TCP/443 and UDP/3478 for the relevant service endpoints. Don’t block the service tag.

• No TLS inspection or proxy authentication on RDP flows: Disable interception or inspection for RDP connectivity if it flows through a device providing this function.

• Other traffic: You can route non-RDP traffic through your default route (for example, to Azure Firewall) as needed.

• Be cautious with NVAs for RDP: NVAs, including Azure Firewall, can add latency and may disrupt long-lived UDP/TCP sessions during scale-in operations. Use NAT Gateway for key long-lived traffic such as RDP and Microsoft 365 traffic.

• Validate underlying connectivity: Use the guidance provided and validate with Azure Network Connection (ANC) health checks.

Diagram 5: Simplified ANC deployment with optimizations for RDP traffic

This diagram shows three main routes configured from the Azure virtual network (VNet):

1. Default route (0.0.0.0/0 User Defined Route UDR) Sends all traffic to the Azure Firewall’s private IP, which becomes the default path. The firewall allows approved traffic to Microsoft’s network and the internet as required. Use this path for other Windows 365 service endpoints that don’t require special handling.

2. Optimized route for RDP traffic A more specific UDR sends the WindowsVirtualDesktop service tag to 'Internet', which in this example uses a NAT Gateway. This path is optimized for RDP and should also be used for long-lived or latency-sensitive traffic that doesn’t need to traverse the firewall. 'Internet' doesn't mean this traffic reaches the public internet.

3. On-premises route The ExpressRoute Gateway provides a more specific route for on-premises traffic, such as anything in the 10.0.0.0/8 range.

See the document Use Azure Firewall to manage and secure Windows 365 environments for more detail.

Tip

Trusted traffic such as Microsoft 365 flows, VPN/SWG tunnels, or other high-volume, latency-sensitive traffic may also benefit from using the optimized path. Doing so reduces load on the firewall for traffic that truly requires its services.

RDP Optimization FAQ

Q: In a Microsoft Hosted Network deployment, do I need to do anything else?

A: No further configuration is normally required once you configure bypass for the endpoints listed in this article in your proxy, VPN, or SWG solutions. The virtual network card is automatically configured to use Microsoft’s backbone for direct, high-speed connectivity.

Q: Do I need to configure the bypass only on the Cloud PC?

A: No. Apply the bypass to both the Cloud PC and the connecting client if the client uses a proxy, SWG, or VPN. If both devices share the same configuration profile, this bypass should happen automatically. Rows 3–5 in the table in this document apply only to the Cloud PC.

Q: How often do the IP addresses change?

A: We consolidated the RDP endpoints into two dedicated subnets for the service globally. These subnets are sized for growth and minimize the risk of frequent IP address changes. This design helps maintain stability and simplifies firewall and routing configurations. You can monitor the WindowsVirtualDesktop service tag for updates. We’re also working to include these requirements in the Microsoft 365 Web Service for easier monitoring and automation.

Q: Can I add more than RDP traffic to the bypass?

A: Microsoft currently provides IP addresses only for RDP connectivity. If your solution supports FQDN-based configuration, you can add other service endpoints. See the Microsoft Docs page linked in this article. You may also want to bypass Microsoft 365 traffic as a best practice.

Q: I’m using a true split tunnel. Does this impact me?

A: No. This guidance applies to forced tunnel scenarios (inverse split tunnel), where all traffic goes through the tunnel except defined exceptions. In a true split tunnel, where the default path is the internet and only specific endpoints go through the tunnel, RDP traffic should follow the default internet path unless manually configured otherwise.

Q: Does this advice also apply to Azure Virtual Desktop (AVD)?

A: Yes. Windows 365 and AVD have the same connectivity requirements, as does Devbox.

Q: Does the bypass reduce security?

A: No. The connection remains TLS-encrypted end-to-end. The bypass only changes the network path, not authentication, or encryption. Keep your endpoint protection, Conditional Access, and device compliance policies in place.