What a site-to-site VPN is

A site-to-site VPN is a secure network connection that links two separate networks (for example, two office locations or a branch network to a partner network) through an encrypted “tunnel” over an intermediate network such as the public internet. Instead of protecting a single user’s device, the VPN is usually established between network gateways (firewalls, VPN appliances, or routers) so that multiple devices on each side can communicate through the same tunnel.

In many designs, the gateways decide which traffic should be sent through the tunnel by using rules commonly called “selectors” (often based on source/destination IP ranges and ports). Only that selected traffic is encapsulated and sent through the encrypted channel.

How the tunnel is formed

While implementations vary, the process usually has three big phases:

  1. Negotiation: The gateways agree on security parameters such as key material and cryptographic algorithms. If authentication is configured correctly, each side can verify that it is talking to the expected peer.

  2. Tunnel establishment: Once negotiation succeeds, the gateways create the encrypted tunnel. At this stage, you can think of the connection as an active channel where data can be wrapped (encrypted) on ingress and unwrapped on egress.

  3. Traffic flow: When packets match the configured selectors, they are encapsulated into the tunnel and sent to the peer gateway. The remote gateway decapsulates them and forwards the traffic toward the destination network.

Because the VPN is built between gateways, the surrounding network configuration matters: gateway-to-gateway reachability, routing toward internal subnets, and firewall policies on both sides all influence whether traffic will actually pass.

It helps to distinguish site-to-site VPNs from other common VPN patterns:

  • Remote-access VPN (user-to-site): Protects a user device connecting to a single site gateway. The tunnel focus is typically the device session.
  • Site-to-site VPN (site-to-site): Protects network-to-network traffic by using gateway-to-gateway tunnels, often supporting many internal hosts.
  • “Always-on” vs on-demand: Some deployments maintain tunnels continuously; others bring tunnels up as needed. What matters for troubleshooting is whether the tunnel is currently established and whether the selectors match the traffic you’re trying to send.

A related concept is overlay connectivity: many site-to-site VPNs behave like an overlay network on top of the underlying internet path, but they still depend on correct IP addressing, routing, and firewall permissions.

Differences and limitations that affect real deployments

A site-to-site VPN can be straightforward when networks are simple, but several limitations commonly change outcomes:

  • Routing complexity: Even with encryption working, endpoints must be routable. If the gateways do not know how to reach the remote internal subnets (or routes conflict), traffic may not arrive.
  • Selector mismatches: If the IP ranges or ports you expect to travel through the tunnel are not included in the configured selectors, the gateways may simply send the traffic outside the tunnel or drop it.
  • Performance and latency tradeoffs: Encryption and tunnel encapsulation add overhead. Actual throughput and latency depend on factors like CPU load on gateways, tunnel configuration, and the underlying internet path.
  • Operational and misconfiguration risk: Small configuration errors (wrong peer identifiers, incorrect keys, firewall rules that block tunnel traffic, asymmetric routing, or DNS assumptions) can prevent establishment or cause partial connectivity.

It’s also important to avoid assuming absolute security. A VPN reduces exposure by encrypting traffic and enforcing policies, but real-world security depends on correct configuration, key management, gateway hardening, and consistent monitoring.

Practical checks you can run

To validate a site-to-site VPN, focus on checks that directly test tunnel health and end-to-end reachability:

1) Confirm the tunnel state

Look at gateway logs or status screens to verify that:

  • The tunnel is actively established (not merely configured).
  • Negotiation/authentication succeeded.
  • There are no ongoing error messages related to keys or peer identity.

2) Check selector coverage

Verify that the traffic you intend to send matches the tunnel’s configured selectors (source subnet → destination subnet, and any required ports/protocols). If your test traffic uses different IP ranges than expected, you may need to adjust selectors.

3) Validate routing and firewall rules

Ensure both sides have:

  • Routes toward the remote internal subnets (either static routes or dynamic routing, depending on the design).
  • Firewall rules that permit:
    • tunnel protocol traffic between gateways, and
    • the specific internal traffic that should traverse the tunnel.

4) Perform an end-to-end connectivity test

Use controlled tests from a host (or a test subnet) to confirm that packets can reach the remote side. If you see connectivity failures, compare whether the failure occurs at:

  • tunnel establishment time, or
  • internal traffic forwarding after the tunnel is up.

5) Watch for asymmetric behavior

If one direction works but the other fails, suspect routing asymmetry, missing return routes, or firewall state issues. Confirm that return traffic is using the tunnel as intended.

A few terms often appear alongside site-to-site VPNs:

  • Encryption and authentication: Core to protecting traffic confidentiality and ensuring gateways verify peers.
  • Tunnel mode vs. transport mode (general concept): Some designs wrap IP packets differently; how packets are encapsulated affects troubleshooting and firewall rules.
  • Public internet path vs private transport: The internet can be the transport, but performance and reliability are not guaranteed.
  • Key management: Rekeying schedules and certificate/PSK handling affect long-term stability.

If you’re evaluating whether a site-to-site VPN is the right fit, the key question is usually operational: can you reliably align addressing, selectors, routing, and firewall policies so that the intended traffic has a clear, permitted path through the tunnel?