Place NAT Gateway behind Azure Firewall without bypassing spoke inspection

Source facts

Microsoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.

This placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. Microsoft Learn.

Applicability

Confirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.

DSE recommendation

DSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.

Verification

From a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.

Official references

Microsoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network. Source retrieved September 9, 2026.