Windows Virtual Desktop Internals – TCP Only, Reverse Connect

March 25, 2019 - Windows Virtual Desktop

Alright, folks – Windows Virtual Desktop is now in Public Preview in Azure, so now is the time to dig in and start playing with it! I’ve had the privilege to be working with it in Private Preview, so I’m starting a blog series covering the “under the hood” internals that make WVD different than traditional Remote Desktop Services.

Classic Remote Desktop Services deployments (let’s hope WVD is better than New Coke), whether run on-premises or in Azure on IaaS virtual machines, typically require the use of separate VMs to host the infrastructure roles, such as Remote Desktop Web Access, Remote Desktop Gateway, and the Remote Desktop Connection Broker. What Microsoft has done with Windows Virtual Desktop is to abstract away these traditional Windows Virtual Desktop roles into “black box” web services that they control and maintain as part of Azure. As a result, all you are responsible for are the session hosts that serve up the apps/desktops into which your employees or customers connect.

BTW – in Classic Remote Desktop Services, these logical groupings of session hosts were called RDS collections. In WVD, they are now called host pools. You can provision, tear down, and re-provision these host pools via a limited wizard in Azure, through ARM templates in Azure, or via specialized PowerShell commands. I’ll touch upon these concepts more in upcoming articles.

That being said, in Classic Remote Desktop Services, if a Remote Desktop Gateway was deployed, a client would connect to the gateway over TCP Port 443, authenticate, and then the Gateway would create a secure session inbound to a session host (after consulting with the Connection Broker) over the traditional RDP port 3389. In Server 2012 and later, the RDS Gateway could also use UDP port 3391 to enable dual transport for much better connection quality over higher latency or less-reliable networks.

In Windows Virtual Desktop, things are different. My colleague and fellow MVP Freek Berson alluded to as much in his recent blog article. The RDS/WVD client still connects to the Azure Windows Virtual Desktop Gateway Service over port 443, but then using “black box magic” via agent software on the target session host:
1.) The Windows Virtual Desktop Gateway and Broker Services contact the session host in the host pool that should receive the new client connection, and
2.) That session host establishes a reverse connection back to the client through the Azure WVD Gateway Service. In this way, the Azure WVD Gateway Service is acting as a reverse proxy of sorts.

Windows Virtual Desktop Reverse Connect Server Side
No more port 3389 folks. Just a connection from the Remote Desktop Service back to the Azure WVD Gateway Service sitting in the middle between the client and the session host.
As you’ll notice, on the client side, we have an outbound 443 connection to the same WVD Gateway Service in Azure.

Arguably, this architecture is somewhat more secure than classic RDS, since the connection comes from the session host back TO the client through the WVD Gateway after authentication and validation by the Azure WVD Infrastructure. Also, in Classic RDS deployments, admins often forget to be appropriately restrictive with their CAPs (Connection Authorization Policies) and RAPs (Resource Authorization Policies) on their RD Gateways, setting up a scenario where just about any Windows host running RDP can be accessed once any domain user was authenticated through the RD Gateway. In WVD, you have to explicitly indicate the users that will be permitted to connect to any given host pool during host pool creation.

One noticeable difference, now, is the lack of UDP traffic between the client and server. This has direct implications on how robust WVD can be over higher latency connections whereby remote workers in one part of the world attempt to connect to WVD resources in a distant Azure region. I have a feeling Microsoft’s answer to this will be “place your host pools in the Azure geographic region most suitable for your clients” and/or “create as many host pools in different regions as required to serve your clients.” However, that adds both architectural complexity and cost, so it is my hope that RDP dual transport featuring UDP will eventually come to WVD. Until then, it may make sense to continue to set up Classic RDS in Azure with the traditional infrastructure role services under YOUR direct control as opposed to deploying WVD, since dual transport with TCP/UDP will still work in those circumstances.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

Leave a Reply

Your email address will not be published. Required fields are marked *