SmartAdvisorOnline

Checked for UK readers: 3 July 2026

Design routes, ownership and rollback before connecting sites

A site-to-site tunnel links networks rather than individual users. UK deployments should address overlapping subnets, route ownership, high availability, monitoring and supplier access before production traffic moves.

UK privacy and access context

AreaWhat to checkA good first step
Branch officeLAN subnets, internet breakout and failoverDocument routes and test failure behaviour
Cloud networkRoute tables, security groups and gatewaysKeep cloud controls independent of the tunnel
Data centreLegacy ranges and asymmetric routingValidate both directions and MTU
Supplier networkOwnership, limited services and contract endUse narrow routes and expiry
Dual ISP / resilienceFailover and tunnel re-establishmentTest planned and unplanned outages

Where to start

  1. Inventory both networks and data flows.
  2. Check for overlapping RFC1918 address ranges.
  3. Choose route ownership and encryption parameters.
  4. Build narrow firewall and security-group rules.
  5. Test MTU, DNS, failover and asymmetric routing.
  6. Document rollback, monitoring and supplier removal.

Common questions

What causes most site-to-site failures?

Overlapping subnets, asymmetric routes, mismatched proposals, MTU and firewall rules are common causes.

Should every branch route all internet traffic centrally?

Not automatically; security, performance, resilience and policy should determine breakout design.

How should supplier tunnels be controlled?

Use narrow destinations, named ownership, monitoring and a contractual expiry process.

Use these checks as a starting point and confirm the current provider terms. Follow UK law, contracts, account rules and organisational policy.

Hybrid cloud and branch office VPN topology dashboard
Updated: 20 June 2026 Focus: hybrid cloud + branch interconnect Data: topology + subnet logic By Denys Shchur

Site-to-site VPN for UK offices, cloud networks and suppliers

Architecture Blueprint 2026 A site-to-site VPN is a permanent encrypted tunnel between gateways, not individual users. The practical split is simple: hub-and-spoke for easier operations, mesh for latency-sensitive east-west traffic, and WireGuard-based site-to-site for leaner cloud routing where policy complexity makes classic IPsec painful. The modern rule is equally important: the tunnel is only the transport layer. Authorisation inside the network should be handled by Zero Trust / identity-based controls, not by the tunnel alone.
What matters most in practice If you are connecting offices, warehouses, and cloud environments, your biggest risks are usually topology mistakes, overlapping subnets, MTU/MSS fragmentation, and slow failover after a peer drop. This guide sits next to VPN for enterprise, VPN for remote access, VPN access control, and VPN security basics in a real 2026 rollout plan.
Disclosure: We may earn affiliate commissions if you buy via our links. This helps fund testing, updates, and tools. See Disclosure.
NordVPN - security stack Surfshark - team value Proton VPN - privacy focus

Most businesses no longer connect “office A to office B” in isolation. The real pattern is office + cloud + SaaS: a branch needs consistent access to a cloud VPC, internal services, and central identity systems. A serious site-to-site design now overlaps with how VPN works, VPN protocols comparison, and VPN speed testing - because architecture, routing, and throughput all matter at the same time.

Remote access vs site-to-site: planning differences

Remote access VPN vs site-to-site VPN (business view)
QuestionRemote Access VPNSite-to-Site VPN
Who connects?Individual devices and staffEntire networks via gateways
User actionOpen app, sign in, connectNo user action; routing happens at the edge
Best use caseTravellers, staff, contractorsBranches, warehouses, cloud VPCs, partner links
Ops burdenClient app and identity supportRouting, failover, MTU, tunnel monitoring
2026 pairingStrong MFA + endpoint securityZTNA + segmentation + observability
Practical guidance: most organisations need both. Use site-to-site for permanent network interconnect, then layer per-user access for employees through VPN for remote work or VPN for employees.

Topology Designer & Traffic Estimator

This is the “engineering desk” version: choose your scale, traffic shape, and redundancy level. The tool returns a topology direction, estimated overhead, and a deployment note you can actually hand to an admin.

🏢 Topology Designer & Traffic Estimator

Recommended topology
-
Est. overhead
-
Routing model
-
Hardware note
-
Deployment fitness score0%
HQ
Choose options → get design
Branch

Subnet Conflict Checker

One of the most boring mistakes is also one of the most expensive: both sites use the same private network. If Site A and Site B both live on 192.168.1.0/24, your shiny new tunnel will route like a liar. This utility catches the obvious collision before you waste hours in logs, then points you toward re-addressing or 1:1 NAT / access-control planning.

🧭 Subnet Conflict Checker

Enter two IPv4 CIDR ranges to check whether they overlap.

S2S protocols: IPsec vs WireGuard vs SD-WAN

