DevTestLab VM's randomly wont allow RDP sometimes

Question

We've been using Azure DevTest Labs for several months to run remote training classes with 10–12 VMs per class. Students connect from home using RDP files or the provided FQDNs, and until recently, everything worked without issue.

Starting last week, we began seeing a strange, intermittent connectivity problem:

A student suddenly can't connect to the same VM they had been using previously.

The RDP client doesn't even prompt for credentials — it just fails to connect.

The same VM is still accessible from other networks and machines, including my own home network and the instructor’s.

Assigning the student a different VM works fine immediately.

The issue appears isolated to one workstation and one VM at a time.

This week, it happened again — with VM #12. I was onsite and able to test this in person:

From the student’s workstation, I could connect to every other VM except VM #12.

From other workstations, VM #12 was fully accessible.

All VMs are in the same Resource Group and share the same NSG.

I've tried on the affected machine:

Flushing DNS

  Resetting the IP and Winsock stack
  
     Clearing RDP cache and credential manager
     
        Disabling the firewall entirely
        

I also ran Test-NetConnection in PowerShell:

TCP test to VM #12’s public IP and port failed (TcpTestSucceeded = False)

But test to other VMs from the same machine succeeded

Traceroute shows the connection stalls deep in the Azure routing chain — but only from this specific machine to that one IP. This behavior feels like a stale NAT route or a poisoned path between the client and that one IP/port combo.

We’d love help figuring out:

What could cause only one machine to fail connecting to only one VM, while all others are fine

Whether there's a deeper Azure-side routing or load balancing issue we should be aware of

If a better way exists to ensure static IP behavior doesn't result in this kind of routing hang-up

Any help would be very appreciated!

Answer 1

Hi Joshua Polen,

This strongly suggests a TCP path asymmetry or stale NAT translation at the client-side router, or more likely, Azure’s load balancer/NAT gateway layer associated with that specific VM’s public IP.

When a VM is assigned a public IP, Azure maps incoming connections to the private IP of the VM behind the scenes. Occasionally, due to:

TCP session mishandling

Idle timeouts on NAT tables

Imbalanced routing table updates

Azure or the client’s upstream router may hold onto a stale or half-open connection state that prevents new connections to that exact destination (IP:port) combo.

Immediate Mitigations here are some things you can try right now, which often work around the issue:

Restart the VM

This often clears stale mappings or Azure-side NAT paths.

Can also re-register with Azure's load balancer, especially if a public IP is involved.

Force a new public IP

Disassociate and reassign the public IP (or allocate a new one). This will change the routing path and often resolves the issue.

Try changing the RDP port

Changing the RDP port on the affected VM (even temporarily) forces a new NAT mapping.

This is useful if the source IP has a blocked or stuck port mapping.

Change the source IP

From the student’s machine, connect via a VPN or hotspot to get a different source IP.

This has worked in similar cases and confirms that NAT pathing is at fault.

Please refer the below documents:

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-rdp-connection

https://learn.microsoft.com/en-us/azure/devtest-labs/configure-lab-remote-desktop-gateway

If you found information helpful, please click "Upvote" on the post to let us know.

If you have any further queries feel free to ask us we are happy to assist you.

Thank You.