How site-to-site VPN connections work (in plain terms)

A site-to-site VPN typically creates an encrypted tunnel between two VPN gateways so that traffic from one network can securely reach the other network. The gateways negotiate encryption parameters (commonly involving two phases, such as key exchange and security association setup). After negotiation succeeds, each gateway evaluates traffic against configured “interesting traffic” (often called selectors, policies, or proxy IDs). If a packet matches, it is encrypted and sent through the tunnel; otherwise, it may be routed normally or dropped.

A key implication: many “VPN is up but nothing works” cases are not failures of encryption negotiation. They are policy, routing, or firewall problems that occur after the tunnel is established.

Common problems (with clear symptoms)

1) The tunnel never establishes

Typical symptoms: no stable tunnel state, repeated negotiation attempts, or errors related to authentication/key exchange.

Common causes include:

  • Mismatched cryptographic settings (algorithms, key sizes, lifetimes).
  • Incorrect peer identity/authentication details (for example, different pre-shared keys or certificates).
  • Incompatible protocol versions or negotiation expectations.
  • Network reachability problems between gateways (NAT/firewall blocks, wrong public IP/port assumptions).

2) The tunnel establishes, but traffic does not flow

Typical symptoms: the VPN shows as connected, but pings, application ports, or routes do not work across sites.

Common causes include:

  • “Interesting traffic”/selectors don’t match the real source/destination subnets.
  • One side routes the protected subnets incorrectly (missing routes, wrong next hop, overlapping subnets).
  • Firewall rules block decrypted traffic after it arrives on the far side.
  • Local host access is missing (for example, the destination device only allows certain sources).

3) Routing conflicts and overlapping IP space

Typical symptoms: intermittent reachability, unexpected paths, or the wrong packets being encrypted.

If the two networks use overlapping address ranges (e.g., both have 10.0.0.0/24), traffic selectors can become ambiguous. Even if negotiation succeeds, the gateway may not correctly determine which packets should be tunneled.

4) NAT traversal and address translation surprises

Typical symptoms: tunnel comes up only when using certain paths, or traffic fails when private addresses are involved.

NAT can change observed source/destination addresses and therefore affect selector matching and the peer reachability step. Some configurations require explicit handling of NAT behavior, and some environments make negotiation brittle if ports or addresses change.

5) Performance or stability issues that look like connectivity problems

Typical symptoms: the tunnel is technically up, but throughput is low, latency spikes, or sessions drop.

While exact causes vary, high-level contributors often include CPU constraints on gateways, fragmentation issues, lossy links, MTU/MSS mismatches, and oversubscription. These are harder to diagnose without measurements, but they usually show up as incomplete traffic delivery rather than a total negotiation failure.

Practical troubleshooting checks you can do step by step

Check 1: Endpoint reachability (before VPN logic)

Confirm each gateway can reach the other gateway’s reachable IP/port from the network path. If there is NAT, verify that the observed addresses/ports match what each gateway expects. If reachability fails here, no amount of VPN tuning will fix negotiation.

Check 2: Negotiation parameters match

Compare the configured cryptographic and authentication settings on both sides. Even a small mismatch—such as algorithm choice, key lifetime, or authentication method—can prevent successful security association setup.

Check 3: Identities and authentication

If the VPN uses shared secrets or certificate-based authentication, ensure the configured identities correspond to what the peer presents. Authentication mismatches can either block negotiation entirely or cause repeated resets.

Check 4: Verify selectors (“interesting traffic”) and subnet expectations

List the exact source and destination networks that should be protected (for example, Site A 192.168.10.0/24 to Site B 192.168.20.0/24). Then confirm the gateway policy uses those same network definitions.

Also check whether host routes, aggregated routes, or broad subnets are causing unintended matches or gaps. A very common failure mode is the VPN being configured for the “wrong” subnets, often due to assumptions about internal addressing.

Check 5: Routing and forwarding rules on each side

On each gateway (and any intermediate routers/firewalls), confirm there are routes for the remote protected subnets pointing to the VPN tunnel interface. If the gateways themselves can route, also confirm that end devices forward traffic correctly to their default gateway.

Check 6: Firewall policy on both sides (after encryption/decryption)

Even when the tunnel is up, the decrypted traffic must still be allowed by firewalls and host security policies. Confirm:

  • Inbound rules on the destination side allow the remote source addresses (as seen after decryption).
  • Outbound rules on the source side allow traffic to the destination subnet.

Check 7: Look at counters/logs to confirm which step fails

Use whatever visibility your gateway provides: tunnel status, negotiation logs, selector match counters, and dropped packet counters. The goal is to determine whether failure happens during negotiation, selector/policy matching, routing, or firewall enforcement.

Differences and limits to keep in mind

Site-to-site vs. remote-access VPN

Site-to-site is designed for network-to-network flows via gateways. Remote-access VPNs handle individual clients, often with different authentication, address assignment, and routing behavior. If you mix concepts or configurations, you can end up with policy mismatches.

Tunnel “up” does not guarantee end-to-end reachability

Encryption negotiation success only proves that the gateways agreed on security parameters and basic tunnel establishment. End-to-end communication still depends on correct selectors, routing, and firewall rules.

Overlapping subnets can force design changes

If address ranges overlap, you may need renumbering, more complex segmentation, or alternative approaches. Without resolving overlap, selector matching can remain incorrect.

NAT can affect observed packet headers and thus selector matching, while MTU/MSS issues can break specific protocols (especially those sensitive to fragmentation). These are frequently environment-specific, so treat them as hypotheses until you validate with logs and packet captures.

Provider or platform specifics may vary

Exact terminology and configuration fields differ by vendor and protocol suite. The underlying troubleshooting logic—reachability, negotiation match, selector/policy alignment, routing, firewall allowance—remains broadly applicable, but implementation details vary.

Minimal checklist to isolate the problem quickly

  • Confirm gateway-to-gateway reachability on the required IP/port path.
  • Compare crypto/auth settings so both sides negotiate compatible parameters.
  • Verify the protected subnets and selectors match real source/destination traffic.