Create 3 VNETS where all traffic is routed through one VNET (hub and spoke)

Question

I'm trying to figure out how to answer I question I recently had on an exam. The requirements are as follows:

1. You plan on creating 100 VMs across 3 virtual networks (vnetA, vnetB, and vnetC)
2. All traffic must be routed through vnetA
3. All virtual machines must be able to talk to each other via private IP
4. Solution must not require any virtual gateways
5. Solution must minimize the number of peerings.
6. Solution must not require any network virtual appliance (VM acting as router)

To me, this sounds like a hub and spoke topology where I perform the following steps.

1. Create vnet peering from vnetA to vnetB (allow forwarded traffic)
2. Create vnet peering from vnetB to vnetA
3. Create vnet peering from vnetA to vnetC (allow forwarded traffic)
4. Create vnet peering from vnetC to vnetA

Now I need the spoke to spoke connectivity (between vnetB and vnetC) but it has to pass through vnetA which is where I get confused. My first thought was to simply enable Allow gateway transit/Use remote gateways options between the two peerings above, but it doesn't allow that due to vnetA not having virtual network gateway (I even tried adding a GatewaySubnet to vnetA).

I can't seem to use a custom route table attached to the subnets of vnetB and vnetC to specify a next hop unless I use a virtual appliance which can't be used in this solution.

Anyone have any ideas on how they would approach this problem?

Answer 1

As far as I know, it's impossible to meet all the requirements 1-6. Since peering connections are non-transitive eventhough Transitive network flow between peered vnets is on MS roadmap from this feedback here, you have to create VNet peering between VNetB and VNetC. But this method will add the number of peerings and traffic Between VNetB to VNetC will not be routed via VNetA.

After having a quick test, select Allow forwarded traffic is not enough. This configuration option is necessary when configuring virtual networking appliances within your hub VNet so that transit traffic can route through the hub. More details here.

Allow forwarded traffic: Check this box to allow traffic forwarded by a network virtual appliance in a virtual network (that didn't originate from the virtual network) to flow to this virtual network through a peering. For example, consider three virtual networks named Spoke1, Spoke2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings don't exist between the spoke virtual networks. A network virtual appliance is deployed in the Hub virtual network, and user-defined routes are applied to each spoke virtual network that route traffic between the subnets through the network virtual appliance. If this checkbox is not checked for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub is not forwarding the traffic between the virtual networks. While enabling this capability allows the forwarded traffic through the peering, it does not create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about user-defined routes. You don't need to check this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.

To conclude, you have to create a VPN gateway for the hub-spoke network or use a virtual appliance as the hub and create UDR for the spoke network. Or simply create a peering between VNetB and VNetC.