Definition and purpose

A site-to-site VPN is a way to connect two separate networks (for example, a company’s office network and a data center network) by creating an encrypted tunnel between them. Instead of protecting just one user device, it focuses on network-to-network communication so that devices at Site A can reach devices or services at Site B using the networks’ addressing and routing rules.

A simple model of what happens

A straightforward way to picture it:

  • Two VPN gateways (one at each site) establish a tunnel.
  • When devices send traffic from one network to the other, that traffic is routed to the local gateway.
  • The gateway encapsulates and encrypts the traffic, sends it through the tunnel, and the remote gateway decrypts and forwards it to the destination network.

This model usually relies on routing decisions (often via static routes or dynamic routing) so the gateways know which remote subnets should go through the VPN.

Main components you configure

Even when implementations differ, site-to-site VPNs typically involve:

  • VPN gateways: the endpoints that create the tunnel and enforce crypto handling.
  • Crypto/authentication settings: parameters for securing the tunnel and determining how the gateways verify each other.
  • Routing: rules that map “which remote networks should be reachable over the VPN.”
  • Firewall/security policies: rules that decide what traffic is allowed after decryption (for example, which ports or protocols can flow between subnets).

The key idea is separation of concerns: the VPN tunnel carries encrypted traffic, while firewalls and routing determine what is reachable.

Differences and important limits

Site-to-site vs. remote-access VPN

A site-to-site VPN is network-focused (gateway-to-gateway), while a remote-access VPN is user-focused (device-to-gateway). In practice, both use encryption and tunneling, but the routing and client responsibilities differ.

The tunnel is not the same as authorization

Encryption helps protect data while it travels, but it does not automatically grant access. If firewall rules on either side are restrictive (or missing), traffic may still fail—even if the tunnel is up.

Routing and addressing must match your plan

Common failure causes are mismatched subnet expectations (for example, overlapping address ranges), incorrect routes, or incomplete network reachability. If the gateways don’t agree on which networks exist where, traffic won’t reach its destination.

Performance depends on design and path

You may see latency or throughput changes due to tunnel overhead and the network path between gateways. Claims about “perfect” security or “no risk” should be treated skeptically; a correct configuration reduces exposure, but outcomes depend on implementation and operations.

Practical checks you can do

To validate your understanding (and your own setup), focus on these checkpoints:

  • Confirm both gateways can establish the VPN tunnel and agree on configuration parameters.
  • Verify routing: the local gateway should know how to reach the remote subnet(s), and the remote gateway should know the reverse.
  • Check firewall policies after decryption: ensure the allowed ports/protocols exist for the relevant subnet pairs.
  • Ensure addressing is non-overlapping or handled correctly; overlapping subnets often break site-to-site connectivity.

If you can explain those four points for your environment, you understand how a site-to-site VPN works in practice.