Issue with VirtualNetwork service tag when using UDR for routing via Azure Firewall

Question

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/

Answer 1

Hello @Sibba Sailor ,

I understand that you are facing issues with VirtualNetwork service tag in NSG, when using UDR for routing via Azure Firewall. When you add a UDR on your Spoke Subnets to use Azure Firewall for default outbound (0.0.0.0/0 -> Azure Firewall IP), the VirtualNetwork service tag on the NSG attached to the Spoke Subnets gets 0.0.0.0/0 prefix value.

I discussed this behavior with the Azure Virtual Network Product Group team, and they confirmed that this is expected behavior.

Virtual Network tag includes VNet address prefixes, peered prefixes and on-prem prefixes propagated via VPN or Express route gateway.

Refer: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview

To avoid this, either stop propagating 0.0.0.0/0 and use more specific prefix OR use prefixes in NSG instead of that tag.

We have a plan to introduce customer service tags aka IP groups, but this is still in design so no timelines to share yet.

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.