IPsec is not a protocol but a framework of them, standardised so that two devices from different vendors can build a cryptographically protected path across a hostile network. Grasp its architecture — who negotiates, what a security association is, where the encryption actually happens — and every vendor's VPN configuration becomes the same five decisions wearing different syntax.
The vocabulary
- Security Association (SA) — a one-way contract: 'traffic in this direction uses these algorithms with these keys, identified by this SPI'. Every IPsec tunnel is at least a pair of SAs, one per direction, with lifetimes after which they re-key.
- IKE (Internet Key Exchange, UDP 500) — the negotiator: authenticates the peers, performs Diffie–Hellman, and derives all keys. IKEv2 (RFC 7296) is the current, cleaner protocol — fewer messages, built-in NAT traversal and keepalives, EAP support; IKEv1's main-mode/aggressive-mode machinery survives only in legacy configs.
- ESP (IP protocol 50) — carries the protected data: encryption plus integrity, today usually combined in AES-GCM. AH (protocol 51) offers integrity without encryption and is effectively historical.
- NAT-T — ESP has no ports, so NAT breaks it; NAT traversal detects this during IKE and re-wraps ESP in UDP 4500.
The two phases
Phase 1: the peers authenticate each other — pre-shared key or certificates — run Diffie–Hellman, and establish the IKE SA: an encrypted control channel for everything that follows. Phase 2 (IKEv2 calls the exchange CREATE_CHILD_SA): under that protection, they negotiate the IPsec SAs — proposal (say, ESP with AES-256-GCM), the traffic each SA covers, optional fresh DH for perfect forward secrecy — and install them into hardware. Data then flows under ESP with no further IKE involvement until lifetime or dead-peer-detection events. The phases fail differently, which is the diagnostic gift: no IKE SA means reachability, UDP 500/4500, or authentication (mismatched PSK); an IKE SA without IPsec SAs means proposal or traffic-selector mismatch; SAs up with encrypt counters rising and decrypt at zero means one-way transport — usually the return path or NAT.
R1# show crypto ikev2 sa Tunnel-id Local Remote Status 1 203.0.113.1/500 198.51.100.9/500 READYR1# show crypto ipsec sa | include pkts|spi #pkts encaps: 84213, #pkts decaps: 83907 current outbound spi: 0x4A3B1C22
Tunnel mode, transport mode, and the modern shape
Tunnel mode encrypts the entire original packet and adds a new IP header between the VPN gateways — the site-to-site default, hiding internal addressing completely. Transport mode protects only the payload, keeping the original header — meaningful mainly for host-to-host traffic and as the wrapper under GRE. That last case defines modern Cisco practice: rather than classic crypto maps matching interesting-traffic ACLs, current designs build a routed tunnel (GRE or VTI) and apply an IPsec profile to it — the tunnel interface carries routing protocols, multicast and anything else IP, while IPsec protects the tunnel wholesale. Routing over VPNs instead of ACL-matched crypto is half of what makes the next chapter's DMVPN possible.
crypto ikev2 profile SITE match identity remote address 198.51.100.9 authentication local pre-share key R5tF0rum! authentication remote pre-share key R5tF0rum!crypto ipsec profile PROT set ikev2-profile SITEinterface tunnel1 tunnel destination 198.51.100.9 tunnel protection ipsec profile PROT
Baseline choices for anything built today: IKEv2, AES-GCM, DH group 19 or higher, certificates over PSKs where scale permits, PFS on, and MTU respected — ESP adds bytes, and an unclamped TCP MSS through a tunnel is the most reliably recurring VPN ticket in existence.