Azure Virtual Network Manager: diagnose a Security Admin rule before changing NSGs

An application can no longer reach an internal API on port 443. The application team finds an NSG that allows the flow, adds a broader rule, and gets the same timeout. The packet never reaches NSG evaluation: an Azure Virtual Network Manager Security Admin rule stops it earlier in the chain.

This runbook covers an Azure estate where a central team applies network guardrails across VNets while product teams own subnet or NIC NSGs. Its purpose is to identify the rule that actually decides the flow, prove its scope, then choose a targeted correction, governed exception, maintained block, or rollback of the latest regional deployment.

Freeze the exact flow before editing rules

“HTTPS is down” is not a network incident scope. Capture a testable tuple: source, destination, protocol, ports, direction, VNet, region, and UTC time. Keep an unaffected control flow as well. Without that comparison, a global rule, local NSG, route, or target service can produce the same symptom.

Incident: inc-20260902-014
First observed: 2026-09-02T14:18:00Z
Last known success: 2026-09-02T13:55:00Z

Affected flow
Source VM: vm-orders-prod-02
Source IP: 10.42.8.17
Source VNet: vnet-orders-prod-weu
Destination IP: 10.60.4.21
Destination port: 443/TCP
Direction: outbound
Region: westeurope

Control flow
Same source to 10.60.4.22:443 succeeds

Evidence to preserve
effective Security Admin rules
IP Flow Verify result and rule name
VNet flow log tuple
network group membership
active configuration and regional deployment status
NSG effective rules
application test and UTC timestamps

Do not start with a 0.0.0.0/0 opening, lower NSG priority, or NSG removal. A Security Admin Deny can terminate evaluation before the NSG. Widening the NSG then changes nothing and leaves security debt behind after the incident.

Read the evaluation order correctly

Azure Virtual Network Manager evaluates Security Admin rules before NSGs. The action determines what happens next:

• Allow passes the flow to NSG evaluation, where it can still be denied;
• Always Allow permits the flow and skips further NSG evaluation;
• Deny blocks the flow and skips further NSG evaluation.

The lowest numerical priority is evaluated first. An exception Allow at priority 10 can therefore precede a global Deny at priority 100 while still leaving local policy to the NSG. An Always Allow exception is much stronger because it also bypasses an NSG denial. Keep it rare, explicit, and tied to a governance requirement.

Packet
|
v
Security Admin rules, lowest priority number first
Deny         -> blocked, stop
Always Allow -> allowed, stop before NSG
Allow        -> continue
no match     -> continue
|
v
Subnet and NIC NSG rules
Allow or Deny
|
v
Route, destination listener, TLS and application checks

This model also prevents the opposite mistake: blaming every denial on Virtual Network Manager. If IP Flow Verify returns a Security Admin Allow, the NSG remains in the path. If filtering permits the tuple, move on to routes, the target listener, and application protocol evidence.

Prove the effective rule on the VNet

Inspect effective state, not only the expected IaC file. A VNet may enter a dynamic network group after a tag or subscription change. A configuration may also be edited without being redeployed to the region, or may still be converging after deployment.

The following commands use the Azure CLI virtual-network-manager extension. Adapt the names to the real scope and retain the outputs in the incident record.

RG_NET="rg-network-governance"
NETWORK_MANAGER="avnm-platform-prod"
VNET_RG="rg-orders-prod"
VNET="vnet-orders-prod-weu"
REGION="westeurope"

az network manager list-effective-security-admin-rule --resource-group "$VNET_RG" --virtual-network-name "$VNET" --output json

az network manager list-active-security-admin-rule --resource-group "$RG_NET" --network-manager-name "$NETWORK_MANAGER" --regions "$REGION" --output json

az network manager list-deploy-status --resource-group "$RG_NET" --network-manager-name "$NETWORK_MANAGER" --regions "$REGION" --deployment-types SecurityAdmin --output json

Compare four objects: the rule effective on the VNet, the rule active in the region, the configuration definition, and declared IaC intent. A global Deployed status confirms regional deployment, not by itself the behavior of every NIC. The real tuple still needs to be tested.

Ask IP Flow Verify which rule decides

For a VM, IP Flow Verify evaluates the security and admin rules applied to its interface. The result gives a decision and the responsible rule. Use the NIC’s real local IP and the remote IP of the failing flow.

VM_RG="rg-orders-prod"
VM="vm-orders-prod-02"

az network watcher test-ip-flow --resource-group "$VM_RG" --vm "$VM" --direction Outbound --protocol TCP --local "10.42.8.17:*" --remote "10.60.4.21:443" --output json

