Full Diagnostic Tree & Step-by-Step Overview
What specific symptom or error occurs when attempting to RDP into your Azure Windows VM?
Remote Desktop times out immediately with 'Remote Desktop can't connect to the remote computer' (Network error).
RDP prompts for credentials, but fails during authentication, handshake, or hangs at 'Configuring remote session'.
Connection fails due to Azure Access Control, Just-In-Time (JIT) VM access policy, or Bastion errors.
RDP works over internal VNet/VPN, but times out when connecting over Public IP or ExpressRoute.
Where in the Azure network layer is the RDP TCP port 3389 traffic being dropped?
Missing or lower-priority DenyAllInBound rule in the Network Security Group (NSG) attached to NIC or Subnet.
Subnet-level NSG rule conflicts with or overrides Network Interface (NIC) level NSG rules.
Uncertain which specific security policy is dropping traffic; diagnostic trace required via Azure Network Watcher.
Create High-Priority Inbound RDP Rule in Azure Network Security Group (NSG)
Solution:
Root Cause: Missing or Overridden Inbound Security Rule on Port 3389 Azure Network Security Groups (NSGs) evaluate stateful packet filtering rules sequentially by priority (100 to 4096). Every NSG includes default catch-all rules at priority 65500 (
DenyAllInBound). If an explicit
Allow rule for TCP port 3389 is absent, or if a higher-priority rule (e.g., priority 200 blocking all inbound traffic) precedes it, the Azure SDN fabric silently drops incoming TCP SYN packets, resulting in client RDP connection timeouts.
Step-by-Step Fix: 1 Inspect Effective Security Rules in Azure Portal:
Navigate to Virtual Machines > select your target VM > Networking . Click Effective security rules tab to view the combined active rules applied from both Subnet and NIC levels. 2 Add Inbound Security Rule for RDP:
Under the Inbound port rules tab, click Add inbound port rule . Configure parameters: Source: IP AddressesSource IP addresses/CIDR: Enter your local machine's public IP (e.g., 203.0.113.5/32). Avoid setting Any in production for security compliance.Source port ranges: *Destination: AnyService: RDP (or Destination port ranges: 3389)Protocol: TCPAction: AllowPriority: 300 (Ensure this value is lower than any Deny rules).Name: Allow-RDP-3389-InboundClick Add . 3 Alternative - Add Rule via Azure CLI:
Run the following command in Azure Cloud Shell or local terminal: Copy
bash
az network nsg rule create \
--resource-group MyResourceGroup \
--nsg-name MyVMNSG \
--name Allow-RDP-3389 \
--priority 300 \
--source-address-prefixes '<YOUR_PUBLIC_IP>/32' \
--destination-port-ranges 3389 \
--direction Inbound \
--access Allow \
--protocol Tcp
Reconcile Subnet-Level and Network Interface (NIC)-Level NSG Conflicts
Solution:
Root Cause: Dual-Layer Security Group Rules Evaluation Mismatch In Azure Virtual Networks, NSGs can be associated at two distinct layers: the Subnet level and the individual VM Network Interface (NIC) level. Inbound traffic MUST pass through BOTH security layers sequentially (Subnet NSG evaluated first, followed by NIC NSG). If the Subnet NSG allows TCP 3389 but the NIC NSG denies it (or lacks an explicit allow rule), packet processing terminates at the NIC boundary and drops the connection.
Step-by-Step Fix: 1 Identify Associated Security Groups:
Open Virtual Machines > Networking . Note the NSG name listed under Network Interface and the NSG name attached under Subnet . 2 Audit Both Security Group Layers:
Select the Subnet NSG resource and verify an active Allow rule exists for TCP 3389 targeting your source IP. Select the NIC NSG resource and verify an equivalent Allow rule exists for TCP 3389. 3 Consolidate Security Rule Overhead:
To minimize rule divergence, disassociate the NIC-level NSG if organization policy enforces security at the Subnet boundary: Copy
bash
az network nic update \
--resource-group MyResourceGroup \
--name MyVMNic \
--network-security-group ""4 Test Port Connectivity:
Test TCP port reachability from PowerShell on your local workstation: Copy
powershell
Test-NetConnection -ComputerName <VM_PUBLIC_IP> -Port 3389
Diagnose Packet Drops Using Azure Network Watcher IP Flow Verify
Solution:
Root Cause: Unidentified Rule Precedence or Application Security Group Dropping Traffic Complex network topology with multiple Application Security Groups (ASGs), Azure Firewalls, or custom security rules can make manual rule inspection unreliable. For comprehensive troubleshooting workflows, consult the
Microsoft Azure RDP Troubleshooting Documentation .
Step-by-Step Fix: 1 Launch Azure Network Watcher:
In the Azure Portal search bar, type Network Watcher and select it. Under Network diagnostic tools , select IP flow verify . 2 Execute Diagnostic Flow Verification:
Fill in target parameters: Subscription / Resource Group / Virtual Machine: Select your affected VM.Network Interface: Select primary NIC (eth0 / nic1).Protocol: TCPDirection: InboundLocal IPv4 address: Select VM primary internal private IP.Local port: 3389Remote IPv4 address: Enter your workstation public IP.Remote port: 55000 (or any ephemeral port).Click Check . 3 Evaluate Diagnostic Results:
If status returns Access denied , Network Watcher will display the exact NSG rule name (Subnet or NIC) causing the drop. Click on the rule name directly from Network Watcher to edit and correct its priority or action state.
Which guest operating system service, registry setting, or authentication mechanism is failing?
Windows Guest OS Firewall is blocking port 3389, or the Remote Desktop Service (TermService) is stopped.
Network Level Authentication (NLA) handshake fails, or self-signed TLS RDP certificate is corrupted.
The VM is configured to listen on a non-standard RDP port instead of default TCP 3389.
Enable Guest OS Remote Desktop Services & Windows Firewall via Azure Run Command
Solution:
Root Cause: Windows Service Crash or In-Guest Firewall Blockade Even when Azure NSG permits TCP 3389 at the infrastructure boundary, the connection will fail if the Windows guest OS internal firewall (mpsvc) drops traffic across Domain/Private/Public profiles, or if the Remote Desktop Service (TermService) is stopped or set to disabled.
Disable NLA Enforcement & Rebuild Corrupted RDP Certificates
Solution:
Root Cause: CredSSP/NLA Authentication Failure or TLS Certificate Corruption Network Level Authentication (NLA) enforces pre-authentication via CredSSP before initiating a full RDP session. If CredSSP trust is broken between client and guest OS, or if the guest VM's self-signed RDP certificate stored in Remote Desktop\Certificates becomes invalid/corrupted, the TLS handshake fails silently during session initiation.
Audit Custom Listening Port Registry Key in Windows Guest OS
Solution:
Root Cause: RDP Listening Port Mismatch in Windows Registry System administrators often modify the default RDP port in the Windows Registry to harden security. If the guest OS registry key PortNumber is changed to a custom port (e.g., 3390), but the Azure NSG or client RDP client still targets default port 3389, connections will time out.
Which Azure management, identity access policy, or public endpoint configuration is active?
Microsoft Defender for Cloud Just-In-Time (JIT) access policy is active and blocking connections.
Dynamic Public IP address was disassociated or changed following VM deallocation.
Azure Bastion connection fails with target port timeout or missing BastionSubnet NSG rules.
Request Temporary Access via Microsoft Defender Just-In-Time (JIT) VM Access
Solution:
Root Cause: Automatic NSG Locking Enforced by JIT Security Policy When Microsoft Defender for Cloud Just-In-Time (JIT) VM access is enabled, it automatically injects a high-priority DenyAllInbound rule into the VM's NSG. Any existing manual Allow rules on port 3389 are overridden until an authorized user submits an explicit JIT access request.
Re-associate Public IP and Convert Allocation from Dynamic to Static
Solution:
Root Cause: Dynamic IP Address Release Upon VM Deallocation Azure VMs configured with Dynamic Public IP addresses release their assigned IP back to the regional Azure pool whenever the VM is stopped/deallocated. Upon restarting the VM, Azure assigns a new public IP. Connecting to the old IP leads to connection timeouts.
Configure Azure Bastion Subnet NSG and Allow Inbound HTTPS/443 Traffic
Solution:
Root Cause: Missing AzureBastionSubnet Rules or Port 443 Inbound Drops Azure Bastion handles RDP connectivity by establishing secure TLS connections over port 443 from client web browsers directly to the VM over the internal Azure VNet backbone. If the AzureBastionSubnet NSG blocks inbound port 443 or blocks outbound port 3389 to the target VM subnet, Bastion fails.
How is network traffic routed between your local client workstation and the Azure Virtual Network?
User Defined Route (UDR) forces 0.0.0.0/0 traffic to a Network Virtual Appliance (NVA) causing asymmetric routing.
Azure VPN Gateway or ExpressRoute gateway is missing routes for Point-to-Site/Site-to-Site clients.
VNet Peering between management and workload virtual networks is missing 'Allow Forwarded Traffic' options.
Remediate Asymmetric Routing Caused by Route Table (UDR) Default Next-Hops
Solution:
Root Cause: Asymmetric Return Routing via Network Virtual Appliance (NVA) When a User Defined Route (UDR) with destination 0.0.0.0/0 (Next Hop: Virtual Appliance or Azure Firewall) is attached to a VM subnet, inbound RDP packets entering via Public IP are received directly by the VM, but outbound reply packets are redirected through the NVA. The NVA drops packets for non-stateful flows, causing client RDP handshakes to hang.
Propagate Routes and Authorization for Azure VPN Gateway & ExpressRoute
Solution:
Root Cause: Gateway Route Table Misconfiguration or Missing BGP Propagation When connecting over an Azure VPN Gateway (Point-to-Site/Site-to-Site) or ExpressRoute circuit, connection timeouts occur if the gateway route table does not propagate VNet address prefixes to the local client adapter, or if gateway transit is disabled.
Enable Virtual Network Peering Traffic Forwarding Permissions
Solution:
Root Cause: VNet Peering Settings Blocking Remote Virtual Network Transit When accessing a VM residing in a peered Spoke VNet from a Hub VNet jumpbox or gateway, RDP traffic drops if the VNet Peering connection options disallow routed traffic or gateway transit between peered virtual network spaces.