Azure network security groups: trace a blocked connection from end to end

Write down the flow before inspecting rules

An NSG investigation should begin with a specific packet flow: source address, destination address, protocol, destination port and direction. A statement such as 'the server cannot connect' is too broad to compare against security rules. Record whether the application uses a private address, a public address or a hostname that can resolve differently on another network.

An NSG can be associated with a subnet or a network interface. Where both apply, the connection must satisfy the relevant rules at both layers. Rule priorities determine the evaluation order, and lower numbers are evaluated first. An allow rule that appears correct can still lose to an earlier deny rule or encounter a different restriction elsewhere in the path.

Distinguish rules from the rest of the network

NSGs are stateful. An established flow is handled differently from a new connection attempt, which matters when testing a rule change. Start a fresh connection during verification instead of relying on an already open session. Review the effective rules on the intended interface, including default rules, rather than considering only the custom rules visible on one NSG.

An allowed security decision does not guarantee successful delivery. Routes can direct traffic to an appliance, a guest firewall can reject it, and the destination service can be stopped or listening on a different address. A TCP timeout therefore needs a path investigation, while an application-level authentication response indicates that at least part of that path already works.

Use a structured diagnostic sequence

1. Resolve the destination from the affected host and record the resulting address.
2. Confirm the intended listener and port on the destination.
3. Inspect effective NSG rules and effective routes on the relevant VM interface.
4. Use Network Watcher IP flow verify for the specific supported VM flow to identify its security decision.
5. Check the guest firewall and any intermediate appliance, then retry a new connection.

IP flow verify helps identify whether an NSG rule permits or denies the specified traffic and which rule is responsible. It does not replace a full application request or prove the destination is healthy. Use it as one piece of evidence, alongside service logs and route inspection, rather than as a complete connectivity certificate.

Change only the rule the evidence justifies

If a source subnet and one service port are required, describe that pair explicitly. Opening all inbound ports or using the entire internet as a source makes the test less informative and can leave an unnecessary permanent exposure. Keep a short change note with the original flow, the responsible rule and the verification result.

Service tags and application security groups can make policy easier to maintain, but they do not remove the need to understand the destination and direction. Check what a selected tag represents for the current service. A readable rule name and a clear owner reduce the chance that future troubleshooting adds a second rule with overlapping behavior.

Validate after the application starts using the path

Test the real operation from the real source after the network change. Capture connection timing and service responses, and test an intentionally disallowed source where practical. Revisit the rule when the application changes ports or moves subnets. A connection problem is resolved when the required flow works consistently and the remaining access boundary is understood.

References

• Azure network security groups overview — Microsoft Learn
• IP Flow Verify Overview - Azure Network Watcher — Microsoft Learn