No Public IPs, No Shortpath
Litware runs 22 session hosts in a spoke VNet with no public IP addresses. All outbound traffic is forced-tunnelled to on-premises through an NVA, and the perimeter firewall permits TCP 443 only; UDP is blocked. Azure Files is reachable only through a private endpoint, and the storage account has public network access disabled. Branch users connect over the internet with VPN split tunnelling disabled. Sessions take 25 to 40 seconds to establish, Teams audio inside the session is choppy, and the host pool reports no RDP Shortpath connections. Security's non-negotiables: no public IPs on session hosts and no inbound connections from the internet.
1. Why does RDP Shortpath never establish, and what are the two viable paths inside security's constraints?
Read the worked answer
Why it fails. Shortpath is a UDP path built with ICE. For connections over the public internet, the client and host exchange candidates, try a direct UDP route (session host UDP 3390), and fall back to Microsoft-operated TURN relays on UDP 3478 when a direct route is impossible. With UDP blocked at the perimeter and all traffic forced through an NVA, no usable candidate survives, so the client silently falls back to the reverse-connect transport over TCP 443. Nothing errors; the connection simply takes longer and A/V quality degrades, which is exactly the reported symptom.
Path one, least change: allow relayed Shortpath. Permit outbound UDP 3478 to the Microsoft TURN endpoints, and outbound UDP 3390. No public IP on the hosts and no inbound rule is required, because the TURN relay handles reachability. You get relayed Shortpath rather than direct, which is still a large improvement over TCP 443 for both connect time and Teams media.
Path two: Shortpath for managed networks. Because split tunnelling is disabled, branch client traffic already traverses the VPN. If the VPN and NVA pass UDP 3390 end to end and the client can route to the session host's private IP, ICE can build a direct private path with no internet exposure at all. This is the better outcome but depends on firewall, NAT, MTU, and idle-timeout behaviour on the tunnel, and it needs testing per branch.
Also check TLS inspection. If the perimeter inspects traffic to the AVD endpoints, the reverse-connect WebSocket can break or stall, which independently produces long connects. Exclude those endpoints from inspection.
2. What must survive forced tunnelling, and what is the symptom on the host pool if it does not?
Read the worked answer
What must survive: outbound TCP 443 from every session host to the AVD broker and agent endpoints (the WindowsVirtualDesktop service tag), to Microsoft Entra ID, to Intune for management, to Azure Monitor or your private monitoring path, to Windows Update if you patch that way, and SMB 445 to the Azure Files private endpoint resolved through the private DNS zone. The private endpoint traffic should stay in Azure and never traverse the NVA.
Symptom when it does not: the VM is healthy, the agent service is running, and the host pool shows it as unavailable or the broker refuses to place users on it, while CPU and memory look untroubled. Users see 'no resources available' or get placed on the few surviving hosts. Log Analytics HostRegistration data shows repeated registration failures, which is the fastest confirmation.
Design it deliberately: use service tags in NSGs and firewall policy rather than IP lists, keep the storage private endpoint on a subnet with native routing and a private DNS zone link, and give the AVD endpoints explicit bypass rules in the route table. Do not send broker traffic through a proxy that terminates TLS; reverse connect uses WebSocket over 443 and TLS interception breaks the agent in ways that look like intermittent capacity problems.
Validate from inside the host, not from your laptop: a name resolution test and a TCP test to the broker endpoint from a session host tells you in seconds what an hour of metric browsing will not.
3. How would you prove whether the 25-40 second delay is broker placement, transport, or profile attach?
Read the worked answer
Instrument first, or you are guessing. Without connection checkpoints in Log Analytics there is no way to attribute the delay; it is the reason the problem has been argued about rather than measured.
Baseline with a test account from each of the three branch offices, at a quiet time and again at 08:00. Then split the timeline:
- Time from sign-in to host assignment isolates the broker. Slow or unassigned here means capacity, session limits, drain mode, or unhealthy agents, and the fix is infrastructure.
- Time from host assigned to RDP established isolates transport and name resolution. If this segment is long and constant across branches, suspect the TCP 443 fallback and TLS interception; if it varies with branch quality, suspect the branch network.
- Time from RDP established to shell ready isolates the host: FSLogix attach, policy processing, sign-in scripts, or contention.
Corroborate each hypothesis with one cheap signal. For transport, confirm whether any Shortpath connections exist at all, and compare connect time with and without a UDP-relay-friendly path. For profile, pull FSLogix attach duration for the same sessions and line it up against Azure Files SuccessE2ELatency in the same window. For the host, check whether affected sessions cluster on a subset of the 22 hosts; a subset means host-level, a spread means platform-level.
Expectation management: with the TCP fallback, 25-40 seconds is not anomalous for a client with high round-trip time to the host region. Before chasing a defect, confirm which region each branch is landing in.