Azure NAT – Revisited

    Stefan Peters

This blogpost is a Revisit of the former Azure NAT post. During the writing of the BLOG Azure NAT seemed to be a perfect solution for creating a single outbound IP for WVD servers. It will make sure all WVD servers have the same PUBLIC IP to browse the web. Making whitelisting for websites, MFA and other solution easily possible.

Unfortunately I have implemented the Azure NAT Gateway in a customer location and has a bad side effect I did not anticipate. At time of writing I give you one advice:

DO NOT IMPLEMENT AZURE NAT GATEWAY FOR WVD

The WVD connection becomes very unstable. Users randomly get disconnected/reconnected during the session.

Please notice the timestamp.

Check this video clip on how it is visible to the user.

This is how the user experiences the reconnection in WVD.

Diagnostics:

You can trace the disconnects in WVD Classic (formerly known as Fall Release) with this powershell commands:

Add-RdsAccount -DeploymentUrl https://rdbroker.wvd.microsoft.com

Get-RdsDiagnosticActivities -TenantName BLOGLABTENANT -Outcome Failure -Detailed -Type Connection -starttime 08-05-2020 | Sort-Object endtime | ft

The result of this command will show something like this:

The timestamps in the RED box accurately matches the timestamp shown in the previous screenshot and video clip.

Because the WVD reconnection was so frequently we opened a support ticket with Microsoft. The WVD team picked up the ticket, and after a few calls they transferred the ticket to the Azure Network team.

Microsoft Azure Network team asked us to capture network traffic on the client and on the WVD hosts where the user is connected. I tried to explain that there is a black box called “WVD” where we as customers cannot capture any data. The Azure Network team can be unaware how WVD works. After the analysis of the capture they got to the conclusion that the client is not directly connecting to the WVD host (really?).

Luckily I figured out the cause of the issue might be Azure NAT Gateway, and after a quick LAB test from which you see the screenshots and clip in this BLOG, we disabled the Azure NAT Gateway in the customer tenant. After this change the problem seems resolved.