Network Security Groups in Azure give the possibility of doing some simple ACL filtering between - and inside of - subnets, or directly on NICs. Read here for more information about NSGs.

Anyway, my post today is not generally about the NSGs, but more precisely about one of the Service Tags that can be used for source or destination filtering. Turns out this is automatically updated with more than just your Vnet and Peerings + VPN, as stated in the description.

The VirtualNetwork tag is added to all your NSGs in some of the default rules. This means that all prefixes in the tag, is allowed inbound and outbound traffic across the NSG.

This is the content of VirtualNetwork tag before adding route.

In this case I wanted to force all outbound traffic for all unknown network prefixes through a dedicated Network Virtual Appliance. This is done by adding a route of 0.0.0.0/0 to associated routing table on the applicable subnet.

This is the added route for 0.0.0.0/0.

Imagine my surprise when the VirtualNetwork tag suddenly was replaced with the dreaded 0.0.0.0/0 (or any IP address).

0.0.0.0/0 added to VirtualNetwork tag, effectively allowing all traffic in and out via default NSG rules.

Turns out this happens when you use a routing table to force traffic from subnet to a Network Virtual Appliance (in my experience, but I have not found anything official from Microsoft to back this up).

This becomes a problem when you add a DenyVnetOutBound NSG rule, to further isolate the subnets and traffic inside the subnets. Then you need more allow rules with higher priority.