Forum Discussion
Issue with VirtualNetwork service tag when using UDR for routing via Azure Firewall
Hi Experts,
When I add a UDR on my Spoke Subnets to use Azure Firewall for default outbound (0.0.0.0/0 -> Azure Firewall IP), the Virtual Network service tag on the NSG attached to the Spoke Subnets gets 0.0.0.0/0 value. When I remove the UDR default outbound route, the Virtual Network service tag gets the vNet and Peered vNet address space etc.
Due to this, limiting network access at the NSG level on the Spoke Subnets is getting complex. For example, let's consider that I do not want to direct traffic to Azure Firewall for my S2S/P2S VPN traffic, and want to control which S2S IP Addresses can access my Spoke Subnet using NSG rule attached to my Spoke Subnet. This is getting complex as the Default DenyAllInbound is no longer applicable due to AllowVnetInbound allowing everything.
In such scenarios, the network control at the NSG level gets auto-updates and gets allowed for all (0.0.0.0/0 - 0.0.0.0/0 - All Protocols), and the concept of having default DenyAllInbound as the last rule fails. This could be a security risk where the engineer has added a UDR for 0.0.0.0/0 to Subnets and all the NSGs would turn to Allow All (Everything).
Related GitHub Discussion:
https://github.com/MicrosoftDocs/azure-docs/issues/22178
FYI, I just found out a blog also reporting a similar challenge that I am facing: https://www.torivar.com/2019/01/16/azure-nsg-virtualnetwork-tag/
- This behavior is actually by design. It is also documented here: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview
If you see the description of the VirtualNetwork service tag it says:
The virtual network address space (all IP address ranges defined for the virtual network), all connected on-premises address spaces, peered virtual networks, virtual networks connected to a virtual network gateway, the virtual IP address of the host, and address prefixes used on user-defined routes. This tag might also contain default routes.
So UDR entries will directly affect the address prefixes in the VNET service tag. There is no way to change this behavior. You will have to create your own NSG rules instead of relying on the default ones.
