Troubleshooting Lab: Create a secure hub by deploying Azure Firewall inside Virtual WAN hub
Diagnostic Scenarios
Scenario 1 — Root Cause
A network team deployed an Azure Firewall inside an Azure Virtual WAN hub in a secondary region. The hub was created successfully and the firewall appears as provisioned in the portal. However, traffic between two VNets connected to this hub is not being inspected by the firewall: packets reach their destination without any logs being generated in the Log Analytics workspace.
The environment has the following characteristics:
- Virtual WAN hub of Standard type
- Azure Firewall provisioned in the hub with Premium SKU
- Two VNets connected to the hub via Virtual Network Connections
- Log Analytics workspace configured with diagnostics enabled on the firewall
- Firewall Policy associated with the firewall with network rules allowing traffic between the VNets
- The administrator confirmed that the VNet routes appear in the hub's route table
The team also observed that the BGP configuration between the hub and a VPN gateway connected to the same hub was updated the previous week, but the gateway is in a different region.
What is the root cause of the problem?
A) The Premium SKU of the firewall is not compatible with Virtual WAN hub in secondary regions.
B) The Virtual Network Connections are connected to the hub, but the Routing Intent option was not enabled to redirect private traffic through the firewall.
C) The Log Analytics workspace is in a different region from the firewall, preventing log generation.
D) The BGP update on the VPN gateway corrupted the hub's route table, diverting traffic.
Scenario 2 — Diagnostic Sequence
An administrator reports that after enabling Routing Intent on an Azure Virtual WAN hub with Azure Firewall, Branch connections (ExpressRoute) to VNet stopped working. Traffic between VNets continues to operate normally.
The available investigation steps are:
- Verify if the Firewall Policy has network rules that allow traffic from the ExpressRoute circuit prefix to the VNet prefixes.
- Confirm that Routing Intent is configured to inspect private traffic and not just internet traffic.
- Check Azure Firewall logs in Log Analytics to identify if traffic is reaching the firewall and being denied.
- Confirm that the ExpressRoute circuit is in Connected state in the Azure portal.
- Verify if there are routes learned from ExpressRoute in the hub's effective route table.
What is the correct sequence of investigation?
A) 4 → 5 → 3 → 1 → 2
B) 2 → 4 → 5 → 3 → 1
C) 4 → 2 → 5 → 3 → 1
D) 5 → 4 → 3 → 2 → 1
Scenario 3 — Root Cause
An organization configured a secure hub in Azure Virtual WAN with Azure Firewall and enabled Routing Intent for internet traffic. The goal is for all outbound traffic from VNets to the internet to pass through the firewall before exiting.
After the configuration, administrators observe that virtual machines in a specific VNet still access the internet directly, without passing through the firewall. The firewall logs do not record any traffic originating from this VNet.
Environment details:
- Internet Routing Intent is enabled on the hub
- The VNet in question has a UDR (User-Defined Route) with route
0.0.0.0/0pointing to an NVA deployed within the VNet itself - The peering between the VNet and the hub is active and in Connected state
- There is a second VNet without UDR that works correctly through the firewall
- The hub is Standard type with Premium SKU firewall
- The problematic VNet's subscription belongs to a different management group from the other VNets
What is the root cause of the problem?
A) The Standard type hub does not propagate Routing Intent routes to VNets that belong to subscriptions in different management groups.
B) The UDR in the VNet with route 0.0.0.0/0 pointing to the local NVA takes precedence over routes propagated by the hub, diverting traffic before reaching the firewall.
C) The Premium SKU firewall requires additional Firewall Policy configuration to intercept traffic from VNets with active peering.
D) The peering between the VNet and the hub needs to be recreated after enabling Routing Intent for the new routes to be propagated.
Scenario 4 — Action Decision
The team identified that private traffic Routing Intent was enabled on the hub, but the Firewall Policy associated with the firewall does not contain any explicit network rules for traffic between VNets. As a result, all traffic between VNets is being blocked by the firewall, causing unavailability in critical production applications.
Context restrictions:
- The environment is in production and the maintenance window only occurs on Friday nights
- The security team needs to approve any new rule before it is applied
- There is a parent level Firewall Policy shared with other hubs, and the local policy inherits from it
- The team has permission to edit the local Firewall Policy, but not the parent policy
- It is Tuesday and the impact on applications has already lasted two hours
What is the correct action to take at this time?
A) Temporarily disable Routing Intent on the hub to restore connectivity while rules are prepared and approved.
B) Add a permissive network rule to the local Firewall Policy, without waiting for approval, to restore service immediately.
C) Create the necessary network rules in the local Firewall Policy, submit for security team approval under urgent regime and request authorization for application outside the maintenance window, given the production impact.
D) Edit the parent policy to add the network rule, since it is shared and the correction would affect all hubs consistently.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Azure Firewall provisioned in a Virtual WAN hub does not automatically inspect traffic just by being present. For traffic between VNets (private traffic) to be redirected through the firewall, Routing Intent needs to be explicitly enabled with the private traffic option activated. Without this, VNets communicate directly through the hub without passing through the firewall, which explains the absence of logs: traffic never reaches the firewall.
The central clue in the statement is that VNet routes appear in the hub's route table and the firewall is provisioned correctly. The problem is not connectivity or provisioning, but routing policy.
The information about the BGP update on the VPN gateway is irrelevant. It refers to a component in another region and a separate gateway, unrelated to the flow between the two VNets in question.
The most dangerous distractor is D, as it directs investigation toward BGP and the route table, which seem suspicious for having been modified recently. Acting based on this would lead to hours of investigation without finding the real cause.
Answer Key — Scenario 2
Answer: A
The correct sequence is 4 → 5 → 3 → 1 → 2.
Progressive reasoning requires first confirming if the ExpressRoute circuit is operational (step 4), because without physical connectivity all subsequent diagnosis is useless. Next, verifying if ExpressRoute routes are present in the hub table (step 5) validates if the control plane is working. With this confirmed, firewall logs (step 3) reveal if traffic reaches the firewall and what decision it makes. From the logs, it makes sense to check Firewall Policy rules (step 1). Only lastly is it worth confirming the Routing Intent configuration (step 2), since the statement already informs that it was enabled and traffic between VNets works, confirming that Routing Intent is active for private traffic.
The most common distractor is B, which starts with Routing Intent configuration. Although it seems logical to review what was changed, starting with the configuration layer without first validating the physical and routing layer is a methodological error that can lead to false conclusions.
Answer Key — Scenario 3
Answer: B
The UDR with route 0.0.0.0/0 configured directly in the VNet subnet has precedence over routes propagated by the hub of Virtual WAN. When Routing Intent is active, the hub announces 0.0.0.0/0 as next-hop pointing to the firewall. However, routes defined in UDR are more specific in Azure's routing decision plane and override routes learned via hub propagation. Traffic from the VNet exits through the local NVA without ever reaching the hub firewall.
The central clue is in the existence of the UDR and the contrast with the second VNet, which has no UDR and works correctly.
The information about the different management group is irrelevant. Routing Intent propagates routes based on the VNet connection to the hub, not on the subscription's management group hierarchy.
The most dangerous distractor is D, as it induces recreating the peering, a destructive and unnecessary action that would generate additional unavailability without solving the real problem.
Answer Key — Scenario 4
Answer: C
The context presents multiple simultaneous restrictions: production impact, need for security approval, maintenance window, and permission limitation on parent policy. The only action that respects all restrictions and acts with appropriate urgency is to create rules in the local policy, trigger urgent approval and request authorization to apply outside the regular window.
Distractor A seems reasonable because it would restore service quickly, but disabling Routing Intent in production without approval is a high-impact security architecture change, as risky or more than the original problem.
Distractor B ignores the security team's approval process, which may violate governance policies and create unassessed risk exposure.
Distractor D is unfeasible because the statement is clear: the team does not have permission to edit the parent policy.
Troubleshooting Tree: Azure Firewall in Azure Virtual WAN Hub
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
When facing a real problem, start with the root node that describes the observed symptom and answer each diagnostic question based on what you can verify directly in the portal, logs or via commands. Each branch leads to a concrete cause or a new more specific question. Follow the path until you find a red node with identified cause and apply the corresponding green action. If the action does not resolve, return to the last orange validation node and explore the alternative path.