Securing Hub-and-Spoke Networks with Azure Firewall Manager and a Secured Virtual Hub

As Azure environments grow, networking and security quickly become harder to manage.

What often starts as a few virtual networks with basic security rules can turn into a complex setup with duplicated policies, inconsistent outbound access, and limited visibility over traffic between workloads.

This is where Azure Firewall Manager combined with a Secured Virtual Hub in Virtual WAN becomes a practical solution.

The main reason organisations adopt this design is to centralise security. Instead of every virtual network managing its own rules, traffic is routed through a single Azure Firewall that enforces policy consistently.

This makes outbound internet access easier to control, allows inspection of traffic between networks, and reduces the operational risk that comes with maintaining security rules in multiple places.

This approach is especially suitable for environments with multiple virtual networks that need consistent security controls.

It works well when teams want to separate networking from security responsibilities, or when an organisation is following an enterprise or landing-zone style design.

A common example is a platform hosting multiple application environments, such as production and non-production, where security policies must be applied uniformly without tightly coupling them to individual networks.

A secured virtual hub is part of Azure Virtual WAN. It acts as a central routing point that understands how to move traffic between connected networks.

When the hub is secured, Azure Firewall is deployed directly into it and integrated with the routing fabric. Virtual WAN handles connectivity and routing,

Azure Firewall inspects and enforces traffic rules, and Firewall Manager provides a central place to manage firewall policies. Each component has a clear responsibility, which helps keep the overall design simple and predictable.

Once deployed, all spoke virtual networks connect to the secured hub using Virtual WAN connections. Internet-bound traffic and traffic between networks is routed through Azure Firewall.

Firewall policies determine what traffic is allowed or blocked, while Virtual WAN ensures traffic actually passes through the firewall. No user-defined routes are required in the spoke networks, which significantly reduces configuration overhead.

In practice, deploying this solution follows a logical sequence. Virtual networks are created first, followed by a Virtual WAN and a secured virtual hub.

Azure Firewall is deployed into the hub, firewall policies are defined, and those policies are associated with the firewall. Finally, routing is explicitly enforced so that both internet and private traffic flow through the firewall.

This final routing step is critical, as firewall rules do not take effect until traffic is forced through the secured hub.

This design scales well because firewall policies are defined once and reused, routing is managed centrally, and changes can be made without touching every virtual network.

It aligns closely with Microsoft’s recommended patterns for larger Azure environments and reflects how enterprise platforms are typically built.

The entire solution can be deployed using Terraform, including the Virtual WAN, secured hub, Azure Firewall, firewall policies, and routing configuration.

One important detail is that DNAT rules in secured virtual hubs must reference the firewall’s public IP, which differs from traditional VNet-based Azure Firewall deployments and is a common source of confusion when first working with this architecture.

The full Terraform implementation for this lab is available here.