What a site-to-site VPN does in business terms

A site-to-site VPN creates a secure, encrypted connection between two network locations (for example, a company office and a data center). Instead of individual users setting up VPN clients, the link is established between network gateways—devices such as firewalls or dedicated VPN appliances.

In practice, you define:

  • The VPN endpoints (gateways at each site)
  • The encryption and authentication method (tunnel parameters)
  • The “interesting traffic” (which IP ranges from site A should be reachable from site B)
  • The routing behavior (how traffic is forwarded through the tunnel)

A useful mental model is: once the tunnel is up and routing points to it, packets between the specified subnets will be encapsulated, transmitted securely, then decrypted and delivered at the other site.

How the connection works: tunnels, keys, and traffic selectors

Most site-to-site VPN implementations rely on a negotiation phase that establishes security parameters (keys, algorithms, and lifetimes). After negotiation succeeds, traffic that matches the configured selectors (often called traffic selectors or “protected subnets”) is carried inside the tunnel.

Key moving parts you should understand:

  • Phase 1 / negotiation: establishes the secure channel and cryptographic context.
  • Phase 2 / child security context: binds that context to specific traffic selectors (e.g., “10.10.0.0/16” at Site A to “192.168.50.0/24” at Site B).
  • Encapsulation and routing: inside the tunnel, packets keep their original IP addresses; outside, they are wrapped for transport across the internet or WAN.

Because selectors and routing must agree with real network policies, “tunnel is up” is not the same as “application traffic is working.” The tunnel can be established while no traffic matches the selectors, or while routing rules still send packets somewhere else.

Differences that matter: route-based vs policy-based, and tunnel scope

Not all site-to-site VPNs behave the same way, even when they look similar.

Route-based VPN behavior

In a route-based setup, you typically add routes for remote subnets so that the gateways automatically forward matching traffic into the VPN tunnel. This can be simpler when many subnets or changing networks are involved.

Policy-based VPN behavior

In a policy-based setup, you often define explicit policies that match source/destination subnets and ports/protocols. This can be precise, but can become complex as the number of subnets grows.

Tunnel scope: what gets encrypted and forwarded

You also need to clarify what “site-to-site” means in your environment:

  • Which subnets are reachable across the tunnel (traffic selectors or protected networks)
  • Whether only specific traffic is sent through the VPN or broader routing causes more traffic to traverse it

A common limitation is that misalignment between the protected subnets and actual addressing/routing leads to partial connectivity—some devices can ping by accident, while application flows fail due to mismatched routes, missing firewall rules, or DNS not resolving across sites.

Practical limitations and real-world failure modes

Site-to-site VPNs can fail in predictable ways. Understanding these helps you scope checks.

  1. Address overlap: If both sites use the same private IP ranges, traffic selectors and routes become ambiguous. This can break connectivity even if the tunnel comes up.
  2. Firewall policy mismatch: Even with correct VPN settings, the gateways and intermediate security controls must allow the required traffic flows.
  3. Routing asymmetry: If traffic enters the tunnel one way but returns using a different path (or not via the tunnel), sessions may not complete.
  4. MTU and fragmentation issues: Encapsulation adds overhead; this can cause performance problems or broken connections for protocols sensitive to packet size.
  5. Protocol/port expectations: Applications rely on more than just reachability. Services may require specific ports, TCP/UDP behavior, or bidirectional access.

Importantly, avoid assuming that because encryption is enabled, everything is automatically correct. Many failures come from configuration alignment: selectors, routes, and firewall rules.

A practical checklist: verify before and after rollout

Use this as a verification mindset rather than a single “one-time” test. Check connectivity at each layer of the problem.

  • Endpoint reachability: Confirm each gateway can reach the other gateway’s public (or routable) IP over the transport network.
  • Tunnel status vs traffic: Verify the VPN tunnel state and then confirm a specific route or policy exists for the intended remote subnets.
  • Protected subnets (traffic selectors): Ensure the exact source/destination network ranges on both sides match, including subnet masks.
  • Routing direction: Confirm that packets destined for remote subnets are actually forwarded into the VPN (and that return traffic uses the tunnel as well).
  • Firewall rules at both sites: Validate that policies allow required protocols/ports from the local subnet to the remote subnet.
  • Application-layer checks: After basic IP reachability, test the real use cases (for example, name resolution and the specific application sessions), because DNS and service ports are frequent bottlenecks.

If you can’t reach a remote subnet, resist broad changes first. Identify whether the issue is transport reachability, tunnel negotiation, selector/routing mismatch, or firewall policy.

When planning connectivity, you may encounter adjacent approaches. Knowing their differences prevents category mistakes:

  • Remote-access VPN: Individual users connect to a corporate network via a client; site-to-site focuses on gateway-to-gateway connectivity.
  • Direct connectivity (dedicated WAN): Provides private transport without typical internet-based tunneling; it may simplify routing but changes cost and operational assumptions.
  • SD-WAN overlay: Often combines multiple underlay links and policies; a site-to-site VPN can still be one component of the overall design.

The limitation to remember: a “VPN” is not a complete network design by itself. The surrounding IP plan, routing strategy, firewall architecture, and operational monitoring determine whether the solution works reliably.

Key takeaway

A site-to-site VPN is best treated as an engineered path between two networks: define endpoints, agree on protected subnets, ensure routing sends the right traffic into the tunnel, and confirm firewall policies and application requirements end-to-end.