Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.
I understand that you would like to know why Transitive Connectivity is not supported in Azure Vnet Peering.
Put simply, this is by design.
- This is how the product was developed and the recommendation was always to use a NVA in the Hub Vnet to route traffic across Spoke1 to Spoke2 .
- There might be a good number of reasons for the Product Team to do so, however, I don't think it will be shared to public.
One reason I can think of is that,
- Consider Multi Tenant VNet Peering.
- CustomerA - Hub
- CustomerB - Spoke1
- CustomerC - Spoke2
- And only A should be connected with both B and C
- And B and C should only be connected to A
- In this case, it's better to not have Transit connectivity by default
- This way, we can secure/prevent access between B and C
If you are looking for this functionality, then I suggest you use
- Azure Firewall as NVA
- Refer : Spokes communicating over a network appliance
- How to : https://techcommunity.microsoft.com/t5/fasttrack-for-azure/using-azure-firewall-as-a-network-virtual-appliance-nva/ba-p/1972934
- or Go for a vWAN : https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-global-transit-network-architecture#vnet-to-vnet-secured-transit-e
Kindly let us know if this helps or you need further assistance on this issue.
Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.