Before you design any rule set, you need to know which rules apply to a flow, in which direction, and what the platform allows before you write anything yourself.
Direction, statefulness and scope
- Network security groups (NSGs) are evaluated per direction: an outbound rule on the destination subnet’s NSG does nothing to inbound connections arriving there. Only the inbound rules at the destination decide whether an incoming connection is accepted.
- NSGs are stateful: return traffic for an allowed flow is allowed automatically.
- A subnet NSG also filters traffic between VMs in the same subnet. One NSG on the subnet covers every VM deployed to it, which is the least administrative effort.
Common trap: Treating an outbound rule on the destination’s NSG as if it could block (or allow) inbound traffic - NSG rules only apply in their own direction, so for traffic arriving at a subnet only the destination NSG’s inbound rules count (and the source’s outbound rules on the way out).
Default rules
- Every NSG gets six default security rules at the bottom of the priority range. Inbound: AllowVnetInBound, AllowAzureLoadBalancerInBound and DenyAllInBound. Outbound: AllowVnetOutBound, AllowInternetOutBound and DenyAllOutBound. You can’t delete them, only override them with higher-priority rules.
- Traffic from inside the VNet to a subnet whose NSG has only default rules is allowed (by AllowVnetInBound). Unsolicited traffic from the internet is not: DenyAllInBound blocks it, even when the VMs sit behind a public load balancer. You need an explicit inbound allow for internet-facing ports. Figure 13.1 follows one such flow through the destination NSG’s inbound rules.
- The VirtualNetwork service tag used by the default rules includes the subnet itself plus peered and connected address ranges.
