Reverse Connect for Azure Virtual Desktops (AVD)

Azure Virtual Desktops and On-premises Remote Desktops

There’s 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).

This is also a best practice adopted by Microsoft for Azure Virtual Desktops (AVD). Within their “Reverse Connect” 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.

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.

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

But how do I get the real client IP of an AVD user?

So, Reverse Connect is awesome… 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.

The client IP information is available, but most monitoring tools aren’t 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, such as:

• Azure Active Directory
• Your own cloud-hosted or on-prem Windows Server Active Directory (AD) in sync with Azure Active Directory. You’ll also need to monitor that and the Azure AD Connector component that provides the synchronization to Azure AD
• Your Azure subscription
• Implied in this, is also a need to monitor the AVD broker

Beyond this, many eG Enterprise customers chose to add in proactive synthetic monitoring and testing, i.e., scheduled robot users.

eG Enterprise provides a domain-specific model to capture the information available from the AVD Broker and it is here that the administrator can obtain access to a user’s real client IP, location, etc. This is essential information for both troubleshooting and auditing the systems that are being accessed by authorized users.

AVD (was WVD) user forums are littered with IT admins asking this very basic question – “Is there a way to retrieve the client IP of each WVD session?”, “Why can’t I see the client-side IP address?”, etc.

Users fully understand the reasons the IP isn’t available via the on-premises mechanisms they use; they simply want a way to access this key information. One eloquent user summed up his problem recently on the Microsoft community forums:

• “In our current environment, we’re using thin clients at several sites connecting to a Citrix farm. By making calls to wtsapi32.dll, we retrieve the IP address of the thin client, which enables us to determine its physical location and do all kinds of stuff specific for that location, including mapping printers and drives, but also logging for tracing and accountability. Using the Remote Desktop app for WVD, however, the client IP address is never returned. It designates the IP address family as AF_UNSPEC. I can understand why the wtsapi32.dll does not work in this scenario, as the client does not directly connect to the WVD, but is there another way to retrieve the client IP address? It’s important it can be read from within the context and session of the user.“

The eG Enterprise Solution: Access the client IP for AVD sessions with a few clicks

1. Select the AVD Broker

2. Within this, scroll to the “AVD Connections By Host Pools” tests and select the appropriate host pool you are interested in.

3. Now, click the detailed diagnosis icon (the magnifying glass) next to a connection metric such as “Total started connections (Number)” or “Total connected connections (Number)” Detailed diagnosis tests are run automatically when appropriate, so when sessions are connected, a detailed diagnosis test is applied that captures the details of the session. By default, you will see the “Latest” diagnosis run, and there will always be a timestamp to help you verify the chronology. If you want to review events further in the past, then simply select a longer timeframe using the “Timeline” dropdown.
4. Detailed tabulated information will be presented in the results table including, Client OS, Client version, Client-side IP, and Client type. Note: On the top right-hand corner as with all detailed diagnostics, there will be an option to export the data as a .PDF or .CSV file (for analysis in MS Excel).

Learn more

• A guide to monitoring AVD with Azure Monitor and Log Analytics: Azure Virtual Desktop Monitoring – AVD Monitoring | eG Innovations
• How eG Enterprise monitors Azure Infrastructures: Azure Monitoring Tools & Solutions | eG Innovations