How a site-to-site VPN works

A site-to-site VPN creates an encrypted tunnel between two network gateways (often VPN routers or firewalls). Instead of individual devices connecting to the internet, whole networks communicate “as if” they were reachable over a private link.

Typical flow:

  • When a host in Network A needs to reach a destination in Network B, it sends the traffic to its local gateway.
  • The gateway applies the VPN tunnel rules, encrypts the traffic, and sends it to the remote gateway over the underlying transport (commonly the public internet).
  • The remote gateway decrypts the traffic and forwards it into Network B using its local routing.

Conceptually, the VPN is a combination of (1) tunnel establishment (handshake/negotiation) and (2) traffic policy (which subnets are allowed to traverse the tunnel). Even when encryption is strong, connectivity still hinges on correct routing and firewall configuration.

What you need before you start

Before attempting configuration, confirm you have the basic building blocks:

  • Two gateway endpoints (devices or software) that support site-to-site VPN functionality.
  • Public (or otherwise reachable) addresses for the gateways, or a design that provides reachability between them.
  • Network details for both sides: the IP subnets you want to connect.
  • A plan for addressing overlap: if both sites use the same private IP ranges (e.g., both use 192.168.1.0/24), routing ambiguity can break connectivity.
  • Decision on how DNS should behave (for example, whether clients should use remote DNS servers, and which resolver is reachable).

Because there are multiple VPN types and implementations, exact UI labels and parameters vary by vendor and protocol. Treat the steps below as a checklist for the underlying concepts rather than a copy-paste recipe.

Core setup steps (conceptual)

Most site-to-site VPN setups can be mapped to these core configuration themes:

  1. Define tunnel identities and authentication You will configure how the gateways authenticate each other. Common approaches include pre-shared keys or certificates, depending on the product and VPN protocol.

  2. Choose cryptographic and tunnel parameters Both sides must agree on items like key exchange method, encryption/authentication algorithms, and the tunnel “mode” supported by your setup. If the parameter sets don’t match, the tunnel may fail to establish or fall back to incompatible defaults.

  3. Declare “interesting” traffic (subnets) You must specify which source/destination subnets should traverse the tunnel. This is often represented as local and remote networks or “selectors.” Incorrect selectors are a frequent cause of “tunnel up but nothing works.”

  4. Configure routing across the tunnel Once traffic enters the VPN, the remote gateway needs a route to the destination subnets in the other site. Depending on the design, this may be done with static routes or dynamic routing. If routing is wrong or missing, packets may be encrypted but never delivered.

  5. Apply firewall rules on both sides Even with a working tunnel, gateways and internal firewalls must allow the relevant traffic flows. Ensure inbound rules permit the tunneled traffic and outbound rules permit return traffic.

Differences and limits you should expect

Site-to-site VPNs can work well, but there are common constraints that change outcomes:

  • NAT and addressing behavior: If one or both sites use NAT, the encrypted tunnel may still work while end-to-end traffic fails due to how addresses are represented. Pay special attention to whether gateways translate addresses or preserve internal IPs.
  • Overlapping IP ranges: When both sites use the same private subnets, “which site is which” becomes ambiguous without additional techniques (often redesign or address translation).
  • DNS and name resolution: Encrypted connectivity does not automatically make hostnames resolve over the tunnel. Clients may need reachable DNS servers, correct DNS forwarding, or updated resolver settings.
  • Performance perception vs. real throughput: Encryption and tunnel overhead can reduce effective throughput. Actual results depend on hardware, bandwidth, latency, and protocol choices; plan capacity rather than assuming line-rate performance.
  • Partial connectivity: It’s possible for the tunnel to come up but only certain ports/services to work, usually due to firewall rules or application-layer behavior.

Because implementations vary, it’s normal for the “correct” configuration approach to differ across hardware models and VPN protocol families. If you see a mismatch between what one side expects and what the other side offers, treat it as an interoperability problem to resolve.

Practical checks before relying on production

Use a structured verification process to reduce surprises:

  1. Confirm tunnel establishment Check the gateway status for whether the tunnel is established (and whether it is rekeying normally, if that information is available).

  2. Verify negotiated parameters Look for logs or status panels that show the effective encryption/auth/authentication suite and key exchange behavior. If settings differ from what you intended, review compatibility on both endpoints.

  3. Validate reachability and selectors Confirm that traffic from the expected source subnets to the expected remote subnets is considered “interesting” by the VPN policy. If you test from the wrong subnet or use an unselected destination, you can get misleading results.

  4. Check routing and return path After sending traffic from Site A to Site B, ensure Site B can send replies back to Site A through the VPN. A common failure mode is missing return routes or firewall rules that block responses.

  5. Test at multiple layers

  • Network layer: ping or traceroute to confirm basic IP reachability.
  • Transport layer: test the specific ports your applications need.
  • Application layer: verify a representative session (e.g., authentication or a simple transaction) rather than only ICMP.
  1. Watch logs during changes When troubleshooting, record timestamps and tunnel events. If tunnel renegotiation happens during your tests, you may temporarily see packet loss or delays.

To place a site-to-site VPN in context, it helps to distinguish it from adjacent ideas:

  • Site-to-site vs. remote-access: site-to-site focuses on network-to-network connectivity through gateways, while remote-access targets individual users.
  • Overlay routing: a VPN can make remote subnets reachable, but it doesn’t replace your overall network design—routing, DNS, and firewall policy still matter.
  • Key management and rekeying: even if traffic flows today, periodic rekeying or certificate/key rotation can affect stability.

If you need to explain the goal to stakeholders, use this framing: a site-to-site VPN is a secure tunnel between two gateways, constrained by what subnets you allow, what routes exist, and what your firewalls permit.