Network Setup

The following architecture diagram shows an azure virtual Wan deployed in a single azure region with all the three hybrid connections. The setup tries to implement an isolation between the azure virtual networks using custom route tables. For more information on the scenario specification, refer to The implementation of this specific scenario is available in my GitHub repo at

Architecture Diagram

Application of this Network Setup

The key highlight of this setup is that the custom route tables provide the necessary isolation between the azure virtual networks. This could be a very common requirement in an enterprise setup where the virtual networks owned and managed by different business units do not need to connected. They however would need a connection to the on-premise sites, one or all. I would not go in detail of how this is achieved as the documentation has plenty of information. In short, the vnets (vnet pairs in this example) are associated to a custom route table (HUB_RT_VNET) and the components that propagate to this route table are the members of this group (VNET1 & VNET2) and all the hybrid connections. The vnets in a different group (VNET3 &VNET4) do not propagate to this route table. As a result, vnets in one group do not have routes to reach the ones in a different group

Problem Statement (Minor Issue)

The minor issue that I noticed during the implementation of the above shown network setup is that routes to the vnets in the second group (VNET3 with CIDR of and VNET4 with a CIDR of get added to the HUB_RT_VNET route table.

The same behavior is not seen the other way round. The routes of group-1 do not get added to the HUB_RT_VNET2 route table. Also, as the routes get added to the route table, the same would be added to the effective routes that any VM NIC in the group-1 virtual networks can learn.

I reached out to the Azure Networking support team to get more insights on this behavior even though a ping command between VMs in the 2 different groups would fail. I was told that this is a minor issue in the virtual wan and would be fixed in a future release as this is definitely not a show-stopper.

The root cause of the issue seems to be the fact that the URI of HUB_RT_VNET2 contains the URI of HUB_RT_VNET. The check now seems to be happening based on the fully qualified route table URI in the format “Subscriptions/{SubscriptionId}/ResourceGroups/{ResourceGroupName}/Providers/Microsoft.Network/virtualHubs/routeTables/{Route_Table_Name}” where in the URI of HUB_RT_VNET becomes a substring of the URI of HUB_RT_VNET2. The hub has to check the spokes or the virtual networks that are associated to the RT HUB_RT_VNET2 so that all the routes propagated to this table can be advertised to the them. HUB_RT_VNET URI happens to be a substring of HUB_RT_VNET2 URI. So the routes that were propagated to the HUB_RT_VNET2 route table is also advertised to the HUB_RT_VNET RT.


The suggested workaround is to use mutually exclusive URIs for the Custom RT names. That should help us achieve vnet isolation.


The effective routes list in the HUB_RT_VNET seems to the only minor issue. As stated earlier, despite the additional routes learnt, the VMs in the group-1 Vnets cannot reach the machines in Group-2