Site-to-site protocols in 2026
FeatureIPsec (IKEv2)WireGuard (S2S)SD-WAN (Managed)
Setup complexityHigh (policy-heavy)Low (interface-based)Centralised controller
PerformanceHigh with hardware accelExtreme in lean deploymentsVariable by overlay and appliance
StabilityRock solid in legacy estatesGreat when routing is cleanBest for multi-link retail / branch fleets
2026 sweet spotBank-grade, compliance-heavy, established vendorsCloud-to-cloud and hybrid, low-latency opsMulti-branch retail with central orchestration

For a protocol-level refresher, compare types of VPN protocols, protocols comparison, and WireGuard vs NordLynx. Even though NordLynx is consumer-facing, the performance logic still helps explain why kernel-level tunnels can beat more complex stacks in cloud environments.

Hub-and-Spoke vs MeshHQ / HubBranch ABranch BCloud VPCBranch CHub-and-spoke keeps operations sane. Mesh reduces hop count but multiplies routing and failover complexity.
Diagram 1 - Use hub-and-spoke until your east-west traffic truly justifies mesh.
Dual-WAN Failover (why redundancy matters)HQ GatewayBranch GatewayPrimary tunnelBackup tunnel / ISP 2With DPD and sane timers, failover becomes operationally boring - which is exactly what you want.
Diagram 2 - Single tunnels look cheaper until the first ISP flap hits your ERP or VoIP.

Implementation and rollback checklist

Expert Deep-Dive: beyond the marketing

MTU/MSS clamping matters because S2S tunnels add overhead; if you ignore it, voice and SaaS sessions can feel randomly “slow” even when the tunnel is technically up. Dead Peer Detection is what keeps a peer drop from becoming a 20-minute outage. And once you cross into larger regional or hybrid layouts, BGP becomes the grown-up answer for route distribution - especially when you do not want to maintain endless static routes by hand.

That is also why site-to-site VPN work overlaps with VPN for small business, VPN for IT security, VPN for enterprise, and even VPN vs firewall. One secures transport, another enforces network boundaries, and a mature design needs both.

Diskless enterprise checklist: where teams still fail
RiskWhat it looks likeFix
Overlapping rangesTraffic disappears or routes the wrong wayRe-address or deploy 1:1 NAT before the cut-over
Weak failoverTunnel says “up” but apps hang after ISP flapDPD + clear failover timers + test scripts
Policy sprawlACLs become unreviewable across sitesCentralise naming, use summaries, document intent
No segmentationEvery site can talk to every appLayer ZTNA and access controls above the tunnel

Verdict

If you are building a 2026-ready network, the right question is not “Should we use a site-to-site VPN?” but what shape should the transport take. For a small footprint, a clean hub-and-spoke design is usually the best operational choice. For hybrid cloud and east-west traffic, WireGuard-based site-to-site can be faster and simpler. For sprawling branch fleets, SD-WAN may win once central orchestration outweighs DIY tunnel economics. Start with routing clarity, solve the subnet story, then add redundancy where downtime actually costs money.

Denys Shchur
Denys Shchur

Founder and editor of SmartAdvisorOnline. Denys focuses on practical VPN guidance, infrastructure privacy, diagnostic tooling, and business-network patterns that work outside lab slides.

LinkedIn · Contact
Disclosure & privacy: Some buttons are affiliate links. We may earn a commission at no extra cost to you. Analytics runs only after consent. See Disclosure and Privacy.
Last verified by SmartAdvisorOnline Lab:
✓ Leak Test (IP / DNS / IPv6 / WebRTC)
Verification date:

Related guides

  1. Start withCorporate VPN benefits and limits for UK organisations
  2. Then readVPN access control for UK organisations: MFA, roles and Zero Trust
  3. Related caseVPN vs firewall for UK homes and organisations

UK site-to-site checklist: resilience before clever routing

A site-to-site VPN should be boring in the best possible way. It needs predictable addressing, documented routes, monitored tunnels and a failover plan that the team has actually tested. UK offices often combine leased lines, business broadband, cloud networks and supplier access, so a clean diagram matters as much as the encryption setting. If nobody can explain which subnet is reachable from which site, troubleshooting becomes guesswork.

Before rollout, document tunnel ownership, pre-shared key or certificate handling, renewal dates, route tables, DNS forwarding and logging. Then test the uncomfortable cases: one ISP link drops, one firewall reboots, DNS fails, the cloud route changes, a supplier’s IP changes, or an office moves to a new circuit. A site-to-site VPN that only works on the happy path is not production-ready.

For smaller organisations, the biggest risk is overconnecting everything. Do not make every branch, supplier and cloud subnet mutually reachable just because the tunnel supports it. Segment by role, service and risk. The safest VPN design is the one that lets people reach exactly what they need and makes unexpected access visible in logs.