Site-to-Site VPN Explained: Architecture and Use Cases

A company with a head office and two branches faces a simple problem. The accounting system sits in one building, the stock database in another, and the people who need both are in a third. Renting private lines between every site is expensive. Opening each system to the whole internet is unwise. A site-to-site VPN solves this by joining the networks over the public internet through an encrypted tunnel, so that all three buildings behave like parts of one private network.

This article explains the architecture in plain language: what the gateways do, how the tunnel and routes work, which layouts are common, how to plan addresses, what happens when a link fails, where the approach fits and where it does not. It is for owners, office managers and junior IT staff evaluating the idea. If you want a version aimed at joining a home network with another one, see the companion piece on a home site-to-site VPN. Here the focus is business and organisational use.

What a site-to-site VPN is, and what it is not

In a site-to-site design, each location has a gateway. The gateway is often the firewall or router that already connects the site to the internet. The two gateways agree on keys, build an encrypted tunnel, and carry traffic for whole networks through it. Computers, printers and servers at each site do not know a VPN exists. They send traffic to an address on the other side, and the gateway handles the rest.

That is the key difference from the kind of VPN most people know. A personal or remote access VPN runs software on one device and connects that device to a server. A site-to-site VPN runs on infrastructure and connects networks. Staff at the branch do not log in to a VPN, because their network is already inside it. The article on business versus personal VPNs sets the two kinds side by side.

What it is not:

• It is not a privacy tool for browsing. It does not hide your activity from your own company or your internet provider in the way a personal VPN is meant to.
• It is not a replacement for security inside each site. Anything that reaches one network from the other is trusted unless rules say otherwise.
• It is not automatically fast. The tunnel is limited by both sites' internet connections and by the gateways' ability to encrypt traffic.

How the tunnel is built

Most site-to-site VPNs use IPsec, a family of standards described in RFC 4301. The gateways first negotiate a secure relationship, then use it to protect the actual traffic. A standard method for the negotiation is IKEv2, described in RFC 7296. The article on IKEv2 and IPsec explains it in more everyday language.

In outline, the process runs in two stages.

1. Authentication and key agreement. Each gateway proves its identity to the other, using a pre-shared key or digital certificates, and they agree on keys for encryption. This stage is sometimes called the control tunnel.
2. Traffic protection. Using those keys, the gateways build child connections that carry the real data. Each connection is set up for particular pairs of networks.

Every so often the keys are replaced automatically, so that a captured key is useful for only a short time. Good practice is to use strong algorithms that meet current guidance, such as NIST's guide to IPsec VPNs, and to prefer certificates over a single shared password for larger deployments, because certificates can be revoked individually.

Two design styles appear in product manuals.

Style	How it decides what to protect	Best for	Watch out for
Policy-based	A list of rules that matches source and destination networks	Simple, two-site setups with fixed ranges	Rules multiply as networks are added, and mismatched rules on the two sides cause silent failures
Route-based	A virtual tunnel interface, and the routing table decides what uses it	Several sites, dynamic routing, failover	Needs routing knowledge, and wrong routes can send traffic the wrong way

Route-based designs are generally easier to grow, which is why they dominate once a business has more than two or three locations.

Layouts: point-to-point, hub-and-spoke and mesh

How you arrange the tunnels matters as much as how you build one.

• Point-to-point. Two sites, one tunnel. Simple and easy to troubleshoot. A good fit for a head office with one branch, or a company with a separate warehouse.
• Hub-and-spoke. One central site, the hub, with a tunnel to each branch, the spokes. Traffic from one branch to another travels through the hub. It keeps the number of tunnels low and gives one place to apply rules, but the hub becomes a single point of failure and a bottleneck.
• Full mesh. Every site has a tunnel to every other site. Branch-to-branch traffic goes direct and fast. The number of tunnels grows quickly: five sites need ten tunnels, ten sites need forty-five, so management becomes a burden unless the equipment automates it.
• Partial mesh. Hub-and-spoke for most traffic, with direct tunnels only between the sites that talk to each other a lot.
• Cloud-connected. One or more tunnels run from the office to a virtual network in a cloud provider, so that servers hosted there appear as part of the private network.

A useful rule is to start with the simplest layout that matches how people actually move data. If branches only talk to the head office, hub-and-spoke is plenty.

Plan your addresses before anything else

The most common reason a tunnel "comes up but nothing works" is an address problem. Each site needs its own private range, and ranges must not overlap. RFC 1918 defines the private ranges used inside most networks.

Consider an example. Two offices both use 192.168.1.0/24. A computer in office A tries to reach 192.168.1.20. Is that a printer in its own office or a server in office B? It cannot tell, so it assumes the local one and the tunnel is never used.

