This guide shows a practical Azure hub-and-spoke network pattern focused on perimeter security using Azure Firewall in the hub to control traffic between two spoke VNets. Bastion and VPN Gateway configuration are intentionally out of scope — this lesson concentrates on routing, firewall rules, and verifying connectivity.
- Centralized traffic inspection and filtering with Azure Firewall.
- Secure management access via Azure Bastion (no public RDP/SSH ports required).
- Encrypted site-to-site connections via a VPN gateway.
- Centralized logging and telemetry through Azure Monitor.
- Create and attach a route table for Spoke B so that non-internal traffic is routed to the hub firewall.
- Associate the route table with the spoke subnet.
- Add Azure Firewall network rules to allow specific spoke-to-spoke communication.
- Verify connectivity and HTTP/HTTPS behavior based on the firewall rules.
- In the Azure portal, create a route table in the Spoke resource group and name it
SpokeBRT(Spoke B Route Table). - Add these two routes to
SpokeBRT:
| Route name | Destination CIDR | Next hop type | Next hop address / notes |
|---|---|---|---|
| internal | 192.168.2.0/24 | Virtual network | Keeps local subnet traffic local |
| everything-else | 0.0.0.0/0 | Virtual appliance | 192.168.0.4 (Azure Firewall IP in hub) |
- Before associating the route table, VMs in Spoke B may still be reachable via their public IPs. Confirm connectivity (for example via SSH) from your workstation.
- In the route table pane, associate
SpokeBRTwith the Spoke B VNet’sdefaultsubnet. Once associated, the 0.0.0.0/0 route will force non-local traffic to the hub firewall (192.168.0.4), which changes the effective path for outbound traffic and may interrupt direct public-IP access.
- Open the Azure Firewall policy (or firewall instance) and add a Network rule collection (e.g., “spoke comms”). Within the collection create allow rules for the precise source/destination IPs or CIDRs you want to permit.
| Rule name | Priority | Action | Source | Destination | Destination port | Protocols |
|---|---|---|---|---|---|---|
| A1-to-B1 | 300 | Allow | 192.168.1.4 (Spoke A VM1) | 192.168.2.4 (Spoke B VM1) | Any | Any |
| A2-to-B2 | 301 | Allow | 192.168.1.5 (Spoke A VM2) | 192.168.2.5 (Spoke B VM2) | Any | Any |
- Use CIDR prefixes to allow entire subnets (e.g.,
192.168.1.0/24and192.168.2.0/24) if you prefer broader rules. - Priority and collection evaluation order matter: Firewall checks rule collections by priority and stops when it finds a match. If no rule matches, the default action is Deny.
- From Spoke A VM1 (192.168.1.4) to Spoke B VM1 (192.168.2.4) — allowed by the rule:
- From Spoke A VM1 to Spoke B VM2 (192.168.2.5) — blocked because no rule permits it:
- From Spoke B VM1, outbound HTTP/HTTPS (curl) is denied unless the firewall has an Application rule allowing the requested FQDNs:
- To enable web access, add an Application rule to the firewall policy permitting specific FQDNs or FQDN tags for the subnet (e.g., allow
www.google.comfor192.168.2.0/24). After applying the rule, HTTP/HTTPS requests to allowed domains will succeed:
- Route tables (UDRs) are used to force traffic toward the hub firewall using the Virtual Appliance next hop. You can also direct specific ranges to a Virtual Network Gateway to route traffic to on-premises (e.g., using an on-prem CIDR like
10.0.0.0/8with next hop Virtual Network Gateway). - Azure Firewall is stateful: permitting A → B allows return traffic B → A automatically; you do not need separate reverse rules.
- Firewall rule collections and priorities determine which rules apply. Design rule sets to minimize overly permissive entries.
- For secure management, use Azure Bastion to RDP/SSH from the portal without exposing VM management ports.
- Forced tunneling routes internet-bound traffic to on-premises NVAs or other inspection points if required by your security architecture.
- Use Azure Monitor and diagnostic settings on Firewall and VNets for centralized telemetry and alerting.
Firewall rules are stateful: if a network rule allows A → B, return traffic from B → A is allowed automatically — you do not need a separate reverse rule.