A client has an existing Azure Virtual Network (VNet) named 'VNetHub' (10.1.0.0/16) in the 'West US' region, which contains an Azure Firewall. They are deploying a new VNet named 'VNetSpoke' (10.2.0.0/16) in the same region. All traffic originating from 'VNetSpoke' destined for the internet or other VNets must pass through the Azure Firewall in 'VNetHub'. Which two Azure networking configurations are required to achieve this?
- AAzure Virtual WAN connecting 'VNetHub' and 'VNetSpoke', and a UDR on 'VNetSpoke' pointing to the Firewall.
- BVNet peering between 'VNetHub' and 'VNetSpoke', and a User Defined Route (UDR) on 'VNetSpoke' pointing to the Firewall.
- CVPN Gateway connection between 'VNetHub' and 'VNetSpoke', and an NSG on 'VNetSpoke' pointing to the Firewall.
- DVNet peering between 'VNetHub' and 'VNetSpoke', and an NSG on 'VNetSpoke' pointing to the Firewall.
Show answer & explanationAnswer & explanation
Correct answer: B. VNet peering between 'VNetHub' and 'VNetSpoke', and a User Defined Route (UDR) on 'VNetSpoke' pointing to the Firewall.
To enable traffic between VNets in the same region, VNet peering is the most efficient solution. To force traffic from 'VNetSpoke' through the Azure Firewall in 'VNetHub' for internet/other VNet access, a User Defined Route (UDR) is required on 'VNetSpoke' that directs 0.0.0.0/0 traffic to the Azure Firewall's private IP as the next hop. Additionally, 'Allow remote gateways' must be enabled on the 'VNetHub' side of the peering and 'Use remote gateways' on the 'VNetSpoke' side for traffic to traverse the firewall in the hub VNet.
Why the other options are wrong
- A. Azure Virtual WAN is a broader solution for large-scale global networks. While it can achieve this, VNet peering with UDRs is the more direct and appropriate solution for connecting two VNets in the same region for this specific requirement. Additionally, a UDR is still needed to point traffic to the firewall if Virtual WAN routing doesn't implicitly handle it for arbitrary traffic types.
- C. VPN Gateway is less efficient for VNet-to-VNet communication within Azure than VNet peering, and NSGs cannot force routes.
- D. While VNet peering is correct, NSGs filter traffic but cannot force routes. UDRs are needed for forced tunneling.
Hub-Spoke with Forced Tunneling
A network topology where a central 'hub' VNet (containing shared services like a firewall) connects to multiple 'spoke' VNets, and all traffic from spokes is forced through the hub's firewall.
- VNet peering connects hub and spoke VNets.
- UDRs on spoke subnets direct 0.0.0.0/0 traffic to the hub firewall's private IP.
- Requires 'Allow forwarded traffic' and 'Use remote gateways' on peering links.
Memory trick: Hub-Spoke: All roads lead to the firewall.