What a site-to-site VPN is

A site-to-site VPN (Virtual Private Network) connects two networks—such as branch offices or a data center and an office—so that machines on one side can reach machines on the other side as if they were on the same private network.

Unlike a remote-access VPN that focuses on individual devices, a site-to-site design typically treats entire subnets as “interesting” traffic. Encryption and authentication protect the traffic between the gateways (VPN endpoints), while routing determines which source/destination networks are allowed through the tunnel.

How it works, end to end

At a high level, a site-to-site VPN has four moving parts:

  1. VPN endpoints (gateways): Routers or dedicated security devices sit at each network edge and establish the tunnel.

  2. Tunnel and key exchange: The endpoints negotiate encryption parameters and cryptographic keys. The negotiation method depends on the VPN type (for example, IPsec-based designs are common).

  3. Access policy (what subnets are allowed): Each side defines which internal networks (subnets) should be reachable over the tunnel.

  4. Routing and forwarding: Once the tunnel exists, packets are routed so that traffic destined for the remote subnet is forwarded into the VPN gateway, then encapsulated and sent through the encrypted tunnel. The remote gateway decapsulates and forwards packets to the target subnet.

A practical mental model is: “local routing decides to send to the gateway; the gateway decides to encapsulate into the tunnel; the remote gateway decides to deliver to the remote subnet; remote routing delivers to hosts.”

What you typically set up

To get a site-to-site VPN working, you usually configure settings in three categories:

  • Tunnel endpoints and reachability: You must ensure each gateway can be reached over the underlying network (often the public Internet or a provider link). That means IP addressing, DNS (if used), and basic connectivity between gateway addresses.

  • Authentication and encryption parameters: You select an authentication method and encryption settings supported by both endpoints. The exact options vary by implementation, but the goal is consistent negotiation on both sides.

  • Traffic selectors and routing: You configure which local subnets can talk to which remote subnets, and you align routing so that return traffic follows the same path conceptually. If you use static routes, you add routes for the remote subnets pointing to the local VPN gateway. If you use dynamic routing, you ensure the VPN can carry the routing information and that policies are consistent.

Two configuration mistakes frequently prevent connectivity: (a) mismatched “allowed subnet” definitions between gateways, and (b) missing routes (or wrong next hops) for return traffic.

Differences and limits to be aware of

Site-to-site VPNs are powerful, but there are constraints that often change the outcome during setup.

  • Overlapping IP ranges: If both sites use the same private address block (for example, both use 192.168.1.0/24), routing and traffic selection can become ambiguous. Many designs can’t cleanly resolve this without renumbering or additional translation.

  • NAT complications: If one or both networks use Network Address Translation, you must understand whether NAT happens before or after encryption, and how the gateway identifies the “real” internal addresses. Misaligned NAT can make return traffic fail.

  • Firewall rules still apply: Even with an encrypted tunnel, you typically need firewall allowances for the tunnel’s control/data flows on the gateways and to permit traffic within the local networks.

  • Performance and stability trade-offs: Encrypted encapsulation and key negotiation introduce overhead. While the exact performance depends on hardware and traffic patterns, you should treat the VPN tunnel as a stateful path that can be affected by network jitter, packet loss, or gateway CPU limits.

  • Not a full network replacement: A VPN usually connects subnets over the tunnel; it does not automatically make every service and protocol work unless ports, policies, and routing are correct.

Practical checks before you declare it “working”

Use a checklist approach focused on tunnel health and end-to-end reachability.

  1. Confirm the gateway-to-gateway tunnel comes up Verify that the endpoints successfully negotiate and establish the tunnel. If you can’t confirm negotiated state, do not proceed to subnet testing.

  2. Validate “interesting traffic” matching Check that the configured local/remote subnets (or traffic selectors) match the networks you intend to connect. A single subnet typo can make everything look “up” while no user traffic crosses.

  3. Ensure routing is correct on both sides For static routing, verify that each gateway has a route to the remote subnet pointing toward the tunnel. For dynamic routing, ensure route exchange is occurring and that policies permit the intended destinations.

  4. Check end-to-end connectivity between specific hosts Pick two hosts—one from each site—within the allowed subnets. Test basic reachability and application ports relevant to your use case. This helps separate “tunnel exists” from “traffic is actually delivered.”

  5. Look for asymmetric behavior If traffic goes one way but replies fail, it often indicates routing mismatch, firewall state issues, or NAT-related address translation differences. Re-check that both sides expect return traffic to traverse the tunnel.

Even if your goal is straightforward connectivity, it helps to distinguish related VPN ideas:

  • Road-warrior (remote-access) VPN vs site-to-site: remote-access targets individual devices; site-to-site targets network-to-network traffic.

  • Full-mesh vs hub-and-spoke designs: with multiple sites, you must decide how many tunnels you need and how routing policies scale.

  • Routing model (static vs dynamic): the choice affects troubleshooting and how quickly changes propagate.

If you understand these concepts, you can better interpret failures (for example, whether the issue is tunnel establishment, subnet selection, or routing).

What can change the answer

Your exact steps depend on the VPN type, gateway vendor configuration model, and network design (addressing, NAT, and firewall rules). Since no source-specific details are provided here, treat the guidance above as a general setup framework and use your gateways’ interface/diagnostics to confirm the tunnel state and packet flow.