Diagnose Azure Network Security Group rules that block RDP, SSH, HTTPS or application traffic.
Start with Identify the blocked flow and work through the six diagnostic checks in order.
Record results before changing configuration and validate the original symptom after each controlled change.
Quick checks
Start with the basic checks in this runbook before moving to deeper troubleshooting.
- Confirm the affected service or component is available.
- Check recent configuration or connectivity changes.
- Run the relevant commands and compare the result with the expected state.
Identify the blocked flow
Capture the source, destination, protocol and port for the failing connection before changing any security rule.
Check subnet and NIC NSGs
Review effective security rules from both the subnet and network interface because a matching rule at either level can affect the flow.
Use IP flow verify
Use Azure Network Watcher IP Flow Verify to identify whether Azure permits or denies the flow and which rule is responsible.
Check rule priority
Check whether a matching deny rule has a higher evaluation priority than the intended allow rule.
Check ASGs and service tags
Verify Application Security Groups and service tags reference the intended source and destination.
Retest the application path
Retest the same network path after the confirmed blocking rule is corrected.
Useful commands
Run these checks from an appropriate administrative session and replace example values with your environment.
IP Flow Verify
az network watcher test-ip-flow --resource-group <resource-group> --vm <vm-name> --direction Inbound --protocol TCP --local <private-ip>:<port> --remote <source-ip>:<source-port>Effective NSGs
az network nic list-effective-nsg --resource-group <resource-group> --name <nic-name>Quick troubleshooting path
Use this sequence to isolate the failing dependency before changing production configuration.
- Identify the blocked flow → Capture the source, destination, protocol and port for the failing connection before changing any security rule.
- Check subnet and NIC NSGs → Review effective security rules from both the subnet and network interface because a matching rule at either level can affect the flow.
- Use IP flow verify → Use Azure Network Watcher IP Flow Verify to identify whether Azure permits or denies the flow and which rule is responsible.
- Check rule priority → Check whether a matching deny rule has a higher evaluation priority than the intended allow rule.
- Check ASGs and service tags → Verify Application Security Groups and service tags reference the intended source and destination.
- Retest the application path → Retest the same network path after the confirmed blocking rule is corrected.
What good troubleshooting looks like
Good infrastructure troubleshooting is evidence-driven. Capture the original state, test the dependency that can prove or disprove your hypothesis, make the smallest safe change and repeat the original test.
Symptom → hypothesis → direct test → result → controlled change → validation → documentation