A Site-to-Site VPN (Virtual Private Network) is a technology that allows a company to securely connect two geographically separated office networks together over the public Internet. Once connected, computers in the Headquarters (HQ) can communicate directly with computers in the Branch office just as if they were plugged into the same physical switch.
The Concept of the Encrypted Tunnel
If HQ sends unencrypted private data across the internet to the Branch, anyone intercepting the traffic (like an ISP or malicious actor) can read it. Furthermore, internet routers will drop packets destined for private IP Addresses like 192.168.x.x.
A Site-to-Site VPN solves this by creating an Encrypted Tunnel between two VPN Gateways (usually the edge firewalls).
- When a PC at HQ sends a packet to the Branch, the HQ firewall intercepts it.
- The HQ firewall encrypts the entire original packet, wraps it inside a brand new packet addressed to the Branch firewall's Public IP, and sends it across the internet.
- The Branch firewall receives the packet, decrypts it, un-wraps the original private packet, and forwards it to the Branch PC.
How IPsec VPNs Work (Phase 1 & Phase 2)
The vast majority of enterprise site-to-site VPNs rely on a suite of protocols called IPsec. Establishing an IPsec tunnel occurs in two distinct phases:
Phase 1 (IKE / ISAKMP) - Building the Secure Channel
Before any data can be transferred, the two firewalls must verify each other's identities. They negotiate encryption algorithms (e.g., AES-256) and authenticate using a Pre-Shared Key (a long password) or digital certificates. If successful, they establish a secure control channel.
Phase 2 (IPsec SA) - Building the Data Tunnel
Inside the secure Phase 1 channel, the firewalls negotiate the parameters for actually sending user data. They define the Interesting Traffic—which local subnets are allowed to talk to which remote subnets. If both firewalls agree on the subnets and encryption settings, the Phase 2 tunnel comes up, and data can flow.
Route-Based vs Policy-Based VPNs
Vendors handle VPN traffic routing in two different ways:
- Policy-Based: The VPN requires explicit ACLs (e.g., "Encrypt traffic from 192.168.1.0/24 going to 10.10.10.0/24"). If the traffic matches the policy, it enters the tunnel. This is common in older Cisco ASA configurations.
- Route-Based: The VPN tunnel is treated as a virtual network interface (like
tunnel0). The administrator simply adds a standard Static Route pointing the remote subnet to the tunnel interface. This is modern, highly flexible, and standard on Palo Alto, Fortinet, and AWS.
| Symptom | Common Causes & Troubleshooting |
|---|---|
| Phase 1 Fails (Tunnel completely down) | Mismatched Pre-Shared Key. Public IPs are incorrect. Mismatched IKE proposals (e.g., one side uses SHA1, the other SHA256). ISP is blocking UDP Port 500. |
| Phase 1 Up, Phase 2 Fails | The local and remote subnets configured on each side do not perfectly mirror each other. Mismatched Phase 2 encryption proposals. PFS (Perfect Forward Secrecy) mismatch. |
| Phase 1 & 2 Up, but No Traffic Flows | Missing Routing pointing to the tunnel. Missing Firewall Policies allowing the two zones to communicate. NAT rules are accidentally translating the VPN traffic out to the internet instead of letting it pass through the tunnel. |
Common Design Problems: Overlapping Subnets
The most devastating mistake when building a VPN is when both the HQ and the Branch happen to use the same internal subnet (e.g., 192.168.1.0/24). When a PC at HQ tries to ping a server at the Branch, the HQ router looks at the destination (192.168.1.x), assumes it's on the local LAN, and refuses to send the packet across the VPN.
This is why enterprise network engineers must carefully document and allocate unique IP blocks to every site, avoiding default router blocks like 192.168.1.x entirely.
Best Practices
- Document Networks: Maintain an IP address management (IPAM) spreadsheet to ensure no two branch offices ever use the same subnet.
- Monitor Tunnel Health: Configure network monitoring tools to alert you if Phase 1 drops, as VPNs can fail silently without users noticing immediately.
- Use Strong Crypto: Avoid deprecated algorithms like DES, 3DES, or MD5. Use AES-256 and SHA-256 or higher, provided both firewalls support hardware acceleration.