About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
First identify the remote desktop platform. Traditional Remote Desktop Services through RD Gateway and Azure Virtual Desktop (AVD) use different connection designs. Opening a port mentioned for one does not enable the other.
Microsoft's RDS roles guide documents internet-facing RD Gateway access over TCP 443 for HTTPS and UDP 3391 for UDP transport. RDP Shortpath, by contrast, is an AVD UDP transport with managed-network, public direct and public relayed modes. It is not a general feature switch for any traditional RDS collection.
Traditional RD Gateway
The gateway provides an encrypted route to internal desktops or applications. Its certificate must be trusted and match the name clients use. The deployment guide describes this access without requiring a VPN for that Remote Desktop connection.
For diagnosis, record the actual client, gateway and host involved, the negotiated transport, and any VPN or security inspection along the path. Check gateway capacity and network conditions during a reproducible application task. A TCP connection is not evidence of a fault by itself, and UDP does not create capacity on an already saturated connection.
Do not remove certificate checks or introduce TLS offload as a generic performance adjustment. A supported gateway design and its encryption boundaries need to be established independently of a latency complaint.
AVD Shortpath is more than a direct private connection
AVD connections begin with TCP-based reverse connect through the AVD gateway. The client and session host then try to establish a supported UDP transport. If that succeeds, data moves to it; otherwise TCP reverse connect remains the fallback.
| Shortpath route | What Microsoft describes | Planning consequence |
|---|---|---|
| Managed network | Direct connectivity over a private route such as ExpressRoute or VPN; listener-based and STUN-based options are documented | Verify the particular option, route and supported client; the listener-based design uses UDP 3390 by default |
| Public network with STUN | Direct UDP connectivity using discovered public addresses and negotiated ports | NAT and firewall behaviour must permit the resulting path |
| Public network with TURN | UDP relayed through an intermediate server when direct connectivity cannot be established | This is a relayed connection, not a direct client-to-host path |
| UDP cannot be established | TCP-based reverse connect | Treat this as documented fallback, then measure whether it meets the workload's needs |
Shortpath requires Windows App or the Remote Desktop app on a supported platform, together with a supported AVD session-host and network configuration. Do not assume a browser or every client build provides the same transport. The primary page links the current client and configuration prerequisites.
The port numbers are not interchangeable. UDP 3391 belongs to the traditional gateway design above. AVD's listener-based managed route defaults to UDP 3390; public-network STUN/TURN has its own endpoint and negotiated-port requirements, including documented use of UDP 3478 for the discovery/relay service. Use the current network tables for the selected Azure cloud and mode rather than copying a broad firewall rule from this comparison.
Decide from observed sessions
For a proposed transport change, use an authorised pilot with the same application task, client, display size and concurrency. Record the actual route before and after, completion time, failures and disconnects. A change in transport is a configuration result; an improvement requires repeated task measurements.
If UDP is blocked by policy, plan for the supported TCP route and assess its performance. If public Shortpath is available, distinguish direct STUN from TURN relay before interpreting latency. If all users slow down together, investigate the gateway and application dependencies as well as the client path.
Microsoft documents some TURN/NAT connection changes and automatic reconnection behaviour. That does not justify describing fallback as unpredictable, nor does it guarantee that every application operation survives a disconnect. Test reconnect behaviour separately.
No network, gateway or AVD changes were tested for this article. It is a transport-selection guide, not a firewall implementation runbook.
Related service: ThinPoint remote access.
This article was originally published on .