Azure NSG & VNet Connectivity Debug Prompt
Diagnose why traffic is being dropped between Azure subnets, VNets, or out to the internet by reasoning through NSG rules, effective routes, and peering.
- Target user
- Cloud network engineers and platform teams debugging Azure connectivity
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure network engineer who debugs connectivity by tracing the full path: NSG rules (both subnet and NIC level), effective routes/UDRs, VNet peering, and service endpoints/private endpoints — not by guessing. I will provide: - The symptom — source, destination, port, protocol, and what "works" vs "fails" — [SYMPTOM] - NSG rules, e.g. `az network nsg rule list --nsg-name <nsg> -g <rg> -o table` for the relevant NSGs — [NSG_RULES] - Effective rules/routes if I have them: `az network nic list-effective-nsg` / `list-effective-route-table` — [EFFECTIVE_RULES] - Topology: VNets, subnets, peerings, any firewall/NVA, private endpoints — [TOPOLOGY] - Any IP Flow Verify or Connection Troubleshoot output — [DIAGNOSTICS] Your job: 1. **Restate the path** — exact 5-tuple (src IP, dst IP, dst port, protocol, direction) the traffic should take, and where it likely dies. 2. **NSG evaluation** — walk the rules in priority order for both directions. NSGs are stateful, so check that the INITIATING direction is allowed; return traffic is automatic. Identify the deny (explicit rule or the default DenyAllInbound/Outbound) that's blocking. 3. **Subnet vs NIC NSG** — remember both can apply; traffic must pass BOTH. Flag conflicts. 4. **Routing** — check effective routes for a UDR (e.g. 0.0.0.0/0 to a firewall) that black-holes or redirects traffic; check peering `allowForwardedTraffic` / gateway transit. 5. **Service/private endpoints** — if the destination is a PaaS service, check whether a private endpoint or service endpoint changes the expected destination IP and which NSG/subnet applies. 6. **Targeted next checks** — give the exact `az network watcher test-ip-flow` / `test-connectivity` commands to confirm the hypothesis. Output as: (a) most-likely root cause with the specific blocking rule/route named; (b) ranked alternative causes; (c) the minimal rule/route change to fix it (priority, direction, ports); (d) the verification command to run after. Use only the rules and topology I gave you. Don't assume rules that aren't shown — ask for the missing NSG or route table instead.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Azure connectivity failures are almost always a layered problem, and the classic mistake is to look only at the NSG nearest the symptom. Real diagnosis means tracing the whole path: subnet-level NSG, NIC-level NSG, effective routes including any user-defined route that sends traffic to a firewall, VNet peering settings, and whether a private endpoint has quietly changed the destination IP. This prompt encodes that path-tracing discipline and asks for the specific az network outputs that make the reasoning concrete instead of speculative.
A key piece of correct NSG reasoning is that NSGs are stateful and evaluated by priority. Engineers waste hours adding return-traffic rules that aren’t needed, or miss that the default DenyAllOutbound is the real culprit. By forcing the model to walk rules in priority order for the initiating direction and to remember that both subnet and NIC NSGs must pass, the prompt avoids the most common false fixes.
The output is built to keep you in control: it names the exact blocking rule or route, proposes the minimal scoped change, and hands you the Network Watcher command to verify before you trust it. The guardrails specifically prevent the lazy “Allow Any Any” fix and the dangerous habit of rerouting around a firewall, both of which turn a connectivity ticket into a security incident.
Related prompts
-
AKS Troubleshooting Deep-Dive Prompt
Systematically diagnose AKS issues across networking, workload identity, and pod scheduling by correlating kubectl output with Azure-side configuration.
-
Azure UDR & Hybrid Route Table Connectivity Review Prompt
Review user-defined routes, VNet peering, and forced-tunneling config across a hub-and-spoke topology to find the route that blackholes traffic or bypasses the firewall, and explain the effective-route resolution causing the connectivity break.
-
Azure ExpressRoute Circuit & Peering Connectivity Review Prompt
Review an ExpressRoute circuit and its peerings to explain why on-premises to Azure connectivity is failing or asymmetric by analyzing BGP session state, advertised/received routes, gateway SKU limits, and route filters for private and Microsoft peering.
-
Azure VNet Peering & Transit Routing Review Prompt
Review VNet peering topology, gateway transit, and route propagation to explain why traffic between peered or hub-spoke VNets is dropping, and to design correct transitive routing without accidental full-mesh sprawl.
More Azure with AI prompts & error guides
Browse every Azure with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.