Home / Azure

AzureHow-toIntermediate

Azure hub-and-spoke network foundation with Azure Firewall and private DNS

Build the hub VNet, peered spokes, forced routing through Azure Firewall and central private DNS zones so private endpoints and on-premises connectivity work from day one.

Deepak Bhardwaj2 min read

Applies toAzure Virtual Network, Azure Firewall, VPN/ExpressRoute gateways, Azure Private DNS

Target layout

On-premises ── VPN/ExpressRoute ──┐
                                  ▼
                        hub-vnet 10.0.0.0/22
                        ├── GatewaySubnet
                        ├── AzureFirewallSubnet
                        ├── AzureBastionSubnet
                        └── dns-resolver-inbound / outbound
              peering ▲            ▲ peering
       spoke-app1 10.1.0.0/22   spoke-app2 10.2.0.0/22

1. IP plan first

  • Non-overlapping ranges with on-premises and with the DR region (for example 10.0.0.0/16 in Central India, 10.100.0.0/16 in South India).
  • Leave room: a /22 per spoke is a sensible start; AKS with Azure CNI needs more.

2. Hub and peering

az network vnet peering create -g rg-hub -n hub-to-app1 --vnet-name hub-vnet \
  --remote-vnet /subscriptions/<sub>/resourceGroups/rg-app1/providers/Microsoft.Network/virtualNetworks/spoke-app1 \
  --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit

az network vnet peering create -g rg-app1 -n app1-to-hub --vnet-name spoke-app1 \
  --remote-vnet /subscriptions/<sub>/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworks/hub-vnet \
  --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways

3. Force traffic through the firewall

Route table on every spoke subnet:

az network route-table route create -g rg-app1 --route-table-name rt-spoke-app1 \
  -n default-to-fw --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

Set "Propagate gateway routes" = No on spoke route tables, so on-premises routes learned by the gateway don't bypass the firewall. On the GatewaySubnet, add routes for spoke prefixes pointing to the firewall if you inspect on-premises traffic.

4. Central private DNS

  • Create privatelink.* zones (blob, database, vault…) once in the connectivity subscription and link them to the hub VNet.
  • Use Azure DNS Private Resolver in the hub; point on-premises conditional forwarders at its inbound endpoint.
  • Use the Azure Policy initiative that creates DNS records for new private endpoints automatically in the central zones.

Warning

A second copy of privatelink.blob.core.windows.net linked to a spoke causes the most common "private endpoint resolves to a public IP / wrong IP" ticket. One zone per name, centrally.

5. Firewall policy baseline

  • Network rules: spoke ↔ spoke only where needed, DNS to the resolver.
  • Application rules: FQDN tags for Windows Update, AzureKubernetesService, and the specific SaaS endpoints apps need.
  • Diagnostic logs to Log Analytics (structured logs) for troubleshooting denies.

HA and DR notes

  • Deploy Azure Firewall across availability zones (zones 1, 2, 3) in the hub.
  • Use zone-redundant gateway SKUs (VpnGw2AZ, ErGw2AZ).
  • Build an identical hub in the DR region, peer the hubs (global peering), and keep the DR firewall policy as a child of the same parent policy.

Validate

az network watcher test-ip-flow ...           # NSG allow/deny for a VM
az network nic show-effective-route-table -g rg-app1 -n vm1-nic -o table

Related fixes