TURN Relay Goes Global For AVD & Windows 365

Microsoft announced on the 2nd June 2025 that it would expand Traversal Using Relays around NAT (short TURN) relay for Azure Virtual Desktop (short AVD) and Windows 365 (short W365). Now in September 2025 this expansion went live. The rollout introduces a dedicated TURN relay IP range (51.5.0.0/16) and places relays across over 39 Azure regions, moving traffic off the old shared Azure Communication Services (short ACS) range and improving RDP Shortpath performance for public networks. Below I’ll walk through what changed, why it matters, which regions are covered, and what you should do to adapt to this change.

What is TURN?

Traversal Using Relays around NAT (short TURN) helps devices behind firewalls establish reliable UDP connections by relaying traffic when a direct UDP peer‑to‑peer path fails. For RDP Shortpath on public networks, TURN is the fallback that keeps low‑latency, UDP‑based remote desktop sessions working when direct connectivity isn’t possible. Moving to a dedicated range and expanding regional coverage means fewer hops, lower latency, and higher UDP success rates. Especially for voice/video and interactive apps on AVD or Windows 365.

Summary of the change and benefits

Microsoft announced the expansion on 2 June 2025, with changes starting 15 June, and the rollout reached over 39 regions worldwide by September 2025. The big changes: TURN relay traffic for Azure Virtual Desktop and Windows 365 now uses a dedicated IP range (51.5.0.0/16) instead of the shared ACS range (20.202.0.0/16). The new range is included in the WindowsVirtualDesktop service tag, and connections will migrate from the old ACS range to the new subnet over time.

This isn’t just an IP swap — it’s a real upgrade for users and network teams. Relays closer to end users mean lower latency and fewer hops. That reduces lag and improves real‑time experiences for audio, video, and interactive workloads. Reliability goes up too: you should see fewer dropped sessions and more stable connections under variable network conditions. And because the range is dedicated and in the WindowsVirtualDesktop service tag, it’s easier to manage firewall rules and security policies at scale during and after the migration.

Supported regions

A TURN relay is selected based on the client’s physical location, not the Cloud PC or session host. If the client is physically in Switzerland, they’ll use a relay in Switzerland North or West Europe / Italy North, not a relay elsewhere. If a client is far from a supported region, connections may fall back to TCP — expect higher latency in that case.

Supported regions deployed with the new TURN relay include: Australia East, Australia Southeast, Brazil South, Canada Central, Canada East, Central India, Central US, East US, East US 2, East US2 EUAP, France Central, Germany West Central, Israel Central, Italy North, Japan East, Japan West, Korea Central, Korea South, Mexico Central, North Central US, North Europe, Norway East, Poland Central, South Africa North, South Africa West, South Central US, South India, Spain Central, Southeast Asia, Sweden Central, Switzerland North, Taiwan North, UAE Central, UAE North, UK South, UK West, West Central US, West Europe, West US, West US 2, West US 3.

How to prepare for the change

Microsoft intends this to be a seamless transition, but you need to prepare. In short: make the 51.5.0.0/16 subnet accessible from all networks that will host AVD or Windows 365 users, and optimize the path, so the traffic takes the most direct route to Microsoft’s backbone.

Make it accessible

  • Allow outbound access to 51.5.0.0/16 from corporate networks, branch sites, VPN egress points, and cloud egress locations.
  • If you use Azure ANC or Microsoft Hosted Network for Windows 365, connectivity is likely already in place.
  • Otherwise, include the WindowsVirtualDesktop service tag in your NSG/firewall rules to cover the new range automatically.

Optimize the path (this matters more than you think)

  • Don’t perform TLS inspection on this traffic — TURN uses nested TLS and inspection adds latency, reliability risk, and CPU load without benefit.
  • Egress locally: send AVD and W365 traffic to the internet from the closest, most direct egress so it enters Microsoft’s backbone quickly.
  • Bypass VPNs, proxies and Secure Web Gateways (SWG) for this traffic where possible; send it directly to the internet.
  • In Azure, consider a UDR to route AVD and W365 traffic directly to the Internet instead of forcing it through a virtual firewall that adds hops and latency.

Add bypass rules proactively

  • Create allow/bypass rules for 51.5.0.0/16 now.
  • Keep the old ACS range (20.202.0.0/16) permitted until the migration fully settles to avoid accidental drops.

Test and validate from real endpoints

  • Test from branch offices, home offices, VPN egress points, and cloud egress locations to confirm which TURN relay is chosen and to measure latency and media quality.
  • Measure performance with and without your proxy/TLS inspection paths to see the impact.
  • Validate Azure UDRs and firewall rules aren’t hair‑pinning traffic through virtual appliances unnecessarily.

What to watch for / remediation

  • If you see deep inspection or hair‑pinning, rework those flows for WindowsVirtualDesktop traffic.
  • If a client can’t reach a nearby TURN relay, it will fall back to TCP — expect higher latency and poorer real‑time audio/video quality.

Conclusion

This change is a net win — faster, more reliable RDP Shortpath for public networks, better UDP success rates, and a cleaner way to manage access with a dedicated IP range and service tag. But you need to act: allow and optimize 51.5.0.0/16, bypass inspection, and test from your real endpoints.

Sources

You might also like