site to site IPsec, build the tunnel step by step

two offices, one network, zero trust in the internet between them

picture two branch offices. one in denver, one in atlanta. both have their own private lan, their own printers, their own servers that shouldn't ever be exposed to the raw internet. you want someone in denver to hit a file server in atlanta like it's down the hall. the only path between them is the public internet, which is basically a room full of strangers. site to site ipsec is how you make that room irrelevant. you build an encrypted tunnel between the two edge devices, usually a pair of firewalls or asas, and everything that crosses it gets wrapped up so tight that anyone sniffing traffic in between just sees noise.

this post is about understanding how that tunnel actually gets built, so when you're the one defending it, you know exactly what "the vpn is down" or "the vpn got popped" actually means.

phase 1: building the secure handshake

before any real data moves, the two devices need to trust each other and agree on how to talk privately. that's ike phase 1, internet key exchange. think of it as two strangers meeting, verifying identity, and agreeing on a shared secret language before they say anything sensitive out loud.

during phase 1 the two peers negotiate:

encryption algorithm (aes-256, not des, please)
hash algorithm (sha-256 or better)
diffie-hellman group (for key exchange strength)
authentication method (pre-shared key or certificates)
lifetime of the negotiated channel

once they agree, they've built what's called the isakmp sa, a secure management channel. nothing useful has traveled yet. it's just the handshake and the trust.

phase 2: building the actual tunnel

with the secure channel in place, phase 2 negotiates the ipsec sa, the actual tunnel that will carry real traffic. this defines things like which traffic is "interesting" (meaning it should go through the tunnel at all, usually defined by an access list matching the two lan subnets), what encryption protects the data itself, and how often keys rotate.

this is also where esp comes in. encapsulating security payload wraps each packet in encryption and adds integrity checking, so even if someone captures the traffic mid-transit, they get encrypted garbage with no way to tamper with it undetected. once phase 2 finishes negotiating, the tunnel is live, and the two lans start acting like they're on the same switch, just with a very long, encrypted ethernet cable between them.

why ikev1 needs to be retired

ikev1 was designed in the 90s and it shows. it's clunky, it has weaker built in support for nat traversal, it lacks native support for things like eap authentication, and its aggressive mode has a well known weakness where pre-shared key hashes can be captured and cracked offline if an attacker can see the exchange. that's not theoretical, it's a documented, common misconfiguration finding in pentests.

ikev2 fixes a lot of this. it's more efficient (fewer message exchanges to establish the tunnel), it has built in dead peer detection so a dropped tunnel gets noticed and rebuilt automatically, it handles mobility and nat traversal better, and it supports stronger, more flexible authentication. if you're still running ikev1 on production gear in 2024 and beyond, that's a finding waiting to be written up.

how you check and harden your own tunnels

if you're responsible for a site to site vpn, don't just trust that it "works," actually verify the crypto being used:

show crypto isakmp sa
show crypto ipsec sa

look at what's negotiated. if you see des, 3des, md5, or dh group 1/2 anywhere in that output, that's weak crypto that needs to be phased out. push both ends to aes-256, sha-256 or sha-384, and dh group 14 or higher. if pre-shared keys are still in use, make sure they're long, random, and not something like the branch name plus a year. better yet, move to certificate based authentication if your gear supports it.

also check your access lists defining interesting traffic. an overly broad acl means more of your network is exposed through that tunnel than needs to be. scope it down to exactly the subnets that need to talk.

the takeaway

a site to site tunnel is only as strong as the weakest algorithm it's willing to negotiate. understanding phase 1 and phase 2 isn't just ccnp trivia, it's what lets you actually audit your own vpn instead of assuming the blinking green light means everything's fine. check your crypto, kill ikev1, tighten your traffic selectors, and rotate those keys. the internet in between your two sites doesn't have to be scary if you build the tunnel like you actually understand what's inside it.