What a site-to-site VPN is

A site-to-site VPN is a connection between two separate networks (for example, a company office network and a data center network) that provides encrypted transport over an intermediate network like the public internet. Instead of creating individual user sessions, the tunnel is established between gateways (VPN devices or services), and the gateways forward traffic for selected internal IP ranges.

A simple setup model (the checklist)

To set up a site-to-site VPN, treat the job as four linked decisions: (1) tunnel endpoints, (2) interesting networks (subnets), (3) tunnel protection settings, and (4) how traffic is routed and allowed.

  1. Choose the tunnel endpoints Select the two VPN gateway devices that will talk to each other. Each side must know where the other gateway is reachable (typically by IP address) so the gateways can negotiate and maintain the tunnel.

  2. Define the internal networks that should be reachable On each side, specify the “local” subnet(s) that exist behind that endpoint and the “remote” subnet(s) that should be reachable through the VPN. This prevents unnecessary exposure and avoids routing loops.

  3. Configure matching security parameters Both gateways must agree on the cryptographic and authentication approach used to protect the tunnel. In practice, you set items like: the tunnel type, encryption and integrity settings, and how peers authenticate (for example, pre-shared keys or certificates—exact options depend on the gateway).

  4. Make routing and firewall rules line up After the tunnel is up, traffic still needs to be correctly forwarded. Ensure that each gateway has routes for the remote subnets via the VPN tunnel, and that firewalls permit the traffic that must traverse the tunnel (including the required inbound rules for the VPN itself).

Differences and common limits to plan for

A few aspects can change the outcome even when the high-level steps look similar:

  • Site-to-site vs. remote-access: If you are connecting individual users/clients, you typically need a remote-access VPN model. For site-to-site, you configure gateway-to-gateway connectivity and internal subnet forwarding.
  • Which subnets you publish matters: Broad “allow all” subnet definitions often cause unexpected reachability and troubleshooting complexity. Restrict the permitted local/remote ranges to what you actually need.
  • NAT and overlapping IP ranges: If both sites use the same private IP ranges, routing and reachability can break unless the design accounts for it (for example, by renumbering, using translation, or other gateway-supported mechanisms). Similarly, NAT placement (on the way in/out of the VPN) can affect how return traffic is handled.
  • Routing asymmetry: If one side sends traffic into the VPN but return traffic leaves through a different path, connections may fail. Your routing choices must keep request and response traffic consistent.

Practical use: what to verify during setup

If you are checking your configuration, use validation steps that match the four decisions above:

  1. Confirm both gateways can reach each other’s public-facing addresses used for tunnel negotiation.
  2. Verify the “local” and “remote” subnet selections are correct and non-overlapping (or intentionally handled).
  3. Check that tunnel security settings match on both sides (auth method and cryptographic settings).
  4. Ensure both gateways have routes for the remote subnets via the VPN and that firewall policies permit: (a) tunnel establishment traffic and (b) the forwarded application traffic between the intended internal ranges.

If anything fails, treat it as a mismatch in one of those areas: reachability to endpoints, disagreement about what networks are “interesting,” security parameter mismatch, or routing/firewall inconsistency.