An Azure service that is used to provision Windows and Linux virtual machines.
Hi @Dhaval-9536
The Serial Console detail helps a lot. The VM is running and can reach its own subnet, so the break is either inside Windows (firewall or the RDP service) or on the path from your client to that private IP. One note first: ping isn't a reliable test, because Windows Firewall blocks ICMP by default, so "no ping" on its own doesn't mean the network is down.
Inside the VM (via Serial Console, open a CMD channel):
- Run
netsh advfirewall show currentprofile. If the network has flipped to the Public profile, inbound RDP can be blocked even though nothing was changed on purpose. Runnetsh advfirewall firewall set rule group="remote desktop" new enable=yesto re-enable the RDP rules. - Run
netstat -ano | findstr 3389to confirm RDP is listening. If nothing shows, restart the service withnet stop termservicethennet start termservice. - Run
ipconfig /alland check that the IP, gateway and DNS still match the NIC settings in the portal.
On the Azure network side (portal):
- Use Network Watcher > IP flow verify with your client's IP as the source and the VM's private IP on port 3389. It names the exact NSG rule that allows or denies the traffic.
- Check Effective routes on the VM's NIC. A new route through a firewall or NVA, or a change on the VPN/ExpressRoute side, would explain a sudden break without any change on the VM.
Where does the connection come from: another VM in Azure, or your office over VPN/ExpressRoute?
If RDP works again after this, please consider accepting it as the answer. If IP flow verify shows "Allowed" and it still fails, let me know and I'll be happy to keep helping.
Reference: