Your company has an Azure environment containing three virtual networks: - `VNet-Hub` (172… — Microsoft Azure Administrator (AZ-104)

Your company has an Azure environment containing three virtual networks:
- `VNet-Hub` ( $172.30.0.0/16$ ): Contains an Azure Firewall with a private IP address of $172.30.0.4$ in a subnet named `AzureFirewallSubnet`.
- `VNet-Prod` ( $10.100.0.0/16$ ): Contains `VM-Prod` deployed in `ProdSubnet` ( $10.100.1.0/24$ ).
- `VNet-Dev` ( $10.200.0.0/16$ ): Contains `VM-Dev` deployed in `DevSubnet` ( $10.200.1.0/24$ ).

Bidirectional peering connections are established between `VNet-Hub` and `VNet-Prod`, and between `VNet-Hub` and `VNet-Dev`.

To comply with security policies, all traffic between `VNet-Prod` and `VNet-Dev` must transit through the Azure Firewall in `VNet-Hub`.

You associate a route table with `ProdSubnet` that contains a route for address prefix $10.200.0.0/16$ with a next hop of $172.30.0.4$ (Virtual appliance).
You associate a route table with `DevSubnet` that contains a route for address prefix $10.100.0.0/16$ with a next hop of $172.30.0.4$ (Virtual appliance).

Azure Firewall rules are configured to permit all traffic between the two spoke networks.
However, `VM-Prod` and `VM-Dev` are unable to communicate.

Which peering configuration must you enable on the virtual network peering connections to allow communication between the virtual networks?

Enable 'Allow forwarded traffic' on the virtual network peering connections.Answer
B
Enable 'Use remote gateways' on the peering connections in the spoke virtual networks.
C
Enable 'Allow gateway transit' on the peering connections in the hub virtual network.
D
Configure a User-Defined Route in the hub virtual network pointing to the spoke virtual networks using a next hop type of Virtual Network Gateway.

Answer

Enable 'Allow forwarded traffic' on the virtual network peering connections.

The correct option is enabling 'Allow forwarded traffic' on the peering connections. When traffic is routed between spoke virtual networks through a central hub containing a network virtual appliance (NVA) or Azure Firewall, the packets carry source and destination IP addresses that do not belong to the hub virtual network. For the hub to accept and forward this traffic, and for the spokes to accept it from the hub, the 'Allow forwarded traffic' setting (or 'Traffic forwarded from remote virtual network') must be enabled on the peering connections.

Step-by-Step Solution

Analyze the traffic path from VM-Prod to VM-Dev.

Traffic destined for

10.200.0.0/16

is sent to the Azure Firewall (

172.30.0.4

) in VNet-Hub via the User-Defined Route on ProdSubnet.

This identifies the entry point into the hub virtual network.

Analyze how the packet is processed by the hub and forwarded to the destination.

The Azure Firewall forwards the packet to VM-Dev (

10.200.1.4

) in VNet-Dev via the peering link.

The packet now carries a source IP of VM-Prod (

10.100.1.4

) which is outside the address space of VNet-Hub.

Determine why the traffic is dropped at the peering boundary.

Because the source IP is from VNet-Prod and not VNet-Hub, the traffic is classified as forwarded traffic. If 'Allow forwarded traffic' is not enabled on the peering connections, Azure drops this traffic.

Enabling 'Allow forwarded traffic' allows virtual networks to receive and forward transit traffic that did not originate within their own address spaces.

Key Concept

Virtual Network Peering Transit and Forwarded Traffic

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic