For most production deployments, choose route-based IPsec with IKEv2 and certificate authentication as your baseline. Small networks with a handful of sites can run full mesh; medium networks scale better on a hub-and-spoke or transit hub; large or cloud-heavy estates need a virtual WAN or concentrator model with active-active gateways for throughput and resilience. Treat the VPN itself as encrypted transport only. Access decisions belong to a Zero Trust policy engine, not the tunnel.
TL;DR:
- Small networks under ten sites may benefit from full mesh topology with automated configuration, while larger deployments should consider hub-and-spoke or virtual WANs for scalability.
- Route-based IPsec combined with BGP is recommended for managing complex multi-site VPNs, with careful planning of addressing, NAT, and MTU to prevent silent failures.
- Always standardize on IKEv2 with certificate authentication and strong cryptography, and incorporate regular failover testing to ensure high availability and resilience.
- Active-active gateways paired with diverse transport paths improve throughput and uptime, but operational testing is crucial to verify real-world performance.
- Treat the VPN as encrypted transport only; access control must be managed through a Zero Trust policy engine to maintain security and prevent trust from being solely based on tunnel presence.
Table of Contents
- Which multi-site VPN topology fits your network?
- How should routing and addressing be planned for multi-site VPNs?
- What cryptography and authentication should multi-site VPNs use?
- How do you build high availability into a multi-site VPN?
- How do you connect multi-site VPNs into cloud environments?
- How does VPN design fit with Zero Trust security?
- Deployment checklist for a multi-site VPN cutover
- What does 35 years of Cisco deployments teach about multi-site VPN design?
- What actually determines whether a multi-site VPN design survives contact with reality
- How Re-solution supports multi-site VPN design and rollout
- Standards and guidance worth reading directly
- Sources
- FAQ
Which multi-site VPN topology fits your network?
Topology choice is the first decision in any multi-site VPN design, and it determines almost everything downstream: configuration overhead, failure domains, and how painful it is to add site number twenty.
Hub-and-spoke centralises control at one or more hub sites, with every spoke building a single tunnel back to the hub rather than to every other site. It is simple to manage and easy to audit, but the hub becomes both the traffic chokepoint and the single point of risk, so hub bandwidth needs sizing for peak aggregate spoke demand, not average.
Full mesh connects every site directly to every other site. It suits smaller deployments, perhaps under ten to fifteen sites, where east-west traffic between locations is heavy and a hub hop would add unacceptable latency. Beyond that, the number of tunnels grows fast enough that manual configuration becomes unworkable without automation.
Transit hub, concentrator, or virtual WAN designs sit between the two: a managed transit layer handles many-to-many routing so spokes only configure one connection each, while the transit layer resolves the rest.
- Under 10 sites with heavy inter-site traffic: consider full mesh with template-driven configuration.
- 10 to 50 sites, moderate east-west traffic: hub-and-spoke or a single transit hub.
- 50+ sites or heavy cloud egress: virtual WAN or concentrator services built for scale.
How should routing and addressing be planned for multi-site VPNs?
Route-based IPsec is generally preferred over policy-based IPsec for multi-site designs because the routing table, not a static policy match, decides which traffic goes into which tunnel. That distinction matters once you have more than a couple of sites: policy-based tunnels require a matching security association for every subnet pair, which multiplies configuration effort as the mesh grows, whereas route-based tunnels let dynamic routing protocols do that work automatically.
BGP over IPsec is the standard way to achieve this at scale. It exchanges prefixes automatically as sites join or change, supports path preference across diverse transport links, and lets you tag routes with BGP communities to apply consistent policy across the network rather than per-tunnel exceptions.
Follow this sequence when planning addressing:
- Audit existing subnets across all sites and eliminate overlap before any tunnel goes live.
- Summarise routes wherever site subnets allow it, to keep BGP tables and route filters manageable.
- Plan NAT rules explicitly for any legacy site that cannot be re-addressed before cutover.
- Calculate MTU after accounting for IPsec encapsulation overhead, typically 50 to 60 bytes depending on mode and cipher.
- Validate path MTU end to end rather than assuming the default 1500 bytes will survive the tunnel.
Pro Tip: Fragmentation issues rarely show up in initial testing because small packets succeed fine. Push a large file transfer or a video call across every tunnel before go-live. That is where silent MTU black holes reveal themselves.
What cryptography and authentication should multi-site VPNs use?
IKEv1 is now historic. RFC 9395 confirms it should be retired in favour of IKEv2, which supports the modern AEAD cipher suites that IKEv1 cannot negotiate cleanly. Every new multi-site design should standardise on IKEv2 as the baseline protocol.
On cipher selection, RFC 8247’s IKEv2 algorithm guidance recommends AES-GCM or ChaCha20-Poly1305 as AEAD suites, paired with conservative Diffie-Hellman group selection rather than the smallest group that still works. Choosing a stronger DH group protects against long-term key capture risk, though it does add CPU load on the gateway, so factor that into hardware sizing rather than discovering it under peak load.
- Use certificate-based authentication with a properly managed PKI lifecycle wherever the gateway estate supports it.
- Reserve pre-shared keys for cases where certificates genuinely cannot be deployed, and enforce high entropy if you do.
- Rotate keys on a defined schedule rather than leaving them static for the tunnel’s lifetime.
- Store private keys in hardware-backed modules (TPM or HSM) rather than on gateway file systems.
- Monitor authentication logs for credential reuse or unexpected certificate requests.
The NCSC’s device security guidance reinforces the same pattern: IPsec, certificate authentication, and disciplined PKI operation rather than shared secrets left unchanged for years.
How do you build high availability into a multi-site VPN?
Active-active gateway configurations give you two active tunnels to the same device pair rather than one active and one passive, which raises both throughput and availability in a single move. Microsoft’s active-active gateway guidance frames this as the standard pattern for sites where a single tunnel cannot meet either bandwidth or uptime requirements, and its VPN Gateway design documentation notes that aggregate throughput improves because traffic can use both gateway instances simultaneously rather than one sitting idle as backup.
Pairing active-active gateways with transport diversity, such as two different carrier circuits, lets BGP path preference handle failover automatically rather than relying on a manual cutover.
- Run scheduled failover tests, not just annual disaster recovery exercises.
- Separate the management plane from data traffic, ideally onto its own VLAN or private management network.
- Patch gateway firmware on a defined cycle rather than reactively.
- Alert on tunnel health, traffic asymmetry between paths, and route flaps, all of which usually precede a full outage.
Pro Tip: A tunnel that shows “up” in monitoring can still be silently dropping half its packets. Alert on throughput deviation and packet loss, not just tunnel state.
How do you connect multi-site VPNs into cloud environments?
Managed virtual WAN and VPN concentrator services centralise site onboarding so each new location configures one connection to the hub rather than negotiating direct peering with every cloud region it needs. AWS’s Site-to-Site VPN Concentrator model and equivalent Azure hub-spoke and Virtual WAN architectures both trade some routing control for significant reductions in per-site configuration work, which matters after you are onboarding sites monthly rather than annually.
Where a private circuit such as ExpressRoute or Direct Connect is available, prefer it for primary traffic and keep IPsec as an automated failover path rather than the primary connection.
- Automate site onboarding through infrastructure-as-code rather than manual gateway builds.
- Define routing policy for cloud egress before onboarding the first spoke, not after the tenth.
- Watch for hairpinning, where traffic between two spokes routes through the hub even when a direct path would be shorter.
- Model egress cost against a centralised hub design before committing, since traffic concentration changes the cost profile.
How does VPN design fit with Zero Trust security?
A VPN tunnel should be treated as encrypted transport, nothing more. The access decision, whether a device or user can reach a specific resource, belongs to a policy engine, not to whether a packet arrived through the tunnel. NCSC’s ZTNA guidance makes this distinction explicit: tunnelling all traffic is often unnecessary and can hurt usability without improving security, because trusting an IP range once it is inside the tunnel is precisely the anti-pattern Zero Trust replaces.
- Enforce access with a Zero Trust policy engine rather than broad network reachability after connection.
- Apply segmentation and least privilege inside the tunnel, not just at its edge.
- Weigh split tunnelling against full-device VPN per NCSC’s risk guidance rather than defaulting to one for every user group.
- Log tunnel activity for lateral movement patterns, not just connection success or failure.
Deployment checklist for a multi-site VPN cutover
- Sign off addressing plans, route summaries, MTU calculations, PKI structure, and failover SLAs before any configuration begins.
- Build IKEv2 profiles, cipher lists, and certificate provisioning, then configure BGP neighbours and route filters.
- Test tunnel bring-up, throughput, and failover under load, including security scans and clear rollback criteria.
- Set monitoring baselines, tune alert thresholds, update runbooks, and schedule recurring failover drills.
Pro Tip: Define your rollback criteria in writing before cutover night, not during it. A tired engineer at 2am should never be deciding what counts as a failed test.
What does 35 years of Cisco deployments teach about multi-site VPN design?
A company with extensive Cisco partnership experience has spent over 35 years running audits, managed services, and NaaS engagements across education, manufacturing, and logistics sites. Two patterns recur: sites addressed without a plan cause overlap headaches years later, and networks with tested failover recover in minutes rather than hours. A network audit or proof-of-concept via NaaS catches both before they become incidents.
What actually determines whether a multi-site VPN design survives contact with reality
The industry’s obsession with topology diagrams misses the point. Most multi-site VPN failures I’ve seen in audit findings and case studies were not caused by choosing hub-and-spoke over full mesh. They were caused by nobody testing failover until the day it mattered, by MTU assumptions nobody validated, and by PKI left to expire quietly.
Conventional guidance treats crypto and topology as the hard part and operations as an afterthought. That is backwards. IKEv2, AES-GCM, and route-based IPsec are now well-understood defaults; getting them wrong is rare. Getting the operational discipline wrong, unscheduled failover tests, undocumented management access, unmonitored route flaps, is where multi-site networks actually break.
If you take one thing from this article, prioritise resilience testing over adding more tunnels. A second encrypted link that has never failed over under real conditions is not redundancy. It is an assumption waiting to be proven wrong. Design the topology carefully, then spend proportionally more effort validating that it behaves the way the diagram promised.
— Jacob
How Re-solution supports multi-site VPN design and rollout
Re-solution is the practical route to a multi-site VPN design that holds up under real load, not just in the diagram. As a Cisco partner with over 35 years of infrastructure experience, Re-solution moves engagements through a clear path: an audit to assess current topology and risk, a design phase mapping your scale to the right architecture, a pilot to prove failover and throughput, then either handover or an ongoing managed rollout.
For organisations that would rather not carry the operational overhead of managing gateways, certificate lifecycles, and failover testing in-house, Network as a Service puts that operational discipline on Re-solution’s side of the contract. If you want an outside view on your existing tunnels and routing before committing to a redesign, start with a network audit, or explore the full range of professional services and get in touch to scope your next multi-site project.
Standards and guidance worth reading directly
The recommendations here draw on primary standards rather than vendor marketing. RFC 9395 confirms IKEv1’s historic status, while RFC 8247 covers IKEv2 algorithm and Diffie-Hellman group guidance in full. The NCSC’s VPN device security guidance and Microsoft’s Azure VPN Gateway design documentation are worth reading in full before finalising any production design.
Sources
- RFC 9395
- Device security guidance: virtual private networks – NCSC
- About active-active gateways – Microsoft Learn
FAQ
Should I use IKEv2 or IKEv1 for a new VPN deployment?
Use IKEv2 for every new deployment. RFC 9395 confirms IKEv1 is now historic and cannot support the modern AEAD cipher suites that IKEv2 negotiates natively.
What is the benefit of active-active VPN gateways?
Active-active gateways run two tunnels to the same device pair simultaneously rather than keeping one idle as backup, which raises both throughput and availability. Microsoft’s active-active gateway guidance recommends this pattern wherever a single tunnel cannot meet bandwidth or uptime targets.
Should I use certificates or pre-shared keys for authentication?
Certificate-based authentication with a managed PKI lifecycle is the stronger choice for multi-site VPNs, as recommended in NCSC’s device security guidance. Reserve pre-shared keys for cases where certificate deployment genuinely is not feasible, and enforce high entropy if you must use them.
When should I use split tunnelling instead of full-device VPN?
Split tunnelling reduces load on the central hub and improves user experience but weakens visibility into that traffic, so the choice depends on the site’s risk profile. NCSC’s guidance suggests evaluating this per use case rather than defaulting to either option across the whole estate.
How does a VPN relate to Zero Trust network access?
A VPN should function purely as an encrypted transport layer, while a policy engine handles the actual access decision for each user or device. This is the core principle behind Zero Trust network access, and it avoids the common mistake of trusting anything simply because it arrived through the tunnel.
Recommended
- SD-WAN failover design: a playbook for network architects
- Best Practices for Network Design Explained
- Network architecture basics: a guide for IT professionals
- Cisco Meraki Multi-Site Deployment
