RDP Short Path for Public Networks (PREVIEW)

Introduction

The connectivity in Azure Virtual Desktop has been a bit of a topic for a while due to its use of its Reverse Connect technology.

For those that don’t know this is the default connection type for AVD and utilizes an outbound TCP connection over HTTPS initiated from within the AVD Infrastructure.

Normally, connections for terminal services have generally been initiated as an inbound connection from the client directly to the host (via the Web Access/Gateway) so this is more secure and has the best compatibility with various network configurations, as you do not have to open the AVD environment to the wider internet.

Below is a link to the official Microsoft Article on AVD Network Connectivity:

Understanding Azure Virtual Desktop network connectivity – Azure | Microsoft Docs

Whilst this provides a pretty solid, and secure connection to the AVD infrastructure, it is unfortunately based only on a TCP connection which is not ideal for video/graphic content. Anyone that has tried to stream video content can attest to there being lag and other issues.

For a long time in RDS, people have been utilizing UDP based connections to allow for a richer user experience. UDP-based transport is more suitable for graphic and audio transfer in terminal service environments.

Microsoft, therefore, looked to provide UDP-based transport with its RDP Shortpath for Managed Networks.

However, this was limited to private connections over ExpressRoute, VPN etc. This meant you could only benefit from Shortpath if your client machine had a direct line off-site with the AVD Session Hosts, which for a lot of use cases was not possible.

This was a bit of a knockback as anyone thinking of using AVD (or any terminal services environment) for any performance-based tasks (Video/Photo editing, CAD etc) would not be able to benefit from the UDP connections from external locations.


Enter RDP Shortpath for Public Networks

However, this is no longer the case! RDP Shortpath has been announced for Public Networks!

I must preface this with the fact that this is still a preview feature so use it at your own risk etc.

Also, RDP Shortpath for Public Networks is not compatible with RDP Shortpath for Managed Networks. Therefore, you will need to disable RDP Shortpath for managed networks if you wish to test this feature.

One concern that people may have, is with the security of RDP Shortpath. People may incorrectly assume that this is bypassing the Reverse Connect connection and opening your AVD Infrastructure up for attack with direct connections.

However, be assured that RDP Shortpath works with Reverse Connect to control connections.

The Session Host uses a dynamic UDP socket that will accept traffic that has already been authenticated over a Reverse Connection.

This socket will only be opened after the user session has established a Reverse Connect connection. The Shortpath connection itself is then established using TLS using a session host certificate.

Details on how the actual connection works are quite in-depth and are covered in the below link:

https://docs.microsoft.com/en-us/azure/virtual-desktop/shortpath-public

The main gist is that RDP Shortpath for Public Networks utilizes STUN (Session Traversal Utilities for NAT) protocol to discover the external IP address of the NAT router. The traversal of NAT gateways is required to establish the connection.


Configuring

So now we know a bit about what it is, let’s get configuring!

Thankfully to configure this feature there is not much you need to do. The only real configuration required is simple Registry Key addition on each Session Host and then ensure the relevant traffic is allowed on both the AVD and Client side.

Registry Change

To use this feature, we need to enable it on each session host we require.

The easier way is to run the following Registry Key addition.

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations” /v ICEControl /t REG_DWORD /d 2 /f

Firewall Considerations

You may need to make changes to your Firewall configuration to allow the required ports.

It is recommended that you allow UDP access out from the Session Host VNET to the internet. Obviously, if you know there are particular offices or locations, then add the IPs as needed.

You also need to ensure that the Session Hosts can access the Azure STUN servers to perform the NAT traversal required for connection.

From the Client network, we simply need UDP allowed from the network to any of the Public IP addresses assigned to a NAT Gateway or Azure Firewall.

RuleNetworkDestination PortDestination
STUN AccessSession Host & Client NetworkUDP – 347813.107.17.41/32 13.107.64.0/18 20.202.0.0/16 52.112.0.0/14 52.120.0.0/14
RDP ShortpathSession HostUDP – 1024-65535*
RDP ShortpathClient NetworkUDP – 1024-65535Public IP or NAT Gateway or Azure Firewall

Other than the registry entry and the firewall rules, there should be nothing else we need to do to get RDP Shortpath for Public Networks working.


Testing

So now I can confirm my settings are all good to go, it’s time to test!

I’ll now make an attempt to connect to my GPU enhanced AVD Session Host.

We can see that I now have UDP connectivity!

Having UDP enabled vastly improves the video performance of the AVD session. Below is a video of my GPU Enhanced AVD Session playing a little XenoCrisis (a great game by the way!)

And we can see from the connection status that it’s pretty much maintaining 30+ FPS. Considering my AVD Session Host is in West Europe and I’m sat in South England that’s not too shabby!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s