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.
Related reading(s)
- Solving Complex Network Issues: A Network Engineer's Journey
- Understanding the Difference Between VPN and VNet Peering in Azure
- Solving Complex Network Issues: Real-World Solutions That Work
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.
Top comments (0)