What a site-to-site VPN is

A site-to-site VPN is a secure connection between two network locations (for example, an office network and a datacenter network). Instead of securing one device, it typically connects whole networks by creating encrypted “tunnels” that carry traffic from one side to the other.

In practical terms, this means computers and systems in Site A can reach allowed resources in Site B over an encrypted path, as if the two networks were directly connected—while still passing through the public internet or another untrusted transport.

How site-to-site VPN works (the core flow)

Site-to-site VPNs rely on two main ideas: encryption of data in transit and controlled establishment of the tunnel.

First, the VPN endpoints (commonly gateway devices such as routers or dedicated appliances) negotiate the tunnel parameters. This usually includes:

  • Authentication: confirming that the right endpoint is talking to the tunnel.
  • Key exchange: generating session keys used for encryption.
  • Negotiation of security settings: agreeing on protocols and algorithms.

Second, once the tunnel is established, traffic matching the configured “interesting” networks is encapsulated and sent to the remote gateway. The remote gateway decapsulates the traffic and forwards it to the appropriate internal destination.

Benefits: when site-to-site VPN is useful

1) Secure connectivity between locations

The main benefit is confidentiality and integrity for traffic traveling between the two sites. When configured correctly, sensitive internal communication (such as application traffic or internal service calls) is protected over the transport network.

2) Centralized network access patterns

Because entire networks are connected, you can simplify reachability for multiple devices and services at once. This can reduce the need to configure per-device access methods.

3) Consistent routing and policy enforcement

With gateway-to-gateway tunnels, you can apply network rules at the edges: which subnets are reachable, which ports and protocols are allowed, and how traffic is forwarded once it arrives.

4) Useful for hybrid and multi-environment setups

Organizations often use site-to-site VPNs to connect on-prem networks with cloud networks or to link multiple internal environments where direct private connectivity is not available or is too costly to deploy immediately.

Differences and limits: what can change the outcome

Not the same as user remote access

Site-to-site VPN is designed for network-to-network connectivity. If your requirement is “secure access for individual employees from anywhere,” that is usually handled with a different approach (commonly remote-access VPN or client-based access). Mixing the purposes can lead to avoidable complexity.

Routing and subnet design determine what actually works

Even with an established tunnel, traffic may not flow if routing is incorrect. Common issues include:

  • Overlapping IP address ranges (both sides use the same subnet), which makes it unclear where packets should go.
  • Missing static routes or incorrect dynamic routing configuration on one or both gateways.
  • Firewall rules that block the required traffic after it enters the tunnel.

Encryption does not automatically guarantee performance

Encryption and encapsulation add overhead. Real throughput depends on factors like endpoint CPU capacity, tunnel settings, link capacity, and overall latency. As a result, site-to-site VPNs can be “working” but still not meet performance expectations.

Reliability depends on the entire path

Tunnel stability can be affected by internet path changes, NAT behavior, firewall policies, and endpoint configuration. If the tunnel renegotiates frequently, traffic will be intermittent.

Practical checks and troubleshooting checklist

Use these verification steps to confirm the VPN is correctly set up for the intended networks and traffic:

1) Confirm the tunnel state

Check whether the VPN tunnel is actually established and stable on both gateways. Many systems provide status indicators and counters for negotiations and rekey events.

2) Validate routing for the target subnets

From each site, verify that routes exist for the remote networks via the VPN tunnel. If you cannot reach a host, confirm whether the packet is being forwarded into the tunnel at the source and whether the destination subnet is reachable on the remote side.

3) Verify firewall and policy rules

Even with a working tunnel, internal firewalls and security groups can block traffic. Confirm that the required ports/protocols are allowed in the relevant inbound and transit paths.

4) Check DNS and name resolution

If applications use hostnames rather than raw IP addresses, ensure DNS queries resolve to the correct remote addresses and that the DNS traffic itself is reachable as intended.

5) Inspect logs for errors

Look for authentication failures, negotiation mismatches, route misses, or drop counters that indicate where traffic is being rejected.

6) Re-run the test with representative traffic

Test with the same protocol and ports your applications require (not just ping or a single service). This helps reveal policy and MTU-related issues that only appear under real workloads.

  • Gateway device vs. tunnel endpoint: The device that terminates the tunnel is what other systems “see” at the edge.
  • Traffic selectors / allowed subnets: The configuration that defines which networks and flows are sent through the tunnel.
  • MTU and packet sizing: Encapsulation overhead can affect packet sizes; misalignment can cause fragmentation or drops in some environments.
  • Alternative connectivity: Depending on requirements, organizations may choose direct private links or client-based VPN approaches instead of site-to-site.

Because terminology and feature support vary by vendors and environments, treat any specific behavior as configuration-dependent and validate it against your own gateway capabilities and network design.