Question

Difficulty: HardConfigure Virtual Network Peering

An administrator deploys three virtual networks in the Azure environment:
* VNet-Hub (10.80.0.0/1610.80.0.0/16): Contains a subnet named GatewaySubnet (10.80.0.0/2410.80.0.0/24) with an active Virtual Network Gateway connected to an on-premises network (172.16.0.0/16172.16.0.0/16), and a subnet named Subnet-Hub (10.80.1.0/2410.80.1.0/24) with a virtual machine named VM-Hub.
* VNet-SpokeA (10.81.0.0/1610.81.0.0/16): Contains a subnet named Subnet-A (10.81.1.0/2410.81.1.0/24) with a virtual machine named VM-A.
* VNet-SpokeB (10.82.0.0/1610.82.0.0/16): Contains a subnet named Subnet-B (10.82.1.0/2410.82.1.0/24) with a virtual machine named VM-B.

The administrator configures virtual network peering between VNet-Hub and VNet-SpokeA, and between VNet-Hub and VNet-SpokeB with the following settings:
* For both peerings, Allow virtual network access is set to Enabled and Allow forwarded traffic is set to Enabled.
* On the peering connections from VNet-Hub to both spokes, Allow gateway transit is set to Enabled.
* On the peering connections from both spokes to VNet-Hub, Use remote gateways is set to Enabled.

No user-defined routes (UDRs) or network security groups (NSGs) are configured.

Which statement correctly describes the connectivity established by this configuration?

  1. A
    Neither VM-A nor VM-B can communicate with the on-premises network unless a User-Defined Route with a next hop type of Virtual Network Gateway is associated with Subnet-A and Subnet-B.
  2. B
    VM-A and VM-B can communicate with each other, and both can communicate with the on-premises network.
  3. VM-A and VM-B can both communicate with the on-premises network, but VM-A and VM-B cannot communicate with each other.Answer
  4. D
    VM-A and VM-B can communicate with each other, but neither can communicate with the on-premises network unless a User-Defined Route is created in GatewaySubnet.

Answer

VM-A and VM-B can both communicate with the on-premises network, but VM-A and VM-B cannot communicate with each other.
The correct answer is correct because virtual network peering is non-transitive. Even though both spoke virtual networks are peered with the hub virtual network and configured to use remote gateways, this configuration only permits spoke-to-hub and spoke-to-on-premises (via the VPN gateway) communication. It does not allow traffic from one spoke to traverse the hub to reach another spoke. To enable spoke-to-spoke communication, a network virtual appliance (NVA) or firewall must be deployed in the hub, or direct peering must be configured between the spokes.

Step-by-Step Solution

1
Analyze the gateway transit configuration.
Since 'Allow gateway transit' is enabled on the hub peering links and 'Use remote gateways' is enabled on the spoke peering links, both spoke networks (VNet-SpokeA and VNet-SpokeB) can utilize the VPN Gateway in VNet-Hub to reach the on-premises network.
This allows the spoke VNets to access the hybrid connectivity path established in the hub VNet.
2
Analyze the spoke-to-spoke connectivity.
Although both spokes are connected to the hub, virtual network peering is non-transitive. Traffic from VNet-SpokeA cannot transit VNet-Hub to reach VNet-SpokeB unless a network virtual appliance (NVA) or Azure Firewall is introduced with custom routing.
By default, Azure virtual network peering does not support transit routing between two peered networks via a third peered network.
3
Synthesize the overall connectivity status.
VM-A and VM-B can successfully communicate with the on-premises network, but they cannot communicate directly with each other.
Gateway transit allows spoke-to-on-premises traffic, but non-transitivity prevents spoke-to-spoke traffic.

Key Concept

Azure Virtual Network Peering is non-transitive, and gateway transit only allows spokes to reach the hub gateway and on-premises resources.
Rate this question