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

Hub-and-spoke is one of the most common Azure networking patterns and one of the easiest to get “mostly right” while still shipping a design that breaks under real traffic, real DNS needs, and real security requirements.

This guide is a practical checklist you can use to validate (or design) a hub-and-spoke network in Azure, with the failure points called out explicitly: DNS, routing, NSGs, and firewalls.

If you’re building this pattern as part of a real Azure network engineering role, this is exactly the type of implementation detail covered in the AZ-700 (Azure Network Engineer) training.

What you’ll learn

The minimum components of a production hub-and-spoke design
A DNS checklist that prevents the “everything resolves except…” problem
Routing rules that avoid asymmetric routing and blackholes
NSG patterns that scale without becoming unreadable
Firewall placement decisions (and what breaks when you choose wrong)
A “common mistakes” section you can use as a pre-flight review

The baseline: what hub-and-spoke is trying to solve

Hub-and-spoke is not just “central VNet + peered VNets.” It’s a way to centralize:

shared services (DNS, identity services, jump hosts, tooling)
security controls (firewall, inspection, egress control)
connectivity (VPN/ExpressRoute, on-prem, partner networks)
governance boundaries (consistent routing and policy)

A good hub-and-spoke design makes it easy to answer:

How does traffic flow between spokes?
How does traffic reach on-prem?
How does internet egress happen?
Where does DNS resolution happen?
Where do we inspect traffic?

If you can’t answer those clearly, you don’t have a design, you have a diagram.

Checklist 1: Topology and peering (the “it works on paper” layer)

1) Define the hub’s responsibilities

Decide what the hub is for:

central firewall / inspection?
VPN/ExpressRoute gateway?
DNS services?
shared services subnet(s)?
both ingress and egress, or egress only?

Decision rule: if the hub does everything, it becomes a bottleneck. If it does nothing, it’s pointless.

2) VNet peering is not transitive (plan for it)

A classic early failure:

Spoke A is peered to Hub
Spoke B is peered to Hub
Team assumes Spoke A can talk to Spoke B “through the hub”

That’s not automatic. You need explicit routing and (often) inspection design.

3) Peering settings checklist

For each spoke↔hub peering, validate:

Allow forwarded traffic (if you’re doing NVA/firewall inspection)
Allow gateway transit / use remote gateways (if hub has the gateway)
Naming/metadata is consistent (you will have many peerings)

Common mistake: enabling gateway transit inconsistently → some spokes reach on-prem, others can’t.

Checklist 2: DNS (where hub-and-spoke breaks first)

DNS is the silent killer of “working” networks.

1) Decide your DNS model early

Pick one of these models intentionally:

Azure-provided DNS only (simple, limited)
Custom DNS in the hub (VM-based or managed)
Azure DNS Private Resolver (common modern approach)
Hybrid DNS (on-prem + Azure integration)

2) Private endpoints and private DNS zones

If you use private endpoints, you need a plan for:

private DNS zones creation and linking
zone links to the right VNets (hub and/or spokes)
resolution from on-prem (if required)

Common mistake: private endpoint works in one VNet but not another because zone links are incomplete.

3) Spoke-to-hub DNS resolution path

If spokes use hub DNS, confirm:

DHCP options (VNet DNS settings) point to the right resolver
Resolver is reachable (NSGs/UDRs don’t block it)
Forwarding rules exist for on-prem domains (if needed)

Common mistake: routing forces DNS queries through a firewall that blocks/doesn’t allow the resolver path → intermittent name resolution failures.

Checklist 3: Routing (UDRs) and traffic flow (where “mostly right” becomes broken)

Routing is where hub-and-spoke either becomes a clean, enforceable pattern—or a maze of exceptions.

1) Map the 4 traffic types explicitly

Before writing a single UDR, document how these flows should work:

Spoke → Internet (egress)
Spoke → On-prem (VPN/ER)
Spoke → Spoke (east-west)
Spoke → Hub shared services (DNS, jump hosts, tooling) If you don’t map these, you’ll end up “fixing” routing reactively.

2) Decide: forced tunneling or split tunneling?

Forced tunneling: all internet-bound traffic goes through hub security (firewall/NVA)
Split tunneling: internet traffic exits directly from spokes; only private traffic goes through hub

Decision rule: forced tunneling gives stronger control, but increases complexity and cost. Split tunneling is simpler, but you must accept less centralized inspection.

3) UDR checklist (per spoke subnet)

For each spoke subnet, confirm:
Default route (0.0.0.0/0) behavior is intentional (forced vs split)
Routes to on-prem prefixes are correct (and not overridden by a broad default)
Routes to hub shared services subnets exist (if needed)
Routes to other spokes exist (if you allow spoke-to-spoke)

Common mistake: a broad 0.0.0.0/0 route to firewall causes unexpected hairpinning and breaks services that expect direct internet access (updates, SaaS endpoints, time sync, etc.).

4) Asymmetric routing check (the #1 “it connects but breaks” problem)

Asymmetric routing happens when:

traffic goes one way through the firewall/NVA
return traffic goes a different way (or bypasses inspection)
stateful devices drop the return path

Checklist

If you’re using a firewall/NVA, ensure both directions of the flow traverse it (or neither does)
Validate return routes from hub and from on-prem back to spokes
Confirm SNAT behavior where required (especially for internet egress)

Common mistake: “Spoke can reach on-prem, but some apps time out” → return path is different.

5) Route propagation and gateway transit (hybrid connectivity)

