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.
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.