NSG rule evaluation in Azure
A network security group (NSG) is a list of allow and deny rules; Azure checks a packet against the rules in priority order, lowest number first, and stops at the first match. If nothing you wrote matches, three default rules decide: traffic inside the virtual network is allowed, Azure load balancer probes are allowed, and everything else inbound is denied. The rest of this page traces packets through that logic.
The rules of the game
- Priority is a number from 100 to 4096. Lower number means evaluated first. Two rules in the same direction cannot share a priority.
- Each rule matches on source, source port, destination, destination port and protocol, and then allows or denies.
- NSGs are stateful. If a connection is allowed in one direction, the reply is allowed without a rule in the other direction.
- Rule changes affect new connections only. An open SSH session survives the removal of the rule that allowed it.
- Default rules cannot be removed, but a rule with a lower priority number overrides them. They sit at 65000 and above, so yours always run first.
The default rules in every NSG:
| Direction | Name | Priority | What it does |
|---|---|---|---|
| Inbound | AllowVNetInBound | 65000 | Allow from VirtualNetwork to VirtualNetwork |
| Inbound | AllowAzureLoadBalancerInBound | 65001 | Allow from AzureLoadBalancer |
| Inbound | DenyAllInbound | 65500 | Deny everything else |
| Outbound | AllowVnetOutBound | 65000 | Allow VirtualNetwork to VirtualNetwork |
| Outbound | AllowInternetOutBound | 65001 | Allow to the Internet |
| Outbound | DenyAllOutBound | 65500 | Deny everything else |
Note the asymmetry: outbound to the internet is open by default, inbound from the internet is closed. VirtualNetwork is a service tag, and it includes peered VNets, so peered networks can reach each other through the default allow unless a rule says otherwise. See VNets, subnets and peering for the peering side.
Worked packet examples
A subnet NSG has these custom rules, all inbound:
| Priority | Name | Source | Destination port | Action |
|---|---|---|---|---|
| 100 | Allow-Web | Internet | TCP 443 | Allow |
| 200 | Deny-Partner | 198.51.100.0/24 | TCP 443 | Deny |
| 300 | Allow-Admin | 10.1.0.0/16 | TCP 22 | Allow |
- A customer at 203.0.113.9 connects to TCP 443. Rule 100 matches (source is the internet) and allows it. Done.
- A host in 198.51.100.0/24 connects to TCP 443. Rule 100 matches first because the internet tag covers that address, and allows it. Rule 200 is never reached. The deny is dead. Fix: give the deny a number lower than the allow, which means moving the allow to, for example, 250 (not 300, which Allow-Admin already uses in the same direction).
- A host in 10.1.4.4 connects to TCP 22. Rule 300 matches and allows it. If 10.1.0.0/16 is inside the VirtualNetwork tag (the VNet or a peered VNet), AllowVNetInBound would have allowed it anyway, so the rule matters only for sources outside the tag. Note that the tag also covers on-premises ranges connected through a VPN or ExpressRoute gateway.
- A host on the internet connects to TCP 3389. No custom rule matches. AllowVNetInBound and AllowAzureLoadBalancerInBound do not match, and DenyAllInbound at 65500 drops it.
A common mistake in step 2 is trying to fix it with priority 90. That number is out of range. The minimum is 100.
Subnet NSG plus NIC NSG
An NSG can be associated with a subnet, with a network interface, or with both. For inbound traffic Azure processes the subnet NSG first and then the NIC NSG. Outbound is the reverse: NIC, then subnet. The packet must be allowed by both. Each evaluation is separate, with its own defaults.
Example: the subnet NSG above allows TCP 443 from the internet at priority 100. The VM’s NIC also has an NSG, containing only default rules. The packet passes the subnet check and reaches the NIC NSG, where no rule allows it and DenyAllInbound drops it. The VM is unreachable although the subnet rule looks right. Microsoft’s guidance is to associate an NSG with either the subnet or the network interface, but not both, which avoids this class of fault.
Also remember: if neither the subnet nor the NIC has an NSG, no NSG filters the traffic. Outbound flows freely, but a VM with a Standard public IP (the only SKU since Basic public IPs were retired on 30 September 2025) is still closed to inbound internet traffic, because Standard public IPs are secure by default and need an NSG to allow traffic in.
Finding out what is actually in force
- Effective security rules on a NIC shows the combined rules from both NSGs, in separate tabs (the portal lists the first 50 and lets you download all). Duplicate default rules in the output are normal.
- IP flow verify in Network Watcher tests one specific packet and names the rule that allows or denies it.
- Application security groups let rules use “all web servers” as source or destination instead of IP addresses.
- Security admin rules from Azure Virtual Network Manager are evaluated before NSG rules. A deny or always-allow there ends evaluation before the NSG is consulted.
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| AZ-104 | Implement and manage virtual networking: create and configure NSGs and application security groups, and evaluate effective security rules | Virtual networking guide |
| AZ-305 | Design infrastructure solutions: recommend a solution to optimize network security, where NSGs sit next to Azure Firewall, private endpoints and Bastion. A minor topic: design choices, not rule-by-rule evaluation | Infrastructure design guide |
| SC-500 | Secure storage, databases and networking: implement and manage NSGs and ASGs, and evaluate effective security rules with Network Watcher diagnostics | Storage, databases and networking guide |
| SC-900 | Capabilities of Microsoft security solutions: describe NSGs among the core infrastructure security services. Describe level only, so priority details are rarely needed (same objective in the outline that applies from October 21, 2026) | Security solutions guide |
How exam questions are built around NSGs
Dead rules. A deny with a higher number than a matching allow. Always sort the rules by priority in your head before reading what they say.
Two NSGs. One looks correct, the other silently denies. The answer is to check or fix the second one, or to look at effective rules.
NSG versus the alternative. NSGs filter by address, port and protocol. SQL injection means a WAF; centralised FQDN-based egress control means Azure Firewall.
Constraint words: “first match”, “lowest number”, “existing connection”, “new connection”, “without changing the application”.
Two practice questions
Question 1. An NSG has an inbound rule at priority 100 that allows TCP 80 from any source. Administrators must now block TCP 80 from 198.51.100.0/24 while keeping access for everyone else. What should they do?
- A. Add a deny rule for the range at priority 110
- B. Add a deny rule for the range at priority 90
- C. Change the allow rule to priority 200 and add a deny rule for the range at priority 150
- D. Add a deny rule for the range at priority 100
Show answer
Answer: C
The first matching rule wins, so a deny must have a lower priority number than the allow. Priority 90 is invalid because the minimum is 100, and a deny at 110 is never reached. Two rules in the same direction cannot share priority 100. Changing the allow to a higher number such as 200 and adding the deny at 150 gives the correct order.
Question 2. A subnet NSG allows inbound TCP 443 from the internet at priority 100. The only VM in the subnet has a network interface with its own NSG that contains only the default rules. Users on the internet cannot reach the VM on port 443. What is the most likely fix?
- A. Add an inbound allow rule for TCP 443 to the NIC NSG
- B. Delete the DenyAllInbound rule from the NIC NSG
- C. Add an outbound allow rule for TCP 443 to the NIC NSG
- D. Change the subnet rule priority to 4096
Show answer
Answer: A
Inbound traffic must be allowed by both the subnet NSG and the NIC NSG. The NIC NSG has only defaults, so DenyAllInbound blocks internet traffic. Adding an allow rule for TCP 443 to the NIC NSG, or dissociating that NSG, fixes it. Deleting default rules is not possible, and raising the subnet rule priority changes nothing about the NIC check. Outbound rules are not involved because NSGs are stateful.
Go deeper
- Network security groups overview, Microsoft Learn
- Diagnose a VM network traffic filter problem, Microsoft Learn
- Application security groups, Microsoft Learn
- Related on this site: VNets, subnets and peering, zero trust explained, multiple-choice exam tips