Azure Virtual Machine: Unable to connect through RDP after enabling Network Security Group rules

Griego Macdonald 0 Reputation points
2026-08-11T06:30:17.5666667+00:00

I’m using an Azure Windows Virtual Machine and I’m trying to connect to it through Remote Desktop (RDP) from my local Windows 11 computer.

The VM is running normally, but the RDP connection fails after I configured the Network Security Group (NSG) rules. I have already verified that the VM is running and that the RDP service is enabled.

Environment:

  • Azure Windows Virtual Machine
  • Windows 11 client
  • Remote Desktop (RDP)
  • Network Security Group (NSG)

What I have tried:

  • Confirmed that the VM is running.
  • Checked the NSG inbound rules.
  • Verified that TCP port 3389 is allowed.
  • Restarted the virtual machine.
  • Retried the RDP connection from another network.

Result:

The RDP connection still fails with an authentication/connection error.

What should I check next to determine whether the issue is caused by the NSG, Windows Firewall, or the RDP configuration inside the VM?I’m using an Azure Windows Virtual Machine and I’m trying to connect to it through Remote Desktop (RDP) from my local Windows 11 computer.

The VM is running normally, but the RDP connection fails after I configured the Network Security Group (NSG) rules. I have already verified that the VM is running and that the RDP service is enabled.

Environment:

  • Azure Windows Virtual Machine
  • Windows 11 client
  • Remote Desktop (RDP)
  • Network Security Group (NSG)

What I have tried:

  • Confirmed that the VM is running.
  • Checked the NSG inbound rules.
  • Verified that TCP port 3389 is allowed.
  • Restarted the virtual machine.
  • Retried the RDP connection from another network.

Result:

The RDP connection still fails with an authentication/connection error.

What should I check next to determine whether the issue is caused by the NSG, Windows Firewall, or the RDP configuration inside the VM? I want to know, are they expert to know this matter: https://paranoid.security/en

Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 28,050 Reputation points Independent Advisor
    2026-08-11T08:28:28.2266667+00:00

    Hello,

    Since you’ve already confirmed that TCP 3389 is allowed in the NSG, the next step is to isolate whether the block is happening at the VM’s Windows Firewall or at the RDP listener itself. Start by checking the effective NSG rules applied to the VM’s NIC and subnet. In Azure, NSG rules are cumulative, and a deny rule at the subnet level can override what you configured at the NIC. Use az network nic effective-nsg list --name <NICName> --resource-group <RGName> to confirm that inbound TCP 3389 is truly allowed from your source IP.

    If the NSG looks correct, log into the VM via Azure Serial Console or use Run Command from the portal. Run netstat -an | findstr 3389 to verify that the RDP service is listening on 0.0.0.0:3389. If it is not, check the registry key HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp and confirm the PortNumber value is set to 3389. Also confirm that fDenyTSConnections under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server is set to 0.

    On the Windows Firewall side, ensure the inbound rule for Remote Desktop is enabled. You can check with Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select Name, Enabled. If the rules are disabled, re-enable them.

    Finally, confirm that you are connecting with the correct public IP of the VM. If the VM is behind a load balancer or has a changed IP, the RDP attempt will fail regardless of NSG. You can verify the current public IP in the Azure portal under Networking.

    If all of the above checks out, but you still get authentication errors, it may be a case of Network Level Authentication (NLA) mismatch. Ensure your local client supports NLA and that the VM has it enabled under System Properties > Remote.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    HP.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-08-11T06:30:47.45+00:00

    Next checks should focus on proving where the block occurs.

    1. Use Network Watcher > IP flow verify first.
      • In Azure portal, open Network Watcher.
      • Go to IP flow verify.
      • Select the affected VM and its primary NIC.
      • Set Protocol to TCP.
      • Set Direction to Inbound.
      • Set Local port to 3389.
      • Set Local IP address to the VM private IP.
      • Set Remote IP address to the public IP of the client network being used.
      • Use any remote port such as 60000.
      • Select Check.
      Expected result:
      • If it shows Denied, the output also shows the NSG rule causing the block.
      • If it shows Allowed, the NSG path is likely correct and the issue is more likely inside the VM or elsewhere in networking.
    2. Review Effective security rules on the VM NIC.
      • Go to Virtual Machines > select the VM.
      • Open Networking > Network settings.
      • Select the NIC name.
      • Under Help, open Effective security rules.
      • Check inbound rules affecting TCP 3389.
      Verify these points:
      • An Allow rule exists for 3389/TCP.
      • The allow rule has a higher priority than any matching deny rule. In Azure, lower number = higher priority.
      • If NSGs exist on both subnet and NIC, RDP must be allowed by both.
    3. Check for common NSG misconfigurations.
      • A broad deny rule with a higher priority can override the RDP allow rule.
      • A subnet NSG may allow RDP while the NIC NSG still blocks it, or the reverse.
      • The source IP restriction may be too narrow. If the inbound rule allows only one source IP, confirm the current client public IP exactly matches that rule.
    4. If NSG checks pass, reset the RDP configuration from Azure. Since the VM is running and port 3389 has already been reviewed, the next Azure-side test is to reset the RDP configuration:
      • In Azure portal, open the VM.
      • In the Help section, select Reset password.
      • Set Mode to Reset configuration only.
      • Select Update.
      This is the documented step when Remote Connections are disabled or Windows Firewall rules are blocking RDP.
    5. If needed, reset credentials separately. If the connection reaches the VM but fails at sign-in, use the same Reset password area and choose Reset password mode to set a known local administrator password.
    6. Continue with Azure VM checks if RDP still fails.
      • Review Boot diagnostics for startup issues.
      • Check Resource health and confirm the VM reports Available.
      • If still unresolved, try Redeploy. Risk: redeploy can cause ephemeral disk data loss and dynamic IP addresses associated with the VM are updated.
    7. Also confirm the basic access path.
      • If the Connect button is grayed out and there is no Express Route or Site-to-Site VPN, the VM needs a public IP address for direct RDP.
      • Verify local network equipment such as routers or firewalls is not blocking outbound TCP 3389.

    A practical decision path is:

    • IP flow verify = Denied → fix NSG rule, priority, subnet/NIC conflict, or source IP restriction.
    • IP flow verify = Allowed but RDP still fails → use Reset configuration only, then check credentials, boot diagnostics, and resource health.

    The question about the external company is outside scope.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.