Hub-and-spoke vs full mesh: which VPN topology fits your sites

Two branch offices talk to each other all day, and the tunnel between them detours through a datacenter in another region. Every request pays for that detour twice, and nobody notices until the file sync starts to feel wrong. That is where the topology question really begins: not with which diagram looks more resilient, but with which traffic pattern you are paying for. Both designs work, and they fail in different ways at different costs.

Count the peer relationships before anything else

With N sites, a full mesh needs N times N minus one, divided by two, tunnels; a hub needs N. At five sites that is ten against five, which still sounds manageable. At fifteen it is 105 against fifteen, and the difference is no longer arithmetic but staffing.

Each of those relationships carries state you have to own. In IPsec that means a security association, an identity, a key or certificate, dead-peer detection and at least one route per remote prefix. In WireGuard it means a public key and an AllowedIPs block per peer, which is cheaper per peer but comes with no discovery at all: a new site is a configuration change on every existing one either way.

Let the traffic mix decide, not the drawing

If branch traffic is mostly requests to a central ERP or file cluster, a hub is not a compromise, it is the correct shape: the traffic already wanted to go there, and one policy point is easier to audit than a mesh of pair-wise rules. A mesh earns its complexity when branches exchange data with each other — replication between two offices, voice between sites, a CAD share that a dozen engineers open all day.

The awkward cases sit in between, and they are the majority. Measure before you argue rather than guessing from an org chart.

Read the table as a tie-breaker, not a rule. Three of four rows pointing one way usually settles the design; a split means a hybrid, which is what most mature networks end up running anyway.

A hub has to be told to forward

Two working spoke-to-hub tunnels do not create spoke-to-spoke access. The hub needs IP forwarding enabled, a route to each spoke network, a firewall rule that permits the transit, and the return path worked out; each spoke needs a route for the other site's prefixes. On a Linux hub that is net.ipv4.ip_forward=1 plus a FORWARD chain that does not silently drop the pair, and on policy-based IPsec it is traffic selectors that list the remote spoke subnet on both ends. strongSwan's forwarding notes cover the kernel and firewall side when that is the layer you are missing. A cheap test is to send traffic from one spoke to a service on the other while watching the hub's counters; a rule that never increments means the order is wrong, not the route.

Central policy is also the useful part. Branches can be allowed to reach shared services without reaching each other, and that access matrix is worth writing down explicitly. Missing routes are a poor substitute for a rule someone can read.

Watch for the half-done version: spoke A routes to spoke B through the hub, the hub routes both ways, and the hub's firewall allows new connections from A but not from B. The first direction tests fine and the second hangs, which looks like a routing fault and is not.

Design the failure, then the normal path

A single hub is a shared dependency and a transit bottleneck, and redundancy is where hub designs usually go wrong. Two hubs mean every spoke holds two tunnels, and the return path has to agree with the outbound one; when it does not, a stateful firewall drops the replies and the symptom is a connection that opens and then dies. Larger deployments solve this with a routing protocol over the tunnels rather than static prefixes, which is more machinery but removes the guessing. Whatever you choose, write the return path next to the outbound one, because the return half is the one nobody tests.

A mesh spreads that risk: one site's link going down does not isolate the others. It also multiplies the places where path selection can surprise you, and application sessions still do not survive a path change without help.

Neither design keeps a TCP session alive across a failover by itself. If the application cannot reconnect, topology is not your problem.

Choose by change cost, then verify the routes

Start with the hub, because it is the cheaper thing to be wrong about, and add direct tunnels for the pairs whose traffic justifies them. That hybrid is not a failure to decide; it is the design most organizations converge on within a year. What matters is that each direct link has a stated reason and an owner.

Then verify the two drawings rather than one. For the normal path, traceroute from each site to each service prefix and confirm the hops match the diagram. For the failure path, shut one tunnel down and repeat it, because a route that only works while everything is up has not been designed, only configured.

Keep both drawings with the access matrix, and revisit them when a site is added; the cost you are managing is the cost of the next change, not the elegance of the current picture.