VPN gateway inter-vnet routing with default site

Question

VPN gateway inter-vnet routing with default site

Geoff Lee 20

I've recently come to understand the following:

If:

A VPN gateway is configured in a hub vnet and
Spoke vnets are peered with the hub and configured to use gateway transit to access the S2S VPN connection through this gateway and
Forced tunnelling is enabled with the Default Site setting to route all 0.0.0.0/0 traffic through the gateway

Then:

The default behaviour of the gateway is to route traffic between the spoke VNets. ie if spoke A knows nothing about spoke B, then traffic from spoke A addressed to spoke B will be sent to the 0.0.0.0/0 route and the gateway will pass it between the VNets. I don't think this is made very clear in the documentation and isn't the behaviour I want.

Having discovered this behaviour, I had assumed that the default NSG would at least block this traffic, but as best I can tell, this inter-spoke traffic is also allowed by the 'Vnet' service tag in the default NSG, meaning that when Default Site is enabled, any spoke Vnets that have gateway transit over the hub are effectively transitively peered together.

I have two questions:

Is my understanding correct? My testing bears it out but I'm quite possibly missing something
Is there a recommended way to stop this behaviour? Other than putting a UDR on every spoke subnet to explicitly blackhole traffic for other spoke VNets?

Rohith Vinnakota 3,925 Reputation points Microsoft External Staff

2025-04-09T22:44:28.4033333+00:00

Hi @Geoff Lee,

Is my understanding correct? My testing bears it out but I'm quite possibly missing something

Yes, your understanding is correct. The two spoke VNets will communicate with each other. If you want to block this traffic, you can use the UDR (custom route table) and the NSG.

Is there a recommended way to stop this behaviour? Other than putting a UDR on every spoke subnet to explicitly blackhole traffic for other spoke VNets?

You can use the NSG instead of the UDR.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
chrischin 915 Reputation points Microsoft Employee

2025-04-10T01:28:00.4966667+00:00

Hi Geoff,

Normally you would have an Azure Firewall sitting in the Hub alongside the VPN Gateway where the AzFirewall controls and filters traffic between spokes and to/from the VPN Gateway while the VPN Gateway is there to connect you to an external network (S2S). Whether or not the VPN Gateway will accept your traffic depends on how you have configured it (what routes are advertised). If you post your configuration, I can explain the expected behavior. The configuration of your resources (VNet peerings (propagation), route tables, existence of a VPN Gateway) adds entries to the effective routes of interfaces on your network - the most specific route wins. NSGs are typically not the first choice to enforce routing behavior.

Accepted answer

0 additional answers

Your answer

Rohith Vinnakota 3,925 Reputation points Microsoft External Staff

2025-04-09T22:44:28.4033333+00:00

Hi @Geoff Lee,

Is my understanding correct? My testing bears it out but I'm quite possibly missing something

Yes, your understanding is correct. The two spoke VNets will communicate with each other. If you want to block this traffic, you can use the UDR (custom route table) and the NSG.

Is there a recommended way to stop this behaviour? Other than putting a UDR on every spoke subnet to explicitly blackhole traffic for other spoke VNets?

You can use the NSG instead of the UDR.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
chrischin 915 Reputation points Microsoft Employee

2025-04-10T01:28:00.4966667+00:00

Hi Geoff,

Normally you would have an Azure Firewall sitting in the Hub alongside the VPN Gateway where the AzFirewall controls and filters traffic between spokes and to/from the VPN Gateway while the VPN Gateway is there to connect you to an external network (S2S). Whether or not the VPN Gateway will accept your traffic depends on how you have configured it (what routes are advertised). If you post your configuration, I can explain the expected behavior. The configuration of your resources (VNet peerings (propagation), route tables, existence of a VPN Gateway) adds entries to the effective routes of interfaces on your network - the most specific route wins. NSGs are typically not the first choice to enforce routing behavior.

Answer 1

Rohith Vinnakota 3,925 Microsoft External Staff

Hi @Geoff Lee,

I tested your scenario. As you mentioned, I was able to communicate between two spoke VNets even though they are not peered with each other. This two vnets are peered with the hub vnet only.

This my Topology

User's image

I deployed two VMs in the two spoke VNets. See this screenshot; they are communicating with each other.
User's image

User's image

See this traffic is going like this:
spoke01vnet----->VPN Gateway------>spoke02vnet
User's image

User's image

I configured the NGS rule to block this communication.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Geoff Lee 20 Reputation points

2025-04-10T12:46:46.2633333+00:00

Thanks for the confirmation - we are in the process of deploying a firewall which will control all of the inter-spoke traffic, but I feel that this behaviour, which is potentially very significant, could be more clearly called out. In neither of the below documents is it made clear that a side-effect of enabling gateway transit and forced tunnelling is that all of your spoke vnets will be effectively transitively peered.

https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

https://learn.microsoft.com/en-us/azure/vpn-gateway/site-to-site-tunneling

Appreciate you taking the time to answer me - thanks.
Rohith Vinnakota 3,925 Reputation points Microsoft External Staff

2025-04-10T13:01:41.5033333+00:00

Hello Geoff Lee,
Thanks for sharing your feedback. The firewall is a great option to manage traffic.

Please do not forget to "Accept the answer” and “Yes” wherever the information provided helps you, this can be beneficial to other community members.

Share via

VPN gateway inter-vnet routing with default site

0 additional answers

Your answer