Practical planning rules:

1. Give every site a distinct range, such as 10.10.0.0/24 for the head office, 10.20.0.0/24 for the first branch and 10.30.0.0/24 for the second.
2. Leave room to grow. A small range that later runs out forces a painful renumbering.
3. Keep a simple table of ranges in the documentation, and update it when anything changes.
4. Avoid the ranges that home routers use by default, since staff may also use a remote access VPN from home and collide with them.
5. If overlap already exists, address translation at the gateways can map one site's range to a different one, but it adds complexity. Renumbering one site is usually the cleaner solution if you can afford it.

What happens when something fails

A tunnel that carries your accounting system is part of your critical infrastructure, so plan for its failure.

• Internet outage at one site. The tunnel drops. Staff at that site lose access to remote systems. A second internet connection, even a modest one, can restore it. Gateways that support two uplinks switch automatically.
• Gateway failure. A spare device or a pair of gateways in high-availability mode keeps the tunnel up.
• Dead peer detection. Gateways check that the other side is alive and rebuild the tunnel when it is not. Make sure this is turned on.
• Key or certificate expiry. A tunnel can stop at midnight simply because a certificate expired. Put expiry dates in the calendar.
• MTU problems. Encrypted packets are slightly larger. If they exceed what the path can carry, some traffic works and some mysteriously hangs. The article on VPN MTU issues describes the symptom, and RFC 1191 explains the path mechanism behind it.
• Monitoring. A simple check that pings a system across the tunnel every minute and alerts someone gives you early warning.

Typical use cases

Use case	What the tunnel does	Why a site-to-site VPN fits
Head office and branches	Lets branches reach shared files, accounting and phone systems	One central set of systems, no exposure to the internet
Warehouse or factory	Connects machines and stock systems to the main office	Devices that cannot run VPN software still get connected
Shops and point-of-sale	Links tills to a central database or payment gateway	Many identical small sites, predictable traffic
Cloud migration	Joins the office to a virtual network in a cloud service	Servers in the cloud look like a local network
Mergers and partners	Gives two organisations a narrow link to specific systems	Access can be limited to just the systems needed
Backup and replication	Moves data to a second site every night	Encrypted copy to a different location

For the partner case, narrow rules matter. A tunnel to another company should allow only the systems and ports needed, not whole networks.

Three scenarios

The clinic group. A medical practice has a main clinic and two satellite clinics. Patient records are on a server at the main site. Each satellite has a firewall that builds a tunnel to the main site in hub-and-spoke form. Staff at the satellites open the records system as if it were local. The gateways also limit which devices can reach the records server, so that a guest laptop in the waiting room cannot. When one satellite loses its fibre line, the firewall switches to a backup mobile data connection, and the tunnel returns within a minute.

The online retailer. A small retailer runs its storefront in the cloud but keeps its warehouse system in a back office. A tunnel from the office to the cloud network lets the storefront send orders to the warehouse system privately. The team plans address ranges carefully and finds that the cloud network's default range overlaps with their office. They choose a new range for the cloud network before anything is deployed, saving weeks of trouble later.

The workshop with a rented unit. A craftsman rents a second workshop across town. He needs the stock list and the shared printer at the original unit. A pair of small routers with a point-to-point tunnel does the job. Because the second site's internet provider uses shared addresses, one router cannot accept incoming connections, so the pair is configured so the second site always starts the tunnel. The article on VPN with CGNAT explains why that happens.

Mistakes to avoid

• Reusing the same private range at two sites.
• Using one weak shared password across all tunnels.
• Opening the tunnel to whole networks when only one or two systems are needed.
• Forgetting firewall rules inside the tunnel. A tunnel is trusted traffic unless you filter it.
• Skipping monitoring, so the first sign of a broken tunnel is a phone call from staff.
• Running old gateway firmware. Gateways face the internet and are a frequent target.
• Building a full mesh for six sites without a plan to manage the tunnels.
• Treating the tunnel as a substitute for per-user access control. A site-to-site VPN trusts the network, so consider adding stricter controls, a topic covered in zero trust versus VPN.

Summary

A site-to-site VPN joins whole networks through an encrypted tunnel built between gateways, usually with IPsec and IKEv2. Staff and devices do not run VPN software. Success depends on planning: distinct address ranges, a layout that matches real traffic, route-based design for growth, narrow rules, a second internet link for critical sites and monitoring that tells you when the tunnel is down. It protects the link between sites, not what happens inside each network, so keep the rest of your security in place.

If you also want a personal tool for your own devices when you travel, the pricing page shows simple prepaid options for individuals.