If the hub has the VPN/ER gateway:
spokes must be configured to use remote gateways
hub must allow gateway transit
you must decide whether you rely on propagation or explicit UDRs

Common mistake: mixing propagation + UDRs without a clear rule → unpredictable routing during changes.

Checklist 4: NSGs (security that scales without becoming unreadable)

NSGs are where good intentions go to die if you don’t standardize.

1) Use a tiered NSG model

A scalable pattern:

Subnet-level NSG: broad rules for the workload tier (web/app/data/shared services)
NIC-level NSG (optional): only for special cases, not as a default

Common mistake: putting everything at NIC level → impossible to audit at scale.

2) Standardize on “allow lists” with explicit denies

In Azure, NSGs are stateful and default-deny inbound. That’s good—but you still need clarity.

Practical approach

Define inbound rules by source (hub, on-prem, specific spokes)
Define outbound rules intentionally for sensitive tiers (data subnets, management subnets)
Use service tags where appropriate (but don’t blindly allow “Internet”)

3) NSG checklist questions (per subnet)

What are the allowed inbound sources? (hub, on-prem, specific spokes)
What are the allowed inbound ports? (only what’s needed)
Are management ports restricted to jump hosts / management subnet?
Is outbound restricted for sensitive tiers?
Are you relying on “Any/Any” rules anywhere? (if yes, why?)

Common mistake: “temporary allow any-any” rules that never get removed.

4) Don’t confuse NSGs with firewalls

NSGs are not a full inspection device. They’re access control. If you need:

TLS inspection
URL filtering
centralized egress control
threat intel-based blocking …that’s firewall/NVA territory.

Checklist 5: Spoke-to-spoke: allow, deny, or inspect?

You need a policy decision:

Deny by default (simplest, strongest segmentation)
Allow directly(fast, but reduces central control)
Allow through hub inspection (best control, most complexity)

Decision rule: if you allow spoke-to-spoke, you must be able to explain why and how it’s controlled.

Common mistake: spoke-to-spoke becomes “accidentally allowed” via broad routes and permissive NSGs.

Checklist 6: Firewall / inspection (where you decide what you control)

If you’re serious about controlling egress, inspecting traffic, or enforcing segmentation, you need a clear firewall story.

1) Decide what the firewall is responsible for

Common responsibilities:

internet egress control (who can go out, to where)
east-west inspection (spoke-to-spoke)
hybrid traffic inspection (spoke-to-on-prem)
DNS proxying / DNS filtering (optional)

Common mistake: deploying a firewall but not forcing traffic through it consistently.

2) Placement patterns (pick one intentionally)

Pattern A: Centralized egress only (simpler)

Spokes send internet-bound traffic to hub firewall
Spoke-to-spoke may be denied or allowed separately
Good when you mainly want egress control

Pattern B: Full inspection hub (strong control, more complexity)

Spokes route internet + east-west + hybrid through hub firewall/NVA
Requires careful UDR design to avoid asymmetry
Good when segmentation and inspection are core requirements

Pattern C: Distributed inspection (advanced)

Some spokes have dedicated inspection devices
Used for high-isolation workloads
More operational overhead

3) Firewall checklist

Are UDRs forcing the intended traffic types through the firewall?
Are return routes symmetric?
Is SNAT configured appropriately for egress?
Do you have rule ownership and change control?
Are logs enabled and being reviewed?

Common mistakes(use this as a pre-flight review)

If you want a fast “are we about to regret this?” scan, check these:

DNS model undefined→ private endpoints break in random places
Private DNS zones not linked consistently →“works in hub, fails in spoke”
Assuming peering is transitive →spoke-to-spoke surprises
Forced tunneling without planning →SaaS endpoints/timeouts/update failures
Asymmetric routing → intermittent app failures and dropped sessions
Gateway transit inconsistent → some spokes reach on-prem, others can’t
NSGs inconsistent across subnets → impossible to audit, easy to bypass
Firewall deployed but not enforced → false sense of control
No logging baseline → you can’t prove what happened during incidents
No change discipline → “what changed?” becomes the main incident question

Next steps (if you’re implementing this for real)

Build and validate hub-and-spoke networking patterns (DNS, routing, security, connectivity) in AZ-700 (Azure Network Engineer).
If you’re operating the environment day-to-day (governance, monitoring, incident patterns), the AZ-104 Azure Administrator training path complements it perfectly.

FAQ (practical questions)

Do I always need a firewall for hub-and-spoke?
No, but you do need a clear decision about egress control and inspection. If you must control outbound destinations, inspect traffic, or enforce segmentation centrally, a firewall/NVA becomes hard to avoid.

What breaks first in hub-and-spoke designs?
DNS especially with private endpoints and hybrid name resolution. If DNS isn’t explicitly designed, you’ll get intermittent failures that look like “network flakiness.”

Should I allow spoke-to-spoke traffic?
Default answer: deny unless you have a clear business need. If you allow it, decide whether it’s direct or inspected, and enforce it consistently with routes and NSGs.

Is forced tunneling worth it?
It depends. Forced tunneling gives stronger centralized control but increases complexity and cost. If you choose it, plan for SaaS dependencies and ensure routing symmetry.

How do I keep NSGs from becoming unmanageable?
Standardize by tier (web/app/data/shared services), keep most rules at subnet level, and avoid NIC-level rules except for rare exceptions. Treat “temporary any-any” rules as incidents with expiry dates.

What’s the fastest way to validate an existing design?
Start with: DNS model + private DNS zone links, then routing (UDRs + symmetry), then NSG consistency, then firewall enforcement/logging. Those four areas reveal most production issues quickly.