Site-to-site VPN architecture — hub-and-spoke, full-mesh and the topology that fits

A site-to-site VPN is the most common production VPN deployment. Two networks become one over an encrypted tunnel; the operators on each side reach resources on the other side as if the WAN were a private wire. The “two networks” part hides the design problem: with two sites the topology is obvious (point-to-point), but with three, four, or twenty sites the topology choice is one of the most consequential decisions in the network.

This lesson covers the canonical topologies — point-to-point, hub-and-spoke, full-mesh, partial-mesh — the addressing plan that supports each, the routing and operational trade-offs, and the OPNsense-specific configuration patterns.

The canonical topologies

Point-to-point. Two sites, one tunnel. The simplest topology. Common for a small office connecting to a headquarters, or a single cloud VPC peered with an on-premise network. The configuration is two peer entries, two AllowedIPs, two firewall rules.

Hub-and-spoke. A central site (the hub) connects to every other site (the spokes). The spokes do not connect directly to each other; spoke-to-spoke traffic goes through the hub. Common for retail branches connecting to headquarters, or for a primary data centre connecting to many small regional sites.

Full-mesh. Every site connects directly to every other site. With N sites, there are N(N-1)/2 tunnels. Common for a small number of high-value sites where any-to-any connectivity is required (e.g. three data centres, two production sites and a DR site).

Partial-mesh. A subset of full mesh. Some sites connect to each other directly (the high-traffic pairs); some go through a hub. Common when the full mesh would be too many tunnels but the operational requirement is more than hub-and-spoke.

Hub-and-spoke in production

Hub-and-spoke is the most common production pattern for multi-site deployments. The hub is a data centre firewall (or a pair in HA), with N-1 tunnels to N-1 spokes. Each spoke has a single tunnel to the hub.

The advantages:

• Linear scaling. Adding a spoke means adding one tunnel at the hub. The hub configuration grows linearly; full mesh grows quadratically.
• Centralised routing. The hub knows about all the spoke subnets. Spokes only need a default route to the hub.
• Centralised services. DNS, RADIUS, monitoring — all centralised at the hub. Spokes reach them through the tunnel.

The disadvantages:

• Hub is the bottleneck. Spoke-to-spoke traffic goes through the hub. With ten branches all streaming video to each other, the hub’s VPN bandwidth is the bottleneck.
• Hub is the single point of failure. If the hub tunnel drops, every spoke loses connectivity to every other spoke. HA at the hub (CARP) is required for production.
• Latency for spoke-to-spoke traffic. Spoke A -> Hub -> Spoke B has more latency than Spoke A -> Spoke B directly.

# Hub-and-spoke topology (5 sites).
# Hub: site H (headquarters).
# Spokes: site A, B, C, D (branches).

Site H: tunnels to A, B, C, D (4 tunnels).
Site A: tunnel to H (1 tunnel).
Site B: tunnel to H (1 tunnel).
Site C: tunnel to H (1 tunnel).
Site D: tunnel to H (1 tunnel).

# Spoke-to-spoke (A->B): A -> H -> B (two hops, both via VPN).

The WireGuard configuration at the hub has four peer entries, one per spoke. Each peer’s AllowedIPs is the spoke’s LAN subnet. The hub’s AllowedIPs for the spoke peer (the return direction) is the hub’s LAN subnet (plus the hub’s tunnel address).

Full-mesh in production

Full-mesh is the right choice for small numbers of high-value sites. Three data centres, two production sites and a DR site, four regional manufacturing plants — these are the cases where any-to-any connectivity is required and the number of sites is bounded.

The advantages:

• Lowest latency. Any-to-any traffic goes directly, no hub.
• No single point of failure. One site’s failure does not isolate any other site.
• Predictable performance. Each tunnel’s bandwidth is dedicated to that pair.

The disadvantages:

• Quadratic growth. Five sites is ten tunnels; ten sites is forty-five tunnels. The operational cost is real.
• Configuration management. Every tunnel must be configured on every site. With five sites, every site has four peer entries; with ten sites, every site has nine peer entries. A typo on one site affects only that pair, but a typo on the hub’s AllowedIPs in hub-and-spoke affects only that spoke.

# Full-mesh topology (4 sites).
# Every site connects to every other site.

