Site-to-Site VPN: How It Works and When to Use It

A site-to-site VPN connects two entire networks over an encrypted tunnel between their gateways, so every host on one side can reach hosts on the other without running any VPN software itself. It is how a branch office reaches headquarters, or how an on-premises network reaches a cloud environment, as though they were one private network.

It is the counterpart to remote access: instead of one tunnel per user device, a site-to-site VPN builds one persistent tunnel per network pair, and the gateways do all the work.

How a site-to-site VPN works

Each site has a VPN gateway — usually its firewall or router. The two gateways authenticate each other and establish an IPsec tunnel between them, typically always-on. When a host in Office A sends a packet to a subnet in Office B, its gateway recognises the destination, encrypts the packet with ESP, and sends it across the tunnel to Office B's gateway, which decrypts it and delivers it locally. The hosts never know a VPN was involved. The tunnel mechanics are the same IPsec described in IPsec VPN explained.

Because the tunnel is between networks, not devices, you scale it by adding sites and gateways, not by adding clients. That makes it efficient for connecting fixed locations and cloud VPCs.

Policy-based vs route-based

There are two ways to decide which traffic enters the tunnel. Policy-based VPNs match traffic against access lists — 'traffic from this subnet to that subnet uses the tunnel'. Route-based VPNs create a virtual tunnel interface (a VTI) and simply route traffic into it like any other interface, which lets you run dynamic routing protocols and makes complex or multi-tunnel topologies far cleaner.

Route-based is the more flexible modern default, especially where you want failover or many peers. Policy-based still appears on simpler or older devices and in some cloud configurations.

Site-to-site in the cloud

Cloud providers implement site-to-site VPNs as managed services. AWS Site-to-Site VPN connects a virtual private gateway or transit gateway to your on-premises device and provisions two tunnels for redundancy; Azure uses a VPN Gateway resource; Google Cloud offers Cloud VPN. All are IPsec under the hood, and all expect you to define your on-premises gateway and the routing between the environments.

These services are the common way to build hybrid networks today, and they are usually more robust than a hand-built tunnel because the provider manages availability on their side.

When to use it

Use a site-to-site VPN to link fixed locations — offices, data centres, cloud VPCs — that need continuous private connectivity. Use a remote-access VPN instead when you are connecting individual roaming users. For larger multi-site networks, weigh site-to-site against SD-WAN and cloud interconnects, which can offer better path control at higher cost.

The trade-off to remember: a site-to-site tunnel typically extends trust between whole networks, so a compromise on one side has a path to the other. Segment accordingly, and see the business VPN guide for how this sits beside the alternatives.

Redundancy and routing

A production site-to-site VPN should not rest on a single tunnel. The common pattern is redundant tunnels — two per connection is what AWS provisions by default — combined with dead peer detection so a gateway notices when the far end stops responding and fails over. Route-based VPNs make this far cleaner, because you can run a dynamic routing protocol such as BGP over the virtual tunnel interfaces and let routing withdraw a failed path automatically.

Match the routing to the topology. A single branch to one headquarters can live with static routes. A mesh of offices and multiple cloud regions benefits from dynamic routing, so paths reconverge without someone editing access lists at 2am. This is the main reason route-based VPNs have displaced policy-based ones in anything beyond the simplest deployments.

Site-to-site VPN vs SD-WAN

For a handful of sites, a plain site-to-site VPN over the internet is the simplest and cheapest option. As the number of branches grows, many organisations move to SD-WAN, which overlays multiple links (broadband, LTE, MPLS) with centralised policy and application-aware path selection — and which usually encrypts those overlay links with IPsec anyway. So SD-WAN is not the opposite of a VPN; it is a management and path-selection layer that typically uses VPN tunnels underneath.

The decision is about scale and control. Choose a straightforward site-to-site VPN when you have few sites and predictable connectivity; consider SD-WAN when you have many branches, multiple transport types per site, or a need for centralised, application-aware traffic steering that hand-managed tunnels cannot give you.

A note on segmentation

The most common design mistake with site-to-site VPNs is treating the tunnel as the security control and stopping there. A site-to-site tunnel joins networks, which means it also joins their risk: once Office A and Office B are bridged, a compromise at one site has a clear path to the other. Encryption protects the traffic in transit; it does nothing to limit what the far side can reach once decrypted.

So pair every site-to-site link with segmentation. Restrict the tunnel to the specific subnets and services that genuinely need to cross it, rather than routing entire flat networks into each other, and apply firewall policy at the tunnel's internal edge. This is the same least-privilege principle that underpins zero trust, applied to network-to-network connectivity — and it is what keeps one site's bad day from becoming everyone's.