IPsec: who you are, which key we use, what goes into the tunnel
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Where a parameter changes the outcome, there is a simulator where you change it yourself.
TL;DR
IPsec protects IP packets between two endpoints: it encrypts them, signs them and numbers them. It has two planes: IKE, which authenticates the peers and negotiates the keys (UDP 500, or 4500 through NAT), and ESP, which protects each packet (IP protocol 50); AH signs without encrypting and does not survive NAT. The agreements are called SAs and are unidirectional, with a lifetime and rekey. What goes into the tunnel is decided either by an ACL (crypto map) or by a tunnel interface (GRE/IPsec, VTI, DMVPN, FlexVPN), in which case routing and multicast work normally; GETVPN removes tunnels altogether, on a private WAN. Most incidents can be read straight from the IKE state and the encaps / decaps counters: mismatched policy, different PSK, non-mirrored ACLs, NAT without NAT-T, MTU.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between standards (RFC) and the Cisco implementation, or between platforms. In animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of two offices of the same company sending each other confidential documents by mail, in a box locked with a seal and a serial number, after the mail rooms agreed over the phone: who they are, what code the locks use and how often they change it. The mail carrier only sees the box and the mail room's address, not the document.
The model holds up to §11. From §12 onward (MTU, anti-replay with reordering, GETVPN with a shared lock), it stretches; see the full analogy and its limits in §16.