Site A: tunnels to B, C, D (3 tunnels).
Site B: tunnels to A, C, D (3 tunnels).
Site C: tunnels to A, B, D (3 tunnels).
Site D: tunnels to A, B, C (3 tunnels).

# Total: 6 tunnels for 4 sites.

The WireGuard configuration at every site has N-1 peer entries. The AllowedIPs at every peer entry is the remote site’s LAN subnet. The discipline is consistency: every site has the same number of peer entries, every AllowedIPs is the right subnet, every endpoint is the right address.

Partial-mesh and tiered topologies

Partial-mesh is the production choice when the topology must reflect traffic patterns. A deployment with a few high-traffic pairs and many low-traffic peers uses partial-mesh:

• High-traffic pairs: direct tunnels (full-mesh among the high-traffic sites).
• Low-traffic peers: through a hub (hub-and-spoke for the rest).

A four-tier example: regional hubs in five regions, each hub connecting to a global hub. Regional hubs within a region have full-mesh; cross-region traffic goes through the global hub.

The advantage is that the topology matches the traffic pattern; the disadvantage is that the topology is bespoke and harder to reason about. The discipline is to document the topology — every tunnel, every allowed subnets, every reason for the topology choice — so the next operator can understand it.

Addressing for a multi-site VPN

The addressing plan is the foundation that everything else builds on. Three rules:

1. No overlap. Every site’s LAN subnet is unique across the entire VPN. A site with 10.0.0.0/24 and another with 10.0.0.0/24 cannot coexist on the same VPN — routing will fail.
2. Tunnel subnets are distinct from site subnets. The tunnel subnet (10.99.0.0/24 for example) is the WireGuard-level addressing. The site subnets (10.0.0.0/24, 10.1.0.0/24, etc.) are the LAN subnets behind each firewall. The two must not overlap.
3. Tunnel addresses are /32 per site. Each site’s WireGuard interface has one address (10.99.0.1/32, 10.99.0.2/32, etc.). The other addresses in the tunnel subnet are unused or reserved.

# Example addressing plan for a 5-site VPN.
# Tunnel subnet: 10.99.0.0/24 (WireGuard-level).
# Site subnets: each unique, no overlap.

Site   | Tunnel IP    | LAN subnet
-------|--------------|-------------
HQ     | 10.99.0.1/32 | 10.0.0.0/24
Branch | 10.99.0.2/32 | 10.1.0.0/24
Branch | 10.99.0.3/32 | 10.2.0.0/24
Branch | 10.99.0.4/32 | 10.3.0.0/24
Branch | 10.99.0.5/32 | 10.4.0.0/24

The discipline: write the addressing plan down before configuring the first tunnel. A spreadsheet with every site’s tunnel IP, LAN subnet, peer public key, and AllowedIPs is the difference between a VPN that deploys in an afternoon and one that takes a week of debugging.

Routing in site-to-site VPN

Two patterns for routing:

• Static routes. Each site has static routes for the other sites’ LAN subnets, pointing at the tunnel interface. Simple, predictable, and the right answer for hub-and-spoke with a small number of sites.
• Dynamic routing. A routing protocol (OSPF, BGP) runs over the tunnel interfaces. The sites learn each other’s routes dynamically. The right answer for full-mesh and partial-mesh with more than a handful of sites.

# Static route example for a hub-and-spoke deployment.
# Spoke A has a static route for site B's LAN subnet via the hub.

route add -net 10.2.0.0/24 10.99.0.1

The hub in hub-and-spoke typically uses static routes (the hub knows all the spoke subnets) or summarises them (the hub advertises 10.0.0.0/8 with each spoke contributing its own /16). The dynamic routing pattern is the multi-site fabric lesson.

Verification

After deploying the topology, verify:

1. From every site, traceroute to every other site’s LAN subnet — must traverse the VPN (or the hub, in hub-and-spoke).
2. From the hub, wg show — must show all the spoke peer entries with recent handshakes.
3. From every spoke, wg show — must show the hub peer entry with a recent handshake.
4. From any site, tcpdump -ni wg0 — must show the bidirectional flow when the test traffic runs.
5. From the corporate firewall’s monitoring, the tunnel state is “up” for every site — no stale “down” tunnels.

A topology that passes 1-2 but fails 3-5 has a hub-side configuration but spokes that are not properly connected. A topology that passes 3-4 but fails 1 has connected tunnels but no routing between sites.