What a site-to-site VPN is and how it works

A site-to-site VPN is a connection that links two network locations (for example, an office network and a datacenter network) so that devices in each location can communicate as if they were on a private network—while traffic travels over an untrusted network such as the public internet.

At a high level, it works by establishing a secure tunnel between VPN endpoints, typically over IP. Once the tunnel is up, the endpoints encrypt and authenticate traffic that matches selected “interesting” traffic criteria (commonly defined by subnets or address ranges). Routing then determines which flows should traverse the tunnel.

Common implementation building blocks include:

  • VPN endpoints (gateways) that terminate the tunnel.
  • Key management for establishing security parameters (often via IKE for IPsec environments).
  • Encryption and integrity protections applied to tunnel traffic.
  • Firewall policies and routing rules that steer relevant traffic into the tunnel.

Core best-practice guidelines for implementation

Use these guidelines to reduce avoidable misconfigurations and clarify what you are trying to achieve.

  1. Define scope and traffic selectors early Before touching tunnel settings, list:
  • The “local” network ranges at Site A that should be reachable.
  • The “remote” network ranges at Site B that should be reachable.
  • Whether you need full-mesh connectivity across ranges or only specific application ports.

Best practice: align firewall rules and routing intent with those ranges. Mismatched selectors are a frequent reason for “tunnel is up but nothing passes.”

  1. Plan IP addressing and avoid overlaps Site-to-site VPNs become much harder when both sides use identical IP subnets (address overlap). If overlaps exist, you may need redesign, renumbering, or an alternative approach.

Practical guideline: confirm that every subnet you intend to route through the VPN is unique across the two sites.

  1. Make authentication and encryption choices consistent Both endpoints must agree on security parameters (protocol suite, authentication method, and key exchange behavior). In many setups, this means ensuring the same:
  • Cryptographic transforms and modes
  • Authentication settings (such as pre-shared keys or certificates)
  • Lifetimes and negotiation policies

Best practice: treat the configuration as a pair. If you change one side, validate that the other side still matches.

  1. Ensure routing is deterministic Once a tunnel exists, you need a clear decision on how packets are forwarded:
  • Static routing: you add routes that point specific remote subnets to the VPN gateway.
  • Dynamic routing (when supported): you advertise subnets and let the routing protocol decide.

Best practice for reliability: keep route intent simple at first, then expand. Confirm that the next-hop behavior is correct and that the return path is symmetric (or at least routable) for the traffic.

  1. Review firewall policy on both sides Even when VPN negotiation succeeds, traffic can still be blocked. Validate:
  • Outbound rules from the source network that allow VPN-bound traffic.
  • Inbound rules at the destination network that allow traffic arriving from the VPN.
  • Rules that permit VPN control-plane traffic (for example, the protocol used for key exchange and tunnel establishment).

Best practice: implement least privilege while ensuring the minimum required ports/protocols are allowed for tunnel setup and the intended data flows.

Differences and limitations to consider

Site-to-site VPN deployments often differ by topology and network constraints. The limitations below are common and can materially affect results.

NAT and firewall traversal Many deployments pass through NAT devices. NAT can complicate expectations about addresses and ports, especially if the VPN endpoint’s public reachability or source/destination translation is inconsistent. Some VPN implementations handle NAT traversal better than others, but behavior can be environment-specific.

Bandwidth and latency trade-offs A site-to-site VPN encrypts traffic and moves it over the internet or another shared network. This can introduce:

  • Throughput limits due to encryption overhead and internet path capacity
  • Latency impacts that affect interactive applications

Best practice: validate performance expectations with realistic test traffic rather than assumptions.

High availability and rekeying VPN tunnels are not permanent in the sense that security associations may be renegotiated or replaced. During rekey events, there can be brief disruptions depending on configuration and endpoint behavior.

Best practice: understand how your endpoints behave during rekey and failover, and document operational expectations.

Operational complexity Compared with local-only connectivity, VPNs add ongoing maintenance needs: certificate/key management (if certificates are used), monitoring, log review, and keeping configs aligned.

If you rely on dynamic routing, operational complexity increases further: you must ensure route advertisement and filtering are correct and stable.

Practical checks before and after you go live

Use a repeatable checklist to verify that the tunnel and the data-plane behavior match your intent.

  1. Confirm tunnel negotiation details Check that both endpoints:
  • Reach each other over the required control-plane paths.
  • Successfully negotiate agreed security parameters.
  • Report the tunnel as established (not merely “configured”).
  1. Verify the effective routing From a host at Site A, confirm that traffic destined for a remote subnet is routed toward the Site A VPN gateway. Then confirm that Site B has a return route back toward Site A’s subnet.

Best practice: validate with the exact subnets you plan to use, not generic “should work” ranges.

  1. Validate firewall rules with “known-good” test flows Test one direction and one protocol/port at a time. For example:
  • Start with ICMP or a simple TCP port if allowed by your security policy.
  • Then test application ports relevant to your real use case.

If connectivity fails, narrow down whether the problem is control-plane negotiation, routing, or data-plane firewall policy.

  1. Check traffic counters and logs Look for evidence that:
  • Packets matching your selectors are actually entering the tunnel.
  • Packets arriving at the destination are being accepted rather than dropped.

Best practice: correlate timestamps between sites when possible.

  1. Validate edge cases Before full rollout, test likely boundary conditions:
  • Multiple remote subnets routed over the same tunnel
  • Overlapping/near-overlapping addressing scenarios (if any exist)
  • Any NAT-related paths that differ from the “happy path”

To implement site-to-site VPNs effectively, it helps to be clear about adjacent concepts that often get mixed up.

  • Tunnel vs. routing: The tunnel is the protected transport; routing decides what traffic should use it.
  • Traffic selectors vs. firewall rules: selectors define what the VPN considers for encryption; firewalls still enforce policy.
  • Control plane vs. data plane: control plane sets up and maintains security parameters; data plane carries actual application traffic.
  • Security associations and rekeying: encrypted sessions have lifetimes; renegotiation can affect behavior.

Limitations matter here: even a correctly established tunnel does not guarantee that your required traffic is permitted and routable.