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

A site-to-site VPN is an arrangement that connects two separate networks (often “Site A” and “Site B”) through an encrypted tunnel. Instead of protecting only one device, it protects the traffic as it travels between the sites.

In practice, the VPN endpoints are usually located on devices that speak to your internal networks (e.g., VPN gateways or routers). When traffic is sent from Site A to Site B, it is matched to VPN “interesting traffic” rules and then encapsulated and encrypted before crossing the public network. At the other end, the tunnel decapsulates and decrypts the packets and forwards them to the correct destination network.

A typical packet flow looks like this:

  1. A host on Site A sends traffic destined for a network at Site B.
  2. Site A’s VPN gateway decides that the traffic should go into the tunnel.
  3. The gateway encrypts and sends it through the public network.
  4. Site B’s VPN gateway receives, decrypts, and routes the traffic to the destination network.

Two related concepts matter for understanding behavior: routing (how packets are forwarded inside each site) and addressing overlap (whether both sites use the same internal IP ranges). If the two sites share identical private address ranges, you may need additional design steps; otherwise, traffic can be ambiguous.

Benefits for DSL users

For DSL-based deployments, the main benefits are security and network integration, not raw speed.

Encrypted inter-site communication

A site-to-site VPN encrypts data in transit between the two sites. That can reduce exposure of application traffic to the public path, especially when the public network is used in a transit role.

Centralized control at the network edge

Because the VPN is anchored at the gateways, you manage connectivity as a network feature. This can simplify enforcement compared with securing individual client devices, particularly when many devices at each site need access to the other network.

Interoperability of “normal” IP traffic

When configured with correct routing and firewall rules, typical IP-based services can work across sites as if internal networks were logically connected. The tunnel often makes the inter-site communication consistent from the application perspective (subject to latency and path quality).

Risks and limitations on a DSL connection

On DSL, the risks are usually practical rather than theoretical: the tunnel can change performance characteristics, and configuration errors can break connectivity.

Added latency and reduced effective throughput

Encryption, encapsulation, and tunnel negotiation introduce overhead. On a slower DSL uplink or downlink, that overhead can be more noticeable. The result may be higher latency and less usable throughput for the protected traffic compared with non-encrypted paths.

The VPN’s stability depends on the public connectivity between the gateways. If the DSL line is unstable, suffers from frequent drops, or has high jitter, the tunnel may renegotiate or temporarily fail, affecting the reachability between sites.

Complexity: routing, firewalling, and NAT

Most VPN failures come from mismatched expectations between the gateways’ routing and the internal firewalls/NAT rules:

  • “Interesting traffic” doesn’t match the actual source/destination addresses.
  • Firewall policies block packets that arrive from the tunnel.
  • NAT behavior changes the observed IP addresses, breaking the rules that expect specific addressing.
  • Asymmetric routing (traffic returning via a different path) can confuse stateful firewalls.

Address overlap pitfalls

If Site A and Site B both use the same private IP ranges (for example, both use 192.168.1.0/24), you may see confusing results: devices may reach the wrong side, or return traffic may be misrouted. The safer design is unique, non-overlapping address ranges per site.

Operational uncertainty

Different VPN implementations (and different configurations within the same vendor) vary in behavior such as session handling, reconnection logic, and performance. Without specifics about the gateways and configuration, you should treat performance and stability expectations as uncertain.

Practical checks before and after enabling the tunnel

The goal of the checks below is to confirm that encryption works and, more importantly, that routing and packet handling behave as intended for a DSL environment.

1) Confirm IP plan and “interesting traffic”

  • Verify that each site’s internal IP ranges are unique and do not overlap.
  • Ensure both gateways agree on which subnets are routed through the tunnel.
  • Check that firewalls allow inbound VPN traffic and the forwarded application traffic.

2) Validate reachability step by step

Use a staged validation approach:

  • Test basic reachability of the gateways over the DSL/public side.
  • Then test reachability from Site A hosts to the Site B network (not just the gateway-to-gateway path).
  • If it fails, isolate whether the failure is in tunnel establishment, decryption/decapsulation, or internal routing/firewall processing.

3) Check routing direction and return path

Look for routing mismatches:

  • Make sure Site B’s internal devices know how to reach Site A’s subnets via Site B’s gateway.
  • Ensure return traffic doesn’t get redirected to the wrong interface.
  • On stateful firewalls, confirm that traffic is allowed in both directions consistent with the connection tracking model.

4) Monitor stability and performance characteristics

For DSL, monitor tunnel stability during typical conditions:

  • Observe whether the tunnel stays up or frequently renegotiates.
  • Track latency and any noticeable application slowdowns.
  • If performance is poor, consider that VPN overhead may be the limiting factor more than the DSL line speed itself.

Site-to-site VPN vs. other options (and when it matters)

Sometimes a full site-to-site VPN is more than you need. The “right” choice depends on how many users or devices need inter-site access and how the sites are connected.

In broad terms:

  • If only a few remote clients need access, client-based VPN or remote access approaches may be simpler.
  • If entire subnets at two sites must communicate consistently, site-to-site is often the more natural fit.

For DSL connections, the deciding factor is usually operational complexity and performance sensitivity. If your application traffic is latency-sensitive (for example, certain real-time voice/video interactions), the added overhead from the tunnel may matter more. If traffic is mostly transactional or bulk transfers, the trade-off may be acceptable—again depending on your specific DSL line quality and the gateway configuration.

Key exception that can change the outcome

The single most common exception that changes what works is IP addressing overlap combined with routing/firewall assumptions. If both sites use overlapping address ranges or NAT changes addresses in unexpected ways, you may need redesign steps; otherwise, troubleshooting can become significantly harder.

Control-checklist for clarity (afvinkpunten)

  • Unique internal IP ranges at Site A and Site B, or a documented plan for handling overlap. - Agreed subnet definitions (“interesting traffic”) on both VPN gateways.