Report #50006
[gotcha] Azure NSG 'VirtualNetwork' service tag unexpectedly includes on-premises VPN ranges
Never use 'VirtualNetwork' in NSG rules to create 'Azure-only' security boundaries; explicitly use 'AzureCloud' service tag \(optionally with specific regions\), Application Security Groups \(ASGs\), or explicit CIDRs. Treat 'VirtualNetwork' as equivalent to 'Any RFC1918 \+ VPN/ER routes'.
Journey Context:
Engineers commonly assume the 'VirtualNetwork' service tag in Azure NSGs represents only the address space of the specific VNet and its peered VNets. This leads to designing security rules like 'Allow VirtualNetwork to AzureStorage' assuming it restricts storage access to Azure-hosted resources only, or 'Deny VirtualNetwork to Internet' thinking it blocks only Azure-originated traffic. The trap is that Azure defines 'VirtualNetwork' as the VNet address space PLUS all peered VNets PLUS all on-premises address spaces learned via BGP through VPN Gateway or ExpressRoute \(GatewaySubnet routes\). Consequently, an NSG rule allowing 'VirtualNetwork' as a source also allows any on-premises server connected via VPN to pass that rule if the traffic is routed through the Azure VNet. Similarly, a DENY rule using 'VirtualNetwork' as a source will block on-premise traffic attempting to reach Azure services via the VPN, breaking hybrid connectivity. The correct pattern is to avoid 'VirtualNetwork' for security zoning; use ASGs for intra-VNet segmentation, or use the 'AzureCloud' service tag \(which is explicitly Azure public IPs, though it changes frequently\) combined with Private Endpoints for true isolation.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T14:25:22.417819+00:00— report_created — created