Hub-and-spoke Azure networking checklist (DNS, routing, NSGs, firewalls)

Hub-and-spoke networking in Azure is a popular design pattern that helps centralize shared services, security controls, and connectivity. However, if not implemented correctly, it can easily break under real traffic, DNS needs, and security requirements. This checklist focuses on four critical aspects of a hub-and-spoke design: DNS, routing, NSGs (Network Security Groups), and firewalls.

Topology and peering:

1. Clearly define the hub's responsibilities, such as hosting a central firewall, VPN/ExpressRoute gateway, DNS services, or shared services subnets.

2. Remember that VNet peering is not transitive; spokes need explicit routing and inspection design to communicate with each other.

3. When creating hub-to-spoke peering, verify that forwarded traffic is allowed if you plan to inspect traffic, and ensure remote gateways are used if the hub has a gateway. Pay attention to consistent naming/metadata across peerings.

DNS:

1. Choose a DNS model early on. Options include Azure-provided DNS only, custom DNS in the hub, Azure DNS Private Resolver, or hybrid DNS (on-prem + Azure integration).

2. Use private endpoints and private DNS zones for spokes if you plan to use private endpoints. Ensure zone links are properly set up to connect to the right VNets and enable resolution from on-prem if required.

3. Confirm that spokes can resolve DNS names to the hub's DNS resolver. Ensure that NGS/UDRs do not block the path and that forwarding rules exist for on-prem domains if required.

Routing:

1. Map the four main traffic types explicitly: Spokes to the Internet, Spokes to on-prem (VPN/ExpressRoute), Spokes to Spokes (East-West communication), and Spokes to the hub's shared services (DNS, jump hosts, tooling).

2. Decide between forced tunneling (all internet-bound traffic goes through the hub's security layer) or split tunneling (internet traffic exits directly from spokes, while private traffic goes through the hub). Forced tunneling provides stronger control but is more complex and costly, while split tunneling is simpler but may offer less centralized inspection.

3. Create UDRs for each spoke subnet. Ensure that default routes (0.0.0.0/0) are intentional, routes to on-prem prefixes are correct, and routes to hub shared services subnets are established. Also, ensure routes to other spokes are in place if you allow spoke-to-spoke communication.

4. Perform an asymmetric routing check. If traffic experiences asymmetric routing—going one way through a firewall/NVA and returning through a different path or bypassing inspection—it can cause issues with stateful devices and lead to timeouts.

Firewalls and NSGs:

1. When using a firewall/NVA, ensure that both the incoming and outgoing traffic flows are routed through it. If using split tunneling, return traffic may bypass the firewall, causing issues with stateful devices.

2. Validate routing rules and NSGs to ensure that they are consistent and do not inadvertently break the design. Avoid broad default routes that could cause hairpinning and break services that expect direct internet access (updates, SaaS endpoints, time sync, etc.).

By following this checklist, you can avoid common mistakes and create a robust hub-and-spoke networking design in Azure that effectively centralizes shared services, security controls, and connectivity.