Share via

VM unreachable externally on all ports (RDP 3389 and HTTP 80) — Public IP NAT issue suspected

The Pixel Shop 0 Reputation points
2026-04-29T15:58:21.3266667+00:00

I have a Windows Server 2016 VM that is unreachable from external networks on all ports, despite the VM being in a Running state.

VM Details:

  • Region: Canada Central
  • Private IP: Static (assigned via Azure NIC configuration)
  • Virtual Network: Custom VNet with default subnet

Issue:

The VM is not reachable externally on port 3389 (RDP) or port 80 (HTTP). Both PingSucceeded and TcpTestSucceeded return False from an external machine. However, the VM is accessible from other VMs within the same Azure Virtual Network, confirming the OS and services are running correctly.

Steps already taken:

  1. Confirmed NSG inbound rules allow port 3389 from source IP, Azure portal confirmed "Port 3389 is accessible from source IP"
  2. Confirmed public IP is correctly associated with the NIC's IP configuration
  3. Confirmed VM private IP matches Azure NIC configuration (Static)
  4. Verified Windows Firewall rules allow inbound on ports 80 and 3389 for all profiles
  5. Compared firewall configuration with a working VM (staging) in the same NSG — settings are identical
  6. Performed a full Stop (Deallocate) + Start to reset Azure networking fabric — issue persists

Suspected cause:

Azure networking fabric NAT routing between the public IP and private IP may be corrupted or stale following a DHCP failure event on the VM's NIC. The VM previously lost its internal IP and required a manual ipconfig /renew to restore it.

Request:

Has anyone experienced this issue? Could the DHCP failure have caused a stale NAT/routing state in Azure that a deallocate/start didn't fully reset?

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Alex Burlachenko 20,665 Reputation points MVP Volunteer Moderator
    2026-04-30T07:18:50.0533333+00:00

    hello The Pixel Shop & thx for join me here at Q&A portal,

    looks like VNet access works so VM is alive, external path broken means public IP/NIC ipconfig/effective rules, test with fresh public ip or fresh NIC.

    yeah again its look like Azure public ip to nic path is broken, but I would not blame DHCP first. if same VNet access works, OS and private IP path are fine.

    if external RDP and HTTP both fail, and NSG + Windows Firewall are clean, then check the actual NIC IP configuration public ip must be attached to the same primary ipconfig that owns the VM private IP. if there are multiple ipconfigs, stale public ip bindings can look correct in portal but not work, next check effective security rules and effective routes on the NIC, not just NSG rule list. portal “3389 accessible” is helpful but not proof NAT is healthy. check the public IP resource itself changed, is detached or stuck on Basic/Standard behavior mismatch.

    Standard public ip needs explicit NSG allow, basic behaves differently.

    Lets do a quick isolation test detach current public IP, create a brand new Standard static public IP, attach it to the NIC primary ipconfig, then test RDP/80 again. if new public IP works, old public IP mapping was stale/corrupt. if new public IP also fails, issue is NIC/ipconfig/routing, not public IP. DHCP failure inside guest can break guest networking, but Azure NAT maps to NIC private IP from platform metadata, not whatever Windows “thinks”, so stale Azure NAT from DHCP is less likely. if u want fastest recovery, create new NIC, attach same private IP if possible, attach new public IP, and swap it onto VM :)))

    rgds, Alex

    &

     pls if my answer helps pls accept it.
    0 comments

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.