01 IPsec and IKE (Phases, SAs and Selectors)
IPsec is a set of protocols that encrypts and authenticates IP traffic between two points. IKE is the protocol that negotiates IPsec’s parameters and keys. Keeping the two apart explains almost every site-to-site tunnel failure: something fails while negotiating (IKE) or while carrying the traffic (ESP).
Contenido complementario
Not covered in my courses. Verified against the RFCs listed in Sources. Commands are in IPsec Fundamentals (Palo Alto), IPSec - Configuración (Cisco) and Non-Meraki VPN Peers (IPsec) (Meraki).
The two data protocols
- ESP (IP protocol 50): encrypts and authenticates the payload. This is the one used in practice.
- AH (IP protocol 51): authenticates only, no encryption. Rarely used, and it does not pass through NAT.
- Tunnel mode: the whole original packet is encapsulated behind a new IP header. This is the mode used by site-to-site VPNs.
- Transport mode: only the payload is protected; used end to end between two hosts.
IKE: two phases
| Phase 1 (IKE SA) | Phase 2 (IPsec SA / Child SA) | |
|---|---|---|
| What it builds | A secure control channel between the peers | The tunnels that encrypt the real traffic |
| What it negotiates | Encryption, hash, DH group, authentication (PSK or certificates), lifetime | ESP encryption and hash, PFS, lifetime, which traffic is protected (selectors) |
| Ports | UDP 500 (UDP 4500 with NAT-T) | Inside the phase 1 channel |
An SA (Security Association) is a one-way agreement identified by an SPI. That is why a tunnel has at least two data SAs (one per direction).
IKEv1 vs IKEv2
| IKEv1 | IKEv2 | |
|---|---|---|
| Initial messages | Main mode: 6 + Quick mode: 3 | 4 (IKE_SA_INIT ×2 + IKE_AUTH ×2) |
| Phase 1 modes | Main (protects identities) and Aggressive | A single exchange flow |
| Selectors per SA | One source/destination pair | Can be lists of ranges (narrowing) |
| NAT-T | Extension | Built in |
| Dead peer detection | DPD (extension) | Built-in liveness check |
| Authentication | PSK or certificates | PSK, certificates, EAP |
Same word, different behavior
Even though the IKEv2 standard allows several subnets per SA, some devices keep the IKEv1 limit (one pair per SA). That difference is a real cause of “only one subnet works” between different vendors.
Selectors (traffic selectors / proxy IDs)
They are the list of subnets (source and destination) that each SA protects. For phase 2 to come up, the selectors on one side must be compatible with the other side’s. On policy-based devices they are written by hand; on route-based devices they are usually 0.0.0.0/0 ↔ 0.0.0.0/0 and the routes decide what enters the tunnel (see 02 - Policy-based vs Route-based VPN).
How IKEv2 negotiates selectors (RFC 7296 §2.9)
- Each Traffic Selector payload carries one or more selectors, each with an address range, a port range and an IP protocol.
- The responder may narrow what was proposed, but may not return an empty set.
- If nothing proposed is acceptable, it answers
TS_UNACCEPTABLE. If it accepts only one pair, it can answerSINGLE_PAIR_REQUIRED(this explains why some devices “accept only one pair” in IKEv2 as well). - When rekeying, a new Child SA cannot have narrower selectors than the original one (§2.9.2).
IKEv1 modes and messages (RFC 2409)
- Main mode: 6 messages; protects the peers’ identities.
- Aggressive mode: 3 messages; with PSK it does not protect the identities.
- Quick mode (phase 2): 3 messages; negotiates the data SAs and, optionally, the client identities (
IDci/IDcr, the equivalent of proxy IDs). Without them, the identities are the peers’ IP addresses. - PFS: basic Quick mode doesn’t provide it; you get it by including a Diffie-Hellman exchange (KE) in phase 2.
Lifetimes and rekey
- IKEv1: the initiator proposes the lifetime and the responder cannot modify the attributes of the offer; it can only choose among the offered transforms.
- IKEv2: the lifetime is not negotiated; “each end of the SA is responsible for enforcing its own lifetime policy” (RFC 7296 §2.4 and §2.8). Whichever side expires first starts the rekey.
- In practice: even though the protocol tolerates different lifetimes, in production you should match them, because a mismatch is a known cause of periodic tunnel drops (see Troubleshooting VPN Meraki).
NAT-T and dead peer detection
- NAT-T (RFC 3948): ESP is encapsulated in UDP 4500. AH was left out of the specification because it protects the outer IP addresses and conflicts with NAT. A keepalive is a UDP packet with a single
0xFFbyte, used only to keep the NAT mapping alive. - In IKEv2 both peers send
NAT_DETECTION_SOURCE_IPandNAT_DETECTION_DESTINATION_IPinIKE_SA_INIT; if the hashes don’t match there is NAT, and the initiator moves to UDP 4500 (§2.23). - DPD (IKEv1, RFC 3706): announced with a vendor ID; it does not send probes on a fixed schedule, only after idle time when outbound traffic gets no answer. In IKEv2 an empty
INFORMATIONALmessage works as the liveness check (§2.4).
Related notes
- NAT-T, DPD, PFS and lifetimes on Palo Alto: IPsec Fundamentals.
- Cisco equivalent: IPSec - Configuración.
- Tunnels between vendors: IPsec PA a Cisco and IPsec PA a Meraki (IKEv1 y proxy IDs).
Self-check
Q1 — What is the minimum number of data SAs in an IPsec tunnel?
A) 1, because it is a single tunnel
B) 2, one per direction
C) 4, one per phase and per direction
D) It depends only on the lifetime
Respuesta
B. IPsec SAs are one-way, so a pair of peers needs at least one inbound and one outbound SA. A) False: one logical tunnel means two SAs. C) False: phase 1 is a separate control SA. D) False: the lifetime only sets when it is renegotiated.
Q2 — Which protocol and port does NAT-T use to cross NAT?
A) Plain ESP, protocol 50
B) AH over UDP 500
C) ESP encapsulated in UDP 4500
D) GRE over TCP 443
Respuesta
C. NAT-T encapsulates ESP in UDP 4500 so the NAT device can translate ports. A) False: plain ESP has no ports and NAT breaks it. B) False: AH does not pass through NAT. D) False: GRE is not part of IKE/NAT-T.
Q3 — How many messages does IKEv2 need to build the IKE SA and the first Child SA?
A) 2
B) 4
C) 6
D) 9
Respuesta
B. IKE_SA_INIT (2 messages) and IKE_AUTH (2 messages). D) is the typical IKEv1 total with Main mode (6) + Quick mode (3). C) is Main mode only.
Q4 — Phase 1 comes up but phase 2 fails with a selector error. What do you check first?
A) The PSK
B) The phase 1 DH group
C) That the protected subnets match on both sides, including the mask
D) The PAN-OS version
Respuesta
C. Phase 1 already authenticated the peers; what fails is selector compatibility. A) False: if the PSK were wrong there would be no phase 1. B) False: the phase 1 DH was already negotiated. D) False: the version is not the typical cause.
Q5 — In IKEv2, what happens to SA lifetimes?
A) They are negotiated and the lowest wins
B) The initiator sets them and the responder must accept them
C) They are not negotiated: each side enforces its own and whichever expires first rekeys
D) They are always 8 hours
Respuesta
C (RFC 7296 §2.4 and §2.8). A) and B) describe behavior the IKEv2 standard doesn’t have. D) is a default on some products, not a protocol rule.
Q6 — An IKEv2 responder receives selectors that are too broad and accepts only one subnet pair. Which message can it return?
A)
AUTHENTICATION_FAILED
B)SINGLE_PAIR_REQUIRED
C) AlwaysNO_PROPOSAL_CHOSEN
D) Nothing, it silently drops the packet
Respuesta
B. It is the notification the standard defines when only one pair is accepted (§2.9). A) means an authentication failure, not a selector problem. C) is what some devices that reject narrowing send, but it is not the only answer. D) is not standard behavior.