Repeat the test against the control destination. If the affected flow returns a Security Admin Deny and the control returns Allow, the comparison is actionable. If both are allowed, filtering is not the cause: inspect the effective route, listener on 443, TLS, and target service logs.

IP Flow Verify does not replace an application test. It proves a filtering decision for the supplied tuple, not that a server responds, a certificate is valid, or an API accepts the caller’s identity.

Confirm the decision with VNet flow logs

VNet flow logs add time-based evidence. For an Azure Virtual Network Manager decision, aclID identifies the evaluating resource, flowGroups[].rule carries the rule name, and the tuple records direction and state. A D state under a Security Admin rule name is the blocked flow.

{
"aclID": "/subscriptions/<sub>/resourceGroups/rg-network-governance/providers/Microsoft.Network/networkManagers/avnm-platform-prod",
"flowGroups": [
  {
    "rule": "Deny-Prod-To-Shared-Except-Approved",
    "flowTuples": [
      "1788358740000,10.42.8.17,10.60.4.21,52344,443,6,O,D,NX,0,0,0,0"
    ]
  }
]
}

Flow logging must be enabled on each VNet that needs coverage. If it did not exist before the incident, do not present missing logs as proof that traffic was allowed. Retain IP Flow Verify, effective rules, deployment status, and destination logs instead, then add the observability gap to the follow-up work.

Explain why the VNet is in scope

A correct rule can apply to the wrong VNet. Check the Network Manager scope, targeted network group, and membership type. For dynamic membership, record the tags, resource group, subscription, and compliance result that included the VNet.

Then answer three questions:

• do the source and destination match the intended prefixes?
• should the VNet have belonged to this network group at that time?
• is the planned exception a higher-priority rule, or merely a local NSG that cannot override the global Deny?

Security Admin rules are not applied uniformly to every Azure networking case. Some managed-service subnets are exempt, and private endpoints are not covered by these rules. Use that boundary to refine the diagnosis, not to make Private Endpoint the default explanation for every failure.

Choose a bounded correction

The evidence determines the action:

Rule is correct and flow must stay blocked
Keep Deny
Fix caller, target or architecture
Remove temporary NSG openings created during diagnosis

VNet entered the wrong network group
Correct membership condition or tag
Validate the resulting member set before regional deployment

Legitimate narrow exception is missing
Add higher-priority Allow for exact source, destination and port
Keep downstream NSG evaluation
Avoid Always Allow unless bypassing NSG is explicitly required

Last deployment introduced an overbroad rule
Restore the previous tested configuration as regional goal state
Commit only the affected regions
Verify convergence and effective rules

Filtering is not the cause
Stop changing Security Admin rules and NSGs
Continue with routing, listener, TLS, identity and application evidence

Prefer Allow over Always Allow when the application team should retain tighter NSG filtering. Every exception needs an owner, rationale, review date, and negative test proving that a neighboring flow remains denied.

Canary the deployment and prepare rollback

A Security Admin configuration is deployed by region and follows an eventual consistency model. Do not declare success after the first allowed packet. Start with a canary network group or lower-risk region, inspect deployment status and effective rules, test several tuples, then expand.

Rollback is not an improvised rule deletion. Restore a known configuration, redeploy it as the regional goal state, and prove that the former decision has returned. Only one Security Admin configuration from a Network Manager can be deployed to a region. Omitting a configuration from a later commit can remove it from the goal state, so review the complete list before approval.

Before deployment
Diff configuration, collections, priorities and network groups
Export current active rules and regional goal state
Record positive and negative test tuples
Confirm rollback configuration and authorized operator

Canary validation
Deployment status is Deployed
Expected rule is effective on canary VNet
Required flow passes IP Flow Verify and application test
Neighboring unauthorized flow remains denied
VNet flow log names the expected deciding rule

Rollback trigger
broader source or destination becomes reachable
Always Allow bypasses an intended NSG control
unexpected VNets enter the targeted group
deployment state differs across regions
effective rules cannot be reconciled with declared intent

Conclusion

When a Security Admin rule is involved, changing an NSG is often ineffective and can become a later security gap. Start from the tuple, follow Security Admin then NSG evaluation, inspect effective rules, confirm with IP Flow Verify and VNet flow logs, and explain the VNet’s membership.

The final decision must remain operable: preserve a justified block, create a narrow Allow exception, correct network group membership, or redeploy the last known configuration. The incident is closed when the required flow works, the negative flow stays blocked, and rollback remains provable.