An administrator is configuring a hub-and-spoke network topology in Microsoft Azure. The h… — Microsoft Azure Administrator (AZ-104)

An administrator is configuring a hub-and-spoke network topology in Microsoft Azure. The hub virtual network (VNet-Hub) contains an Azure Firewall deployed with the private IP address $10.0.1.4$ . Two spoke virtual networks, VNet-Spoke1 (containing Subnet-App with address space $10.1.1.0/24$ ) and VNet-Spoke2 (containing Subnet-DB with address space $10.2.1.0/24$ ), are peered with VNet-Hub.

The administrator associates a route table with Subnet-App containing a route for destination $10.2.1.0/24$ with a next hop type of Virtual appliance and a next hop address of $10.0.1.4$ . In the Azure Firewall, a Network Rule is configured to allow TCP traffic on port $1433$ from $10.1.1.0/24$ to $10.2.1.0/24$ .

A virtual machine in Subnet-App ( $10.1.1.4$ ) attempts to establish a SQL database connection to a database server in Subnet-DB ( $10.2.1.4$ ). The connection fails, even though no Network Security Groups (NSGs) are blocking the traffic and the database server is configured to accept connections.

Which of the following is the most likely cause of this connection failure?

The route table associated with Subnet-DB does not contain a user-defined route for $10.1.1.0/24$ with the next hop pointing to the Azure Firewall, resulting in asymmetric routing where the firewall drops the stateful TCP connection.Answer
B
Virtual network peering between VNet-Spoke1 and VNet-Spoke2 must be established directly, as transit routing through a hub virtual network is not supported for peered networks without configuring Virtual Network Gateways and Gateway Transit.
C
The route table associated with Subnet-App has an incorrect next hop type of Virtual network gateway instead of Virtual appliance for the destination $10.2.1.0/24$ .
D
The default outbound security rule in the Network Security Group (NSG) associated with Subnet-App has a higher priority than the route table rules, preventing traffic from reaching the firewall.

Answer

The connection failure occurs because the route table on the database subnet (Subnet-DB) is missing a route back to the application subnet (Subnet-App) via the Azure Firewall's private IP, leading to asymmetric routing where the firewall drops the connection due to state mismatch.

For stateful firewalls like Azure Firewall to work correctly, routing must be symmetric. When the source VM sends traffic, it is routed to the firewall due to the UDR on Subnet-App. However, when the database server responds, the lack of a corresponding UDR on Subnet-DB causes the return traffic to bypass the firewall and go directly to Subnet-App. The firewall drops the connection because it cannot complete the stateful TCP handshake tracking.

Step-by-Step Solution

Trace the outbound traffic path from the source VM (

10.1.1.4

) in Subnet-App to the destination database server (

10.2.1.4

) in Subnet-DB.

Traffic destined for

10.2.1.0/24

matches the User-Defined Route (UDR) on Subnet-App and is successfully forwarded to the Azure Firewall (

10.0.1.4

) as its next hop.

To ensure traffic is inspected by the firewall, a UDR must intercept the default system route and redirect it to the firewall's private IP.

Evaluate the firewall rule matching for the outbound connection.

The outbound TCP port

1433

traffic from

10.1.1.0/24

10.2.1.0/24

matches the configured Network Rule and is permitted to pass through the firewall to the destination.

Azure Firewall rules are evaluated in order; matching an allow network rule permits the traffic to continue to its destination.

Trace the return path of the response traffic from the database server (

10.2.1.4

) back to the source VM (

10.1.1.4

Since there is no UDR configured on Subnet-DB directing

10.1.1.0/24

traffic back to the firewall, the response traffic follows the default system route (VNet Peering) directly to Subnet-App, bypassing the hub firewall.

Azure system routes automatically route peered virtual networks directly unless overridden by a custom route table.

Determine the state tracking outcome at the Azure Firewall.

The firewall receives the initial SYN packet and subsequent ACK packet from the source VM, but never sees the intermediate SYN-ACK packet from the database server. Because Azure Firewall is stateful, it detects this asymmetric routing and drops the connection.

Stateful firewalls require symmetric routing (both request and response paths flowing through the firewall) to maintain TCP state tables and validate connection integrity.

Key Concept

Stateful packet inspection and routing symmetry in Azure Firewall

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic