- Add windows-remote-desktop-connection-doctor v1.0.0 for diagnosing AVD/W365 connection quality issues with transport protocol analysis and log parsing - Update claude-md-progressive-disclosurer SKILL.md and references - Update marketplace to v1.32.0 (37 skills) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6.7 KiB
AVD Transport Protocol Reference
How Azure Virtual Desktop selects transport protocols and how RDP Shortpath works.
Contents
- Transport protocol hierarchy
- RDP Shortpath architecture
- STUN/TURN/ICE overview
- Why Shortpath fails
- Network requirements
- Common interference patterns
Transport Protocol Hierarchy
Azure Virtual Desktop clients attempt transports in this order:
- UDP Shortpath (best) — Direct UDP connection via ICE/STUN/TURN
- TCP — Direct TCP connection to session host
- WebSocket — WebSocket over TCP 443 through the AVD gateway (worst)
The client always establishes a WebSocket connection to the gateway first (for control plane). Then it attempts to upgrade to UDP Shortpath. If Shortpath negotiation fails, the session data stays on the WebSocket channel.
RDP Shortpath Architecture
For Public Networks (most common for remote workers)
RDP Shortpath for public networks uses ICE, STUN, and TURN protocols to establish a direct UDP connection between client and session host:
- Client connects to AVD gateway via WebSocket (TCP 443)
- Through this control channel, ICE negotiation begins
- Client and server gather ICE candidates using STUN
- They exchange candidates and attempt connectivity checks
- If a direct UDP path exists, Shortpath is established
- If direct fails but TURN relay is available, traffic relays through TURN
- If all UDP attempts fail, session stays on WebSocket
For Managed Networks (corporate LAN)
When client and session host are on the same network, Shortpath uses direct UDP without STUN/TURN. This is the simplest mode and rarely fails.
STUN/TURN/ICE Overview
STUN (Session Traversal Utilities for NAT)
STUN discovers the client's public IP and port as seen from outside the NAT. The client sends a STUN Binding Request to a STUN server, which replies with the client's observed address.
Key port: UDP 3478
NAT types that affect STUN:
- Endpoint-Independent Mapping (EIM): Best — same public port regardless of destination. STUN works reliably.
- Address-Dependent Mapping: Moderate — different public port per destination IP. STUN may work with help from TURN.
- Address-and-Port-Dependent (Symmetric NAT): Worst — different public port per destination IP:port. STUN alone often fails; requires TURN relay.
TURN (Traversal Using Relays around NAT)
When direct UDP fails, TURN provides a relay server. Traffic goes: Client → TURN server → Session Host. Adds latency but still uses UDP.
Key ports: UDP 3478, TCP 443 (fallback)
ICE (Interactive Connectivity Establishment)
ICE orchestrates STUN and TURN to find the best available path. It gathers candidates (direct, server-reflexive via STUN, relayed via TURN), exchanges them with the peer, and tests connectivity.
Why Shortpath Fails
1. VPN/Proxy TUN Hijacking
When a VPN tool (ShadowRocket, Clash, Surge) runs in TUN mode, it captures all outbound traffic including STUN/TURN UDP packets. The proxy typically cannot relay raw UDP correctly, causing ICE negotiation to fail.
Detection: Windows App's source IP in lsof shows 198.18.0.x (ShadowRocket) or another VPN virtual IP instead of the real local IP.
2. ISP UDP Restrictions
Some ISPs (particularly in China, especially outside tier-1 cities) throttle or block UDP to certain ports or destinations. This prevents STUN binding requests from reaching Azure's STUN servers.
Detection: STUN tests fail even with all VPNs disabled.
3. Symmetric NAT (Address-and-Port-Dependent)
If the router implements symmetric NAT, each outbound UDP flow gets a different public port. STUN discovers one port, but when the actual Shortpath connection uses a different destination, the NAT assigns a different port, and the peer's packets go to the wrong port.
Detection: Tailscale netcheck shows MappingVariesByDestIP: true.
4. FetchClientOptions Timeout
The client needs to fetch transport capabilities from the gateway. If this request times out (network issues, DNS problems, TLS interception), the client never learns about Shortpath availability.
Detection: Log entry CWVDTransport::FetchClientOptions exception: Request timed out.
5. Health Check Failure
Certificate validation errors at app startup prevent the diagnostic subsystem from completing, which can cascade into transport capability discovery failures.
Detection: Failed to validate X509CertificateChain at the start of the log, followed by absence of the health check block.
6. Server-Side Not Enabled
RDP Shortpath must be enabled on the AVD host pool by an administrator. If not enabled, the server never offers Shortpath candidates.
Detection: No STUN/TURN/Shortpath entries at all in logs, even though health checks pass.
Network Requirements for Shortpath
Ports
| Protocol | Port | Purpose |
|---|---|---|
| UDP | 3478 | STUN Binding Requests |
| UDP | 1024-65535 (dynamic) | Shortpath data channel |
| TCP | 443 | Gateway WebSocket (always needed) |
DNS
The client must resolve these domains correctly:
*.wvd.microsoft.com— AVD gatewayrdweb.wvd.microsoft.com— AVD web client- STUN/TURN server addresses (provided by the gateway during ICE)
DNS poisoning (returning fake IPs) prevents proper transport negotiation.
TLS
The client validates TLS certificates for Microsoft endpoints. If the certificate chain is modified (ISP proxy, corporate MITM, DNS poisoning), the health check fails and transport negotiation may be impaired.
Common Interference Patterns
Pattern: ShadowRocket TUN Mode
Mechanism: Creates utun interface with IP 198.18.0.1, captures all public traffic via 0/1 + 128.0/1 split routing, DNS hijacked to 198.18.0.2.
Effect on RDP: All AVD traffic goes through proxy tunnel. STUN/TURN fails because proxy cannot relay raw UDP. DNS returns fake IPs (198.18.0.x).
Fix: Add DIRECT rules for Microsoft/Azure domains and IPs.
Pattern: Tailscale with Exit Node
Mechanism: When exit node is enabled, all traffic routes through the Tailscale tunnel.
Effect on RDP: Similar to VPN hijacking — UDP packets go through WireGuard tunnel to exit node, then to Azure. Adds latency and may break STUN.
Fix: Disable exit node, or add route exceptions for Azure IPs.
Pattern: Chinese ISP UDP Throttling
Mechanism: Some Chinese ISPs, particularly in non-tier-1 cities, apply QoS policies that throttle or drop UDP packets to foreign destinations.
Effect on RDP: STUN binding requests time out. Even with perfect client-side configuration, Shortpath cannot establish.
Fix: Try mobile hotspot (different ISP/carrier), use a proxy with good UDP support to Azure's region, or accept WebSocket with optimization (change DNS to reduce resolution latency).