What a site-to-site VPN is and when you use it

A site-to-site VPN connects two (or more) networks so that machines in one network can reach machines in the other through an encrypted tunnel. Instead of configuring VPN clients on individual devices, you typically configure the VPN on the network edge—often a gateway or firewall—so the tunnel transports traffic between defined subnets.

In practice, site-to-site VPNs are used for:

  • Linking branch offices to a headquarters network
  • Connecting datacenter networks to other networks
  • Providing secure connectivity between network segments that must communicate regularly

How site-to-site VPN configuration works (high level)

Most site-to-site designs follow three cooperating parts:

  1. Tunnel establishment Both gateways must agree on the security parameters used to create the tunnel (for example, key exchange and encryption/authentication choices). If the parameters don’t match, the tunnel may fail to come up.

  2. Traffic selectors and what is allowed through the tunnel Beyond “the tunnel exists,” the configuration usually defines which internal networks (subnets) are permitted to use the tunnel. Think of this as the mapping: “traffic to these destinations should go into the VPN.”

  3. Routing so traffic takes the correct path Once the tunnel is up, routing decides whether packets destined for remote subnets are sent toward the VPN gateway (and not sent to a local interface or default route). This includes both the local side routes and the remote side routes.

A useful mental model is: tunnel parameters must match, then routing and subnet definitions must align on both endpoints, then firewalls must allow the traffic.

Differences and limits you should plan for

Site-to-site VPNs are powerful, but a few limitations frequently determine whether the connection is workable.

Routing complexity and “it’s up but nothing works”

Even when encryption and tunnel negotiation succeed, connectivity can still fail if:

  • One side routes the remote subnet incorrectly
  • The tunnel “selectors” don’t include the exact subnets you’re testing
  • Overlapping IP ranges exist (for example, both sites use 192.168.1.0/24)

These failures often show up as timeouts rather than clear errors.

NAT and address translation issues

If either gateway is behind NAT (or there is NAT along the path), the configuration may need NAT traversal behavior and careful handling of how addresses are matched. NAT can also break assumptions about which source/destination addresses should be carried inside the tunnel.

Throughput and latency constraints

Site-to-site VPNs add encryption overhead and can be constrained by the gateway hardware, encryption configuration, and available internet bandwidth. If you see poor performance, you’ll generally want to validate whether the limiting factor is the tunnel configuration, the path, or the endpoint capacity.

Protocol and device compatibility

Different vendors and configurations can interpret features differently. For robust results, ensure both sides use compatible choices for authentication, encryption, and key exchange, and that any required modes are enabled consistently.

Practical checks and optimization tips before you declare it working

Use a structured checklist so you verify each dependency in order.

1) Confirm the tunnel state

Start with whether the tunnel is actually established and stable. If logs indicate negotiation failures or repeated rekeying, resolve those first before testing application traffic.

2) Verify subnet (traffic selector) alignment

Check that the local configuration includes the remote subnet(s) you need, and that the remote side includes the corresponding local subnet(s). Be explicit about the exact networks being routed over the VPN.

If you are testing a host, verify that the host’s IP is within the intended subnet(s). If you’re testing a service behind another gateway, verify that the service’s destination addresses match what the tunnel and routing expect.

3) Check routing on both endpoints

Validate that packets sourced from Site A and destined for Site B actually leave Site A via the VPN gateway, and that packets arriving at Site B are routed back to Site A’s subnet. A common problem is one-way reachability: Site A can reach Site B, but responses don’t return via the tunnel.

4) Review firewall rules around the VPN

Even with correct cryptographic settings, firewalls may block:

  • Traffic entering from the VPN interface
  • Necessary outbound/inbound rules on internal subnets
  • ICMP or DNS/management ports required for troubleshooting

Temporarily testing with narrower rules can help identify what’s blocked, but avoid leaving overly broad access enabled.

5) Test end-to-end reachability with simple probes

Before application testing, try:

  • Ping or ICMP where allowed
  • DNS resolution if name-based testing is needed
  • TCP connectivity to a known service port

If a probe fails, correlate the failure with tunnel logs, routing tables, and firewall counters.

6) Optimize by reducing mismatch and tightening scope

Optimization is mostly about correctness plus efficiency:

  • Use only the subnets that must traverse the tunnel
  • Avoid overlapping address spaces across sites
  • Keep security settings consistent and up to date on both endpoints
  • Prefer stable routing decisions (and avoid unnecessary policy complexity)

If performance is the goal, consider measuring latency/packet loss through the tunnel path and compare it to non-VPN paths to isolate where degradation occurs. Because gateway capacity varies widely, treat any performance expectations as configuration- and hardware-dependent.

Site-to-site VPN setup often overlaps with these ideas:

  • Network segmentation and routing policy: determines what should go through the tunnel
  • Firewall policy enforcement: decides what traffic is permitted across tunnel boundaries
  • Address planning: helps prevent overlap and reduces selector/routing complexity
  • High-availability design: can affect how tunnels fail over and how quickly routes converge

If you are comparing options, also consider that “site-to-site VPN” is a general term; the exact behavior depends on the tunnel technology and how your gateways implement routing, NAT traversal, and policy enforcement.

Key limitations to keep in mind

If you need a clear “exception list,” focus on these:

  • Overlapping IP ranges at both sites
  • NAT along the path requiring additional settings
  • Routing mismatch causing one-way connectivity
  • Tunnel negotiation failures due to incompatible security parameters
  • Performance constraints from gateway capacity and the underlying internet path

When in doubt, verify tunnel state first, then subnet/selector alignment, then routing symmetry, then firewall allowances—only then proceed to deeper performance tuning.