{"id":17315,"date":"2021-11-18T02:00:56","date_gmt":"2021-11-18T07:00:56","guid":{"rendered":"https:\/\/www.eginnovations.com\/blog\/?p=17315"},"modified":"2022-11-17T18:55:24","modified_gmt":"2022-11-17T23:55:24","slug":"reverse-connect-azure-avd","status":"publish","type":"post","link":"https:\/\/www.eginnovations.com\/blog\/reverse-connect-azure-avd\/","title":{"rendered":"Reverse Connect for Azure Virtual Desktops (AVD)"},"content":{"rendered":"
\n

<\/span>Azure Virtual Desktops and On-premises Remote Desktops<\/span><\/h2>\n

There\u2019s something common between Azure Virtual Desktops and eG Enterprise. Can you take a wild guess? Listening on open TCP ports is an extremely bad practice for cloud architectures, as it exposes products and services to accepting incoming messages from malicious parties. This is something eG Innovations avoids in our own products (see details<\/a>).<\/p>\n

This is also a best practice adopted by Microsoft for Azure Virtual Desktops (AVD). Within their \u201cReverse Connect\u201d technologies, you can run a VM without keeping any inbound ports open. This means that the VMs on AVD are not exposed to the Internet directly.<\/p>\n

Azure Virtual Desktops use reverse connect transport for establishing the remote session and for carrying RDP traffic. Unlike the on-premises Remote Desktop Services (RDS) deployments, reverse connect transport doesn’t use a TCP listener to receive incoming RDP connections. Instead it uses outbound connectivity to the Azure Virtual Desktop infrastructure over the HTTPS connection.<\/p>\n

Microsoft\u2019s own documentation covers how this is done; see Understanding Azure Virtual Desktop network connectivity – Azure | Microsoft Docs<\/a>. Ryan Mangan has also covered the security benefits of this approach on A Deep Dive In to Windows Virtual Desktop \u2013 Reverse Connect \u2013 Ryan Mangan’s IT Blog (ryanmangansitblog.com)<\/a> and WVD Reverse Connect \u2013 The Fish Tank Analogy \u2013 Ryan Mangan’s IT Blog (ryanmangansitblog.com)<\/a>.<\/p>\n

\"Reverse<\/a><\/p>\n

\n

<\/span>What is Reverse Connect for Azure Virtual Desktops?<\/span><\/h2>\n

Connecting from your virtual machine in Azure to your host pool (session hosts in Azure Infrastructure-As-a-Service) works differently with Azure Virtual Desktop. It uses Reverse Connect, which means that no inbound ports need to be opened on the VM to set up the RDP connection. Once the connection flow proceeds, bidirectional communication between your session hosts\/host pool will go over port https (443). This port is almost always open from the inside to the outside, so it\u2019s perfect for a remote connection to Azure Virtual Desktop!<\/p>\n

Source<\/strong>: Christiaan Brinkhoff, Azure Virtual Desktop technical deployment (Classic \u2013 non-ARM-based model) walkthrough | christiaanbrinkhoff.com – Sharing Cloud and Virtualization Knowledge<\/a><\/p>\n<\/div>\n

<\/span>But how do I get the real client IP of an AVD user?<\/span><\/h2>\n

So, Reverse Connect is awesome\u2026 But it does obfuscate some very basic information about your end users, such as their real client IP. Whilst this information can be obtained via agents on the end-users’ endpoints, many administrators prefer to avoid this approach, particularly MSPs or organizations providing BYOD and DaaS-like services.<\/p>\n

The client IP information is available, but most monitoring tools aren\u2019t monitoring parts of the AVD deployment where they can capture information such as the true Client IP. If you are monitoring an Azure AVD deployment, you really need to monitor all the components of the deployment beyond just hosts and VMs, i.e., the components, as detailed in the AVD requirements<\/a>, such as:<\/p>\n