An Azure service that is used to provision Windows and Linux virtual machines.
Hello
Thank you for reaching out and describing the issue in detail. We understand that after removing several inbound and outbound rules from the Network Security Group (NSG) associated with your Azure Virtual Machine (to help reduce bandwidth usage), you can no longer connect to the VM (via RDP for Windows or SSH for Linux). I'm sorry for the inconvenience this has caused.
Azure NSGs include default rules that cannot be deleted. The DenyAllInBound rule (priority 65500) blocks all inbound traffic that doesn't match a higher-priority allow rule. When the custom allow rules for remote management ports were removed, RDP (TCP port 3389) or SSH (TCP port 22) traffic now hits this default deny rule.
The good news is that you can resolve this directly from the Azure portal without needing access to the VM itself. Here's the recommended solution:
Add an Inbound Security Rule
- Go to the Azure portal → Virtual machines → select your VM.
- In the left menu, select Networking.
- Under the Inbound port rules tab, click Add inbound port rule (or navigate to the associated NSG via Network security group link).
- Configure the new rule as follows (adjust based on your VM OS):
- Source: Your public IP address (recommended for security) or a specific range. (Avoid "Any" unless required.)
- Source port ranges: *
- Destination: Any
- Destination port ranges: 3389 (for Windows RDP) or22 (for Linux SSH)
- Protocol: TCP
- Action: Allow
- Priority: 300 (or any number lower than 65500; lower number = higher priority)
- Name: e.g., AllowRDP-MyIP or AllowSSH-MyIP
- Click Add and wait ~30–60 seconds for the rule to take effect.
- Test the connection again from your machine.
If your NSG is applied at both the subnet and network interface (NIC) levels, ensure the allow rule exists (or is mirrored) on both. Traffic must be permitted by every NSG in the path.
Note :
In the Azure portal, go to Network Watcher → IP flow verify (or search for it).
- Enter your VM details, source IP (your public IP), destination port (3389 or 22), and direction Inbound.
- This will instantly show which NSG rule (if any) is blocking the traffic and which NSG is responsible.
- Outbound rules: The default AllowInternetOutBound and AllowVnetOutBound rules usually remain intact. If you removed them, you may also need to add explicit allows for any required outbound traffic (e.g., Windows updates, package managers).
- Security tip: Always scope inbound rules to your specific public IP(s) rather than "Any" to reduce exposure. For ongoing bandwidth management, consider Azure Firewall or more granular NSG rules instead of broad removals.
- Alternative access while troubleshooting: If you prefer, enable Serial console (under VM → Operations → Serial console) for command-line access once the network rule is restored.
Thanks,
Manish.