Connecting sites is a topology decision before it's a VPN decision. Hub-and-spoke is simple and centralised; full mesh is fast but explodes with scale; SD-WAN buys you both at the cost of a subscription and a dependency. This is how to choose the WAN shape — then the tunnel tech follows.
Three shapes, three trade-offs. Hub-and-spoke routes every site through a central hub: trivial to add a branch, one place for policy and internet break-out, but branch-to-branch traffic hairpins and the hub is a bottleneck and a single point of failure. Full mesh gives every site a direct tunnel to every other: lowest latency, no hairpin, but N sites need N(N-1)/2 tunnels — it collapses under its own config past a handful of sites. SD-WAN is the modern answer: a controller brokers a dynamic mesh over any transport (fibre, LTE, Starlink), steers traffic per-application, and fails over sub-second — at the price of a licence, a vendor dependency, and a control plane you don't fully own.
The engineering trick is that DMVPN and WireGuard hub-and-spoke already give you "hub-and-spoke that builds direct spoke-to-spoke on demand" — most of SD-WAN's dynamic-mesh benefit without the subscription. So the real decision is often hub-spoke-with-dynamic-shortcuts vs commercial SD-WAN, not the textbook three. This post picks the shape; the tunnel builds are the VPN posts.
01
Every branch tunnels to the hub; the hub holds policy and often the internet break-out. Adding a site is one config. The costs are the hairpin and the hub as a chokepoint.
This is the right default for a classic HQ-and-branches business: a headquarters with real infrastructure, branches that mostly talk to HQ (files, apps, phones) rather than to each other. Centralising simplifies everything — one place to filter, log, and break out to the internet. The two costs: branch-to-branch traffic detours through the hub (fine if there's little of it), and the hub is a single point of failure (fix with a redundant hub / dual-hub design). When branches genuinely need fast direct paths, don't jump to full mesh — enable DMVPN Phase 3 shortcuts and keep the hub-and-spoke config.
02
Direct tunnels between every pair. Lowest latency and no hairpin — but the tunnel count and config burden grow quadratically. Reserve it for a few tightly-coupled sites.
Full mesh earns its place when you have a small number of sites that all talk to each other with latency-sensitive traffic — say three data centres, or a handful of production sites running real-time replication. Beyond ~5–6 sites the math turns hostile: adding one site means touching every existing router, and the tunnel/peering count becomes unmanageable and fragile. The honest modern position: pure static full mesh is rarely the right long-term answer — you want the effect of a mesh (direct paths) with the management of hub-and-spoke, which is exactly what dynamic-shortcut overlays and SD-WAN provide.
03
A controller and edge devices build tunnels automatically over every available link, steer traffic per-application, and fail over on loss/jitter — not just link-down. Powerful, and a dependency.
SD-WAN's genuine wins: it treats multiple cheap transports as one (fibre + LTE + Starlink), makes per-application decisions (VoIP on the low-latency link, backups on the cheap one — the policy-routing idea, automated and dynamic), and fails over on quality degradation, not just a dead link. The honest costs: it's a subscription, it introduces a controller dependency (often cloud-hosted — your WAN's brain lives at a vendor), and it's a black box compared to protocols you configure yourself. For a distributed retail/branch estate it's often worth it; for three sites, a dynamic-shortcut overlay you own outright usually is not.
Before buying SD-WAN, ask: which of its benefits do I actually need, and can I get them without the subscription? Multi-transport failover → IP SLA / recursive routing. Per-app steering → PBR / mangle marks. Dynamic direct paths → DMVPN / WireGuard overlay. Central management of many sites → the real SD-WAN value. If your win is "manage 40 branches from one dashboard with app-aware steering," SD-WAN earns its keep. If it's "fail over to LTE," you already own the tools.
04
| If… | Use |
|---|---|
| HQ + branches, mostly branch-to-HQ traffic | Hub-and-spoke |
| Above, but some heavy branch-to-branch | Hub-spoke + dynamic shortcuts (DMVPN P3 / WG) |
| A few sites, latency-critical any-to-any | Full mesh (small N only) |
| Many sites, multi-transport, app-aware, one pane | SD-WAN |
| "We need SD-WAN" but the goal is LTE failover | You already own the tools — skip it |
Takeaways
NOCTIS designs multi-site WANs across Crete — hub-and-spoke, dynamic-shortcut overlays, or an honest SD-WAN assessment — matched to how your sites actually talk, on transports including Starlink.
Book a Discovery Call →