Site to Site VPN Basics cover how two separate networks, such as a main office and a branch location, can exchange traffic over the public internet as if they were directly connected. This arrangement is common in businesses that operate several sites.
Unlike a personal VPN that protects one device, this type links entire networks together. Each site keeps its own local equipment, and a secure tunnel carries only the traffic that needs to move between them, which makes it a practical option for shared file access and internal applications.
Why Two Offices Sometimes Need to Act as One Network
Imagine a small accounting firm with a head office in Columbus and a branch office in Dayton. Staff at both locations need to open the same accounting database and print to the same server. Without a link between the two offices, each site would have to rely on exposing services to the internet, which is risky and difficult to manage.
A site to site VPN solves this by creating a private path between the two local networks. Devices at one office can reach resources at the other using their normal internal addresses, while outsiders on the public internet see only encrypted traffic moving between two gateway devices.
This approach keeps the internal layout of each office largely unchanged. Staff do not need to learn new connection steps, and the IT team can manage one secure link rather than dozens of individual device connections.
What a Site to Site VPN Actually Connects
A site to site VPN joins two networks, not two people or two laptops. Each network is typically a local area network, which is a collection of devices such as computers, printers and servers within one building or campus. The VPN connects the gateway devices at the edge of each network, and those gateways handle the encryption and forwarding.
The gateway at each site is usually a router or firewall that supports VPN features. It holds the settings needed to establish the tunnel, including the identity of the remote gateway and the rules for which traffic should travel through the tunnel.
Because the connection operates at the network level, individual devices behind the gateway generally do not need VPN software installed. They send traffic to addresses on the other network, and the local gateway takes care of protecting that traffic before it leaves the building.
Core Components You Will Encounter
Most site to site VPN setups rely on the same set of building blocks. Understanding these terms makes vendor documentation and configuration screens much easier to read.
- Gateway devices: the routers or firewalls at each site that create and terminate the tunnel.
- Tunnel: the encrypted logical path that carries traffic between the two gateways across the public internet.
- Encryption and integrity settings: the cryptographic methods that hide the data and detect tampering while in transit.
- Authentication: the method each gateway uses to prove its identity, often through a pre-shared key or a digital certificate.
- Traffic selectors: the defined lists of source and destination networks that determine which traffic enters the tunnel.
The exact names and options differ between manufacturers, but the underlying roles stay the same. When comparing equipment, check that it supports the standard protocols your partner site also uses, because mismatched settings are one of the most common reasons a tunnel fails to come up.
How the Tunnel Is Built and Maintained
Establishing a site to site VPN typically begins with a negotiation phase. The two gateways exchange information about the encryption methods they support and agree on the keys that will protect the session. A widely used standard for this process is IKE, the Internet Key Exchange protocol, which handles the handshake securely.
Once the handshake succeeds, the gateways begin sending data through the tunnel. Each packet from the local network is wrapped in an encrypted envelope addressed to the remote gateway. The receiving gateway unwraps it, checks that it has not been altered, and forwards the original packet to the destination device on its own network.
Tunnels can be configured to stay up continuously or to re-establish when traffic appears. Many administrators prefer a persistent tunnel with dead peer detection, a mechanism that notices when the other gateway stops responding and triggers a reconnection attempt.
Planning the Address Space Before You Configure Anything
Addressing is one of the first things to settle. If both offices use the same private address range, such as the common 192.168.1.0 block, the gateways will not know which device a packet is meant for. Each site should use a distinct subnet, which is a defined range of addresses within a larger network.
A simple planning exercise helps here. List every subnet at each location, note which ones need to be reachable from the other site, and confirm that no two ranges overlap. Writing this down in a shared document prevents confusion when the tunnel is configured months later by someone new to the project.
It is also wise to leave room for growth. If the head office uses a /24 subnet with 254 usable host addresses, consider whether future expansion could require more. Changing addressing after a tunnel is live is disruptive and often requires coordinated changes at both locations.
Choosing a Design: Common Topologies Explained
Site to site VPNs can be arranged in several shapes, and the right choice depends on how many locations need to communicate and how much traffic they exchange. The three arrangements below are the ones most often discussed in planning meetings.
Point to Point Links
A point to point design connects exactly two sites through a single tunnel. It is the simplest arrangement and the easiest to troubleshoot, because there is only one path to inspect. Many small businesses with a headquarters and one branch choose this model.
Its main limitation is that it does not scale well. Adding a third site means creating additional tunnels between every pair of locations, which quickly becomes difficult to maintain. For a two-location business, however, the simplicity is often an advantage.
Hub and Spoke Networks
In a hub and spoke design, a central site acts as the hub and each remote branch connects to it as a spoke. Traffic between two branches travels through the hub, so the hub must be configured to route it correctly. This model reduces the number of tunnels to manage, since each branch needs only one connection.
The trade-off is that the hub becomes a single point of dependence. If the hub experiences an outage or becomes overloaded, communication between all branches can be affected. Planning redundancy at the hub site is therefore an important part of this design.
Full Mesh Connections
A full mesh design creates a direct tunnel between every pair of sites. Traffic can take the shortest route without passing through a central point, which can improve performance and resilience. Each site also has more than one path to others, so a single link failure does not necessarily isolate a location.
The drawback is complexity. With four sites, a full mesh needs six tunnels, and with six sites it needs fifteen. Administrators must keep settings consistent across all of them, so this design is usually reserved for organizations with a clear need for direct, redundant connectivity.
Security Considerations That Deserve Attention
A site to site VPN protects traffic in transit, but it does not automatically secure the networks at either end. The encrypted tunnel only guarantees that data cannot be read or altered between the gateways. Devices on each side remain responsible for their own protection, including updated software, strong passwords and sensible access rules.
Authentication strength matters a great deal. Pre-shared keys are simpler to set up but must be long, random and kept secret, since anyone who obtains one may be able to impersonate a gateway. Digital certificates offer stronger identity checks and easier management at larger scale, though they require a process for issuing and renewing them.
Access control is equally important. Traffic selectors should permit only the subnets that genuinely need to communicate. Allowing an entire network to reach every resource at the other site increases exposure if one location is compromised, so applying the principle of least privilege to tunnel rules is a sound habit.
Testing and Troubleshooting a New Tunnel
After configuration, confirm the tunnel reaches an established state in the gateway status screen before testing anything else. If it does not, the logs usually indicate the cause, such as mismatched encryption settings, an incorrect remote address or a firewall blocking the protocol ports used for key exchange.
Once the tunnel is up, test connectivity in both directions. A device at Site A should be able to reach a server at Site B, and the reverse should also work. Testing only one direction is a common oversight that leaves problems hidden until someone at the other site tries to connect.
Keep a short checklist for future changes. Record the gateway models, firmware versions, subnet assignments and key-exchange settings. Documentation made at setup time saves considerable effort when a firmware update or staff change makes the tunnel harder to understand later.
Common Mistakes to Avoid When Setting Up a Link
Most failed or unreliable site to site connections trace back to a small number of preventable errors. Reviewing this list before deployment can save hours of troubleshooting.
- Using overlapping private address ranges at the two sites, which prevents the gateways from routing traffic correctly.
- Mismatching encryption or key-exchange settings between the two gateway devices.
- Forgetting to open the firewall ports required for the tunnel protocol on both sides.
- Configuring traffic selectors too broadly, which grants more access than the business actually needs.
- Failing to plan for an ISP outage or gateway failure, leaving no alternate path for critical services.
Many of these mistakes are easier to avoid when the planning and configuration are reviewed by a second person. A brief peer check before going live catches most errors, and it creates a shared understanding of how the link is supposed to behave.
Next Steps for Planning a Reliable Office Connection
If you are considering a site to site VPN, begin by listing the locations involved, the resources each one must reach and the internet connections available at each site. This inventory clarifies whether a point to point, hub and spoke or full mesh design fits your situation and highlights any gaps in the current infrastructure.
Next, check whether your existing gateway equipment supports site to site VPN features, and confirm the protocols and encryption standards it offers. Speak with the vendor or a qualified network professional about licensing, support and firmware update policies, since these affect the long-term cost and maintenance burden of the solution.
Schedule a test period before relying on the link for daily operations. Run it alongside existing processes, monitor logs and performance, and gather feedback from staff at each location. A carefully tested tunnel is far more dependable than one rushed into production.