IPsec site-to-site VPN tunnels encrypt traffic between geographically separated networks over untrusted paths like the public internet. Unlike remote access VPN that serves individual users, site-to-site VPN connects entire subnets — branch office LANs to headquarters data centers, cloud VPCs to on-premises networks, or partner extranets with controlled reachability. Correct IKE configuration, cipher selection, and redundancy design determine whether tunnels provide transparent connectivity or become a source of intermittent failures that resist diagnosis for months.
Internet Key Exchange negotiates security associations that define how IPsec transforms encrypt, authenticate, and encapsulate packets. IKEv2 supersedes IKEv1 in modern deployments with fewer round trips during establishment, built-in NAT traversal, and more graceful handling of address changes. Configure IKEv2 unless legacy equipment absolutely requires IKEv1 — the operational benefits outweigh compatibility concerns in nearly all current hardware generations.
IKE and IPsec Phases
IKE phase one establishes a secure channel between VPN gateways using a pre-shared key or certificate authentication. This IKE SA protects subsequent negotiation messages. IKE phase two creates the actual IPsec SAs that encrypt data traffic, defining encryption algorithm, integrity method, Diffie-Hellman group, and lifetime. Multiple phase-two SAs can exist within a single phase-one relationship when different traffic selectors require distinct policies.
Traffic selectors — proxy IDs on Cisco platforms, traffic endpoints on others — define which subnet pairs the tunnel carries. Mismatched selectors are the leading cause of tunnels that establish successfully but pass no traffic. Both sides must agree on local and remote subnet definitions. When one side uses 0.0.0.0/0 as a summary, the other must either match or use compatible supernet definitions depending on platform behavior. Document every selector pair in your VPN inventory alongside peer addresses and authentication methods.
Cipher and Authentication Selection
Use AES-256-GCM for encryption and authentication in a single combined operation. Avoid legacy AES-CBC with separate HMAC-SHA1 integrity unless required for interoperability with aging peers. Diffie-Hellman group 19 or higher provides adequate key exchange strength — groups 1, 2, and 5 are deprecated and vulnerable to precomputation attacks. Enable perfect forward secrecy by rekeying with fresh DH exchanges rather than reusing key material across sessions.
Pre-shared keys suffice for small deployments but scale poorly — every tunnel pair needs a unique key, and rotation requires coordinated changes on both sides. Certificate-based authentication with a private PKI scales to hundreds of tunnels with automated enrollment and revocation. Store PSKs in a secrets vault with access logging, never in plaintext configuration repositories. IKEv2 supports EAP and MOBIKE for specialized mobile scenarios but site-to-site designs typically use certificate or PSK authentication exclusively.
Topology Patterns
Hub-and-spoke places VPN concentrators at headquarters with branch offices connecting as spokes. Spoke-to-spoke traffic hairpins through the hub unless direct spoke tunnels are added. Hub-and-spoke simplifies policy management and monitoring but increases latency and hub bandwidth requirements for inter-branch communication. Full mesh connects every site to every other site — appropriate for three to five high-traffic locations but becomes operationally unwieldy beyond that count.
Partial mesh connects high-traffic site pairs directly while routing other traffic through hubs. Cloud VPN designs often use a cloud gateway as hub with on-premises sites as spokes, or leverage cloud-native VPN services that scale horizontally. Always configure dead peer detection so gateways detect peer unreachability and attempt reestablishment without waiting for traffic to trigger negotiation. DPD intervals of ten to thirty seconds balance responsiveness against control-plane overhead.
MTU, Fragmentation, and Performance
IPsec adds header overhead — typically fifty to sixty bytes depending on mode and algorithms. Packets exceeding the path MTU after encapsulation fragment at the tunnel endpoint or blackhole if DF bit is set. Set tunnel interface MTU explicitly, commonly 1400 bytes for internet paths, and enable TCP MSS clamping on the firewall to prevent endpoints from sending segments too large for the tunnel. MSS clamping at 1360 bytes on the encrypted interface resolves most fragmentation-related application failures.
Throughput depends on encryption hardware acceleration. Verify that VPN gateways use AES-NI or dedicated crypto ASICs rather than software encryption that caps throughput far below line rate. For high-bandwidth links, benchmark actual encrypted throughput before committing to a platform. Some designs place routing on firewalls and accept throughput limits; others use dedicated VPN concentrators or SD-WAN appliances optimized for encrypted tunnel performance at scale.
Redundancy and Failover
Dual ISP links at branch offices require either two tunnels to the same hub with routing protocol failover or SD-WAN overlay management of multiple underlay paths. Configure IKE keepalives and track tunnel interface state in your IGP or static routing so traffic fails over within seconds of primary tunnel loss. Test failover quarterly by physically disconnecting primary ISP circuits during maintenance windows and verifying application continuity.
Monitor tunnel uptime, phase-one and phase-two rekey events, bytes encrypted, and error counters. Alert on tunnel down conditions before users notice. Log IKE negotiation failures with sufficient detail to distinguish authentication errors, selector mismatches, and peer unreachability without enabling verbose debug in production. IPsec site-to-site VPN remains the workhorse of hybrid connectivity — designed with modern ciphers, correct MTU handling, and tested redundancy, it provides years of reliable encrypted transport between sites.
Cloud VPN Integration
Cloud provider VPN gateways — AWS VGW, Azure VPN Gateway, GCP Cloud VPN — terminate IPsec with specific parameter requirements documented per platform. Cipher proposals, DH groups, and PFS settings must match cloud-side constraints or phase one negotiation fails with cryptic logs on the on-premises side blaming the peer. Use cloud-documented transform sets as the starting point rather than your standard corporate IPsec template.
BGP over IPsec tunnels to cloud gateways enables dynamic route exchange replacing static routing that breaks during CIDR changes. Configure BGP MD5 authentication where supported and prefix filtering on both sides preventing route leaks in either direction. Monitor BGP session state alongside tunnel state — a healthy tunnel with down BGP advertises no routes, producing blackholes identical to a down tunnel from the application's perspective.
Active-active VPN designs with multiple tunnels to the same cloud gateway require careful asymmetric routing management. Equal-cost multipath across tunnels distributes flows but may reorder packets causing TCP performance issues. Policy-based routing pinning specific traffic classes to specific tunnels maintains flow symmetry at the cost of suboptimal load distribution — evaluate per application requirement.