Site to site VPNs connect two or more separate networks, such as a headquarters and a branch office, so that computers on each side can reach each other as if they shared one local network. A virtual private network, or VPN, creates an encrypted tunnel across the public internet to carry that traffic safely.
Unlike remote access VPNs, which link one person’s laptop to a company network, this approach joins entire locations. Once it is running, staff rarely need to think about it. This article explains how the setup works, which design choices matter, and what to verify before relying on one.
Why Organizations Connect Entire Locations Instead of Individual Laptops
Imagine a small accounting firm with an office in Chicago and a second office in Denver. Staff in Denver need to open the file server in Chicago, and the Chicago office needs access to a printer and an accounting database in Denver.
Sending these files over the open internet without protection would expose client data to anyone able to observe the traffic.
A site to site VPN solves this by building a permanent encrypted tunnel between the two office routers, sometimes called gateways. Every device behind each router can then communicate with devices behind the other router without installing any software on individual computers.
This model suits organizations with fixed locations that exchange data continuously. It removes the need for each employee to log in before accessing shared resources, which reduces friction for daily work.
The tradeoff is that the tunnel protects traffic between the two sites, not every activity a person performs online. Staff still need normal safeguards for web browsing and email.
How a Site to Site Tunnel Is Built and Maintained
A tunnel begins with a handshake between the two gateways. The devices agree on how to authenticate each other, usually with pre-shared keys or digital certificates, and then negotiate the encryption methods they will use. A common standard for this negotiation is IKE, the Internet Key Exchange protocol, which is part of the IPsec suite.
Once the handshake succeeds, the gateways wrap outgoing packets from the local network inside encrypted packets addressed to the remote gateway. The receiving gateway unwraps them and delivers the original data to the correct device. This wrapping process is called encapsulation.
The keys used for encryption are refreshed on a schedule, a process called rekeying, so that a long-running tunnel does not rely on one set of keys forever. Lifetimes and algorithms are configurable, and the specific defaults vary by device vendor.
Maintenance matters as much as setup. Administrators should record the tunnel’s endpoints, the subnets it serves, and the people responsible for changes, so that the link can be diagnosed quickly when it stops working.
Choosing Between Policy Based and Route Based Designs
Two common approaches determine which traffic enters the tunnel. Each one fits different network layouts, and the right choice depends on the equipment, the number of subnets, and how often the network changes. Teams should compare the options before buying hardware.
- Policy based tunnels match traffic by source and destination subnet pairs and encrypt only the traffic that fits a defined rule.
- Route based tunnels create a virtual interface, so ordinary routing tables decide what enters the tunnel, which simplifies adding new subnets.
- Policy based designs can become hard to manage as subnets multiply, because every new network pair may need a new rule on both sides.
- Route based designs generally scale better and integrate with dynamic routing protocols, though support depends on the gateway model.
- Both approaches can be secure when configured correctly, so the choice should rest on manageability rather than a belief that one is inherently stronger.
Before finalizing a design, write down every subnet that must communicate across the link and confirm that the gateway supports the chosen method. Ask the vendor for documentation on the exact features included in your model. Testing a small pilot before migrating production traffic reduces surprises and gives staff time to learn the new arrangement.
Addressing, Routing and Security Considerations
Good addressing and sound security settings prevent the most common problems with site to site links. Planning these details before deployment saves time later and avoids conflicts that can be hard to trace once the tunnel is live.
Avoiding Overlapping Address Ranges
Both sites must use private address ranges that do not overlap. If the headquarters and the branch both use the same subnet, such as a common home router default, the gateways cannot tell which device is which, and traffic will fail or go to the wrong place.
A practical habit is to assign each location a distinct block at the start, such as separate ranges for each office and any cloud networks. Documenting these assignments in a shared inventory prevents future conflicts when a new site is added.
When an overlap already exists, the usual remedies are renumbering one side or using translation rules at the gateway. Both carry risk, so they should be tested in a maintenance window with a rollback plan ready.
Authentication and Encryption Settings
The strength of a tunnel depends on its authentication and encryption choices. Pre-shared keys are simple to set up but must be long, random, and kept secret, because anyone holding the key can attempt to join the tunnel. Certificate-based authentication is more manageable at scale because it avoids sharing one secret across many devices.
Administrators should select current, widely reviewed algorithms and disable older options that the gateway supports for compatibility. Vendor guidance and the organization’s own security policy should define which algorithms are acceptable, and that list should be reviewed periodically.
Access to the gateway’s management interface should itself be protected with strong, unique credentials and multi-factor authentication where available, since a compromised gateway exposes every network behind it.
Firewall Rules and Least Privilege
Establishing a tunnel does not mean every device on one site should reach every device on the other. Firewall rules on each side should allow only the specific services that business processes require, such as file sharing from one subnet to a single server.
This principle of least privilege limits damage if one site’s network is compromised, because an attacker cannot freely roam into the other location. Rules should be written in plain language first, then translated into configuration, so reviewers can check the intent.
Logging permitted and denied traffic at the gateway provides evidence for troubleshooting and for security reviews, and logs should be retained according to the organization’s policy.
Common Problems and How to Diagnose Them
Most site to site failures fall into a few patterns. The tunnel never comes up, the tunnel comes up but a particular subnet cannot be reached, or the link works but is slow or drops intermittently. Recognizing which pattern applies narrows the search considerably.
When the tunnel fails to establish, check that both gateways agree on the algorithms, keys, and peer addresses, and that no firewall between the gateways blocks the protocol ports the VPN uses. A mismatch in one small setting is the most frequent cause.
When the tunnel is up but traffic does not flow, verify that the routes on each side point to the tunnel and that the firewall rules permit the traffic. Testing with simple connectivity tools from a device on each subnet helps isolate whether the problem is routing or policy.
Intermittent drops often trace to an unstable internet connection, a gateway running out of resources, or a rekeying problem. Keeping a record of when drops occur makes patterns easier to see and speeds up the conversation with the internet provider or equipment vendor.
Checklist for Deploying a Site to Site Link
A structured checklist helps teams avoid the mistakes that cause most delays. The following steps are practical and can be adapted to the size of the organization.
- Document every site, its address range, and the subnets that must communicate across the link.
- Confirm that each gateway model supports the chosen tunnel type and the required encryption settings.
- Choose an authentication method and store any shared secrets or certificates in an approved password manager or key store.
- Write firewall rules that allow only the named services, and record the business reason for each one.
- Test the tunnel in a pilot, verify failover behavior if a second link exists, and schedule a periodic review.
Keep the final configuration and the test results together in one document. Assign an owner for the tunnel, set a reminder to review keys and algorithms, and plan a rehearsal for restoring the link after an equipment failure. These habits turn a one-time project into a reliable, well-understood part of daily operations.
Planning Your Next Step With Site to Site Connectivity
Looking ahead, the most useful next step is an honest inventory of your locations and the traffic they truly exchange. Many organizations find that only a handful of applications need cross-site access, which may point toward a narrower design than a full network merge.
Consider how the connection will grow. New offices, cloud environments, and partner networks each add subnets, and a design that works for two sites may strain under ten. Revisiting address planning and routing choices before growth arrives is far less costly than redesigning under pressure.
Treat the link as a security boundary, not just a convenience. Review its rules regularly, remove access that is no longer needed, and confirm that the people who manage it have current training. Consulting a qualified network professional can help validate the design against your organization’s requirements and any industry rules that apply to your data.