Site-to-Site vs Remote-Access VPN
The distinction matters because they solve different problems. A remote-access VPN connects individual devices — a laptop, a phone — to a network. The VPN runs on the device, and only that device's traffic enters the tunnel. A site-to-site VPN connects entire networks through gateways. No individual device needs a VPN client; the gateways handle the tunnel automatically, and any device on either network can reach resources on the other as if they were local.
This makes site-to-site VPNs the right tool when you need persistent, transparent connectivity between locations — not occasional device-level access.
How the Architecture Works
Each location needs a VPN gateway: typically a router, firewall appliance, or dedicated server running VPN software (WireGuard, IPsec/IKEv2, OpenVPN, or a cloud provider's native gateway). The gateways authenticate to each other using certificates or pre-shared keys, establish an encrypted tunnel, and then handle routing. Once the tunnel is up, each gateway needs to know which traffic to route into it — traffic destined for the remote subnet goes into the tunnel; everything else goes to the normal internet gateway.
Subnet Planning: The Most Important Step
Overlapping subnets are the most common cause of site-to-site VPN failure. If both locations use 192.168.1.0/24 — which is the default on most consumer routers — the routing table cannot distinguish local traffic from remote traffic, and the tunnel cannot function correctly. Plan subnets before building the tunnel:
| Location | Example Subnet | VPN Gateway IP | Routes Advertised to Remote |
|---|---|---|---|
| Home | 192.168.10.0/24 | 192.168.10.1 | 192.168.10.0/24 |
| Office | 10.20.0.0/24 | 10.20.0.1 | 10.20.0.0/24 |
| Cloud VPC (AWS/GCP) | 172.16.0.0/24 | Cloud gateway | 172.16.0.0/24 |
Protocols for Site-to-Site VPN
| Protocol | Strengths | Common Use Cases |
|---|---|---|
| WireGuard | Fast, simple config, low CPU overhead, excellent for fixed tunnels | Home lab to cloud, small office links, self-hosted setups |
| IPsec/IKEv2 | Widely supported, compatible with hardware firewalls and cloud gateways | Enterprise branch links, Azure/AWS VPN Gateway, Cisco/Palo Alto |
| OpenVPN | Flexible, works through firewalls, mature | Legacy enterprise, when WireGuard is not supported on the appliance |
| Cloud-native (AWS Site-to-Site, Azure VPN) | Managed service, HA options, monitored | Connecting on-premises networks to cloud VPCs |
Firewall Rules and the Tunnel-Connected Illusion
The most common troubleshooting scenario is a tunnel that reports "connected" while no traffic actually passes. The tunnel status shows the handshake succeeded, but nothing can reach the other side. This almost always means the problem is firewall policy, routing, or NAT — not the VPN itself. Check these in order:
- Routes: verify that both gateways have routes pointing to the remote subnet via the VPN interface.
- Firewall policies: most firewalls require explicit allow rules for tunnel traffic. A "deny by default" policy blocks traffic even if the tunnel is established. Create rules permitting the specific subnets and ports you need.
- NAT: if NAT is applied to traffic before it enters the tunnel, the remote side sees traffic sourced from the gateway's IP rather than the originating device's IP. Disable NAT on VPN-bound traffic, or configure NAT exemptions.
- Overlapping subnets: if both sides accidentally share a subnet, routing will prefer the local path over the tunnel for that range.
Test sequentially: ping, then TCP ports, then the actual application. If ping works but the application does not, the problem is application-layer firewall rules, not routing.
Frequently Asked Questions
Do I need static IP addresses on both sides?
Static IPs simplify configuration because the peer address never changes. Dynamic DNS (DDNS) works as a substitute when one or both sides have dynamic IP addresses — the gateway uses the DDNS hostname instead of a fixed IP and updates the DNS record when its IP changes. The more challenging case is both sides being behind CGNAT (carrier-grade NAT), where neither side has a public IP. This requires an intermediary relay server or cloud-based gateway to broker the connection. For home labs connecting to cloud resources, the cloud side almost always has a fixed IP, so only the home side needs DDNS.
When should I use a mesh VPN instead of site-to-site?
Site-to-site VPN makes sense when you control the gateway on both sides and want transparent network-level connectivity. Mesh VPNs like Tailscale or ZeroTier are better when devices move between networks, you want to connect individual machines rather than full subnets, you are behind CGNAT and cannot configure gateways, or you want a managed control plane that handles key distribution and peer discovery automatically. For a home lab connecting to a cloud VM, Tailscale is typically faster to set up and maintain — the trade-off is that Tailscale's control plane is a third-party service.
How do I verify traffic is using the tunnel?
Run a traceroute from the originating device to a resource on the remote subnet. If the first hop goes to your local gateway and subsequent hops reach the remote subnet, routing is correct. Also check the VPN gateway's traffic counters — if bytes-in and bytes-out are not increasing when you send traffic across the tunnel, the traffic is not reaching the gateway interface at all, pointing to a routing problem before the VPN layer.