IKEv2 — Internet Key Exchange v2, RFC 7296, MOBIKE, EAP authentication

IKEv2 is the modern Internet Key Exchange protocol defined in RFC 7296. It replaces IKEv1 with a simpler, more efficient handshake that combines the key exchange and authentication in fewer round trips. IKEv2 also adds MOBIKE (RFC 4555) for mobile endpoints that change IP addresses (e.g., a laptop moving between networks), and supports EAP for remote-access authentication.

This lesson covers the IKEv2 handshake in detail, MOBIKE, EAP authentication, and the production benefits over IKEv1.

Why IKEv2 over IKEv1

IKEv1 had a complex, multi-step negotiation. The two phases:

• Phase 1: Main mode (6 messages) or Aggressive mode (3 messages). Main mode is more secure but slower; Aggressive mode is faster but reveals identities in cleartext.
• Phase 2: Quick mode (3 messages per ESP SA). Multiple ESP SAs require multiple Phase 2 negotiations.

The IKEv1 design has several problems:

1. Slow first-time establishment (up to 9 messages for Main mode + Quick mode).
2. Complex authentication (PSK in Aggressive mode reveals identity; certificates in Main mode require CA chains).
3. No built-in mobility support.
4. Multiple Phase 2 negotiations for multiple SAs.
5. SA pairs must be renegotiated together.

IKEv2 fixes all of these:

1. Four-message handshake (IKE_SA_INIT + IKE_AUTH). Faster first-time establishment.
2. Multiple authentication methods built-in (PSK, certificates, EAP).
3. MOBIKE (RFC 4555) for mobility. Endpoints can change IPs without renegotiating.
4. CREATE_CHILD_SA for rekeys and additional SAs (single 2-message exchange).
5. Synchronized rekey. Both peers rekey together; no half-stale SAs.

The four-message handshake

The IKEv2 handshake consists of two exchanges, totaling four messages:

sequenceDiagram
  participant I as Initiator
  participant R as Responder
  Note over I,R: IKE_SA_INIT
  I->>R: msg 1: SAi, KEi, Ni
  R->>I: msg 2: SAr, KEr, Nr, [CERTREQ]
  Note over I,R: Both sides compute:<br/>SKEYSEED, SK_e, SK_a, SK_p
  Note over I,R: IKE_AUTH (encrypted)
  I->>R: msg 3: IDi, [CERT], AUTH, [IDr], [TSi], [TSr]
  R->>I: msg 4: IDr, [CERT], AUTH, [TSi], [TSr]
  Note over I,R: IKE SA and first ESP SA established

The messages:

msg 1 (IKE_SA_INIT) — Initiator sends:

• SAi (Security Association payload with IKE proposals)
• KEi (Initiator’s Diffie-Hellman key exchange value)
• Ni (Initiator’s nonce)

msg 2 (IKE_SA_INIT) — Responder sends:

• SAr (chosen IKE proposal)
• KEr (Responder’s DH value)
• Nr (Responder’s nonce)
• Optionally CERTREQ (request for the peer’s certificate)

msg 3 (IKE_AUTH) — Initiator sends (encrypted with the derived keys):

• IDi (Initiator’s identity, e.g., IP address or ID payload)
• CERT (Initiator’s certificate)
• AUTH (authentication data, e.g., PSK signature or RSA signature)
• TSi (Initiator’s Traffic Selector — what traffic to send)
• TSr (Responder’s Traffic Selector — what traffic to receive)

msg 4 (IKE_AUTH) — Responder sends (encrypted):

• IDr (Responder’s identity)
• CERT (Responder’s certificate)
• AUTH (Responder’s authentication)
• TSi, TSr (acknowledged traffic selectors)

After msg 4, both sides have a working IKE SA (for key management) and the first ESP SA (for data encryption).

MOBIKE — mobility and multihoming

MOBIKE (RFC 4555) is an extension to IKEv2 that allows an endpoint to change its IP address without renegotiating the IKE SA. This is essential for mobile endpoints (laptops, phones) that move between networks.

Without MOBIKE:

• A laptop on Wi-Fi at the office establishes an IPsec tunnel.
• The laptop moves to LTE at home; its IP changes.
• The tunnel breaks; the laptop must renegotiate with the server, which may take 10+ seconds.
• Applications using the tunnel (e.g., a long-running TCP connection) may experience downtime.

With MOBIKE:

• The laptop sends a MOBIKE update message to the server, telling it the new IP.
• The server updates its IKE SA to use the new IP.
• The tunnel continues without renegotiation.

sequenceDiagram
  participant L as Laptop (mobile)
  participant S as Server
  Note over L,S: Initial connection via Wi-Fi (10.0.0.50)
  L->>S: IKE_SA_INIT + IKE_AUTH (MOBIKE supported)
  S->>L: IKE_AUTH response
  Note over L,S: Tunnel active
  Note over L: Laptop moves to LTE (192.0.2.50)
  L->>S: MOBIKE update (new IP 192.0.2.50)
  S->>S: Update IKE SA routing
  Note over L,S: Tunnel continues with new IP

MOBIKE is supported by most modern IKEv2 implementations. For remote-access deployments with mobile endpoints, MOBIKE is essential.

EAP — Extensible Authentication Protocol

IKEv2 supports EAP (RFC 3748) as an authentication mechanism. EAP allows the IKEv2 authentication to use external authentication systems (LDAP, RADIUS, certificates, tokens). This is essential for large-scale remote-access deployments where each user has individual credentials.

The flow with EAP:

sequenceDiagram
  participant C as Client
  participant S as Server
  participant A as Authentication backend<br/>(RADIUS, LDAP, etc.)
  Note over C,S: IKE_SA_INIT
  C->>S: msg 1
  S->>C: msg 2
  Note over C,S: IKE_AUTH (extended)
  C->>S: msg 3: IDi, SA, TSi, TSr
  Note over S: Server initiates EAP<br/>(not yet authenticated)
  S->>C: msg 4: IDr, EAP-Request
  C->>S: msg 5: EAP-Response (credentials)
  S->>A: Forward credentials
  A->>S: Accept/deny
  Note over S: Server sends AUTH
  S->>C: msg 6: EAP-Request (success), AUTH
  C->>S: msg 7: AUTH (client auth)
  S->>C: msg 8: EAP-Response (ack), AUTH
  Note over C,S: IKE SA established with EAP-authenticated user

The EAP exchange extends IKE_AUTH from 2 messages to 4 messages. The total handshake is 6 messages (vs. 4 for plain IKEv2). After the EAP exchange, both sides know the user is authenticated.

For remote-access deployments, the typical setup is:

• IKEv2 server with EAP authentication.
• RADIUS (or LDAP) backend that stores user credentials.
• Each user has a username/password (or certificate).

The IKEv2 server validates the user’s credentials via RADIUS; the tunnel is established only for authenticated users.

Configuration on VyOS 1.5 LTS

A basic IKEv2 site-to-site VPN with PSK:

configure
# IKE group (IKEv2 proposal)
set vpn ipsec ike-group IKE2 lifetime 28800
set vpn ipsec ike-group IKE2 ike-version 2
set vpn ipsec ike-group IKE2 proposal 1 encryption aes256gcm
set vpn ipsec ike-group IKE2 proposal 1 hash sha256
set vpn ipsec ike-group IKE2 proposal 1 dh-group 14

# ESP group (data plane)
set vpn ipsec esp-group ESP-1 lifetime 3600
set vpn ipsec esp-group ESP-1 proposal 1 encryption aes256gcm
set vpn ipsec esp-group ESP-1 proposal 1 hash sha256

# Peer with PSK
set vpn ipsec site-to-site peer R2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer R2 authentication pre-shared-secret "my-secret-key-here"
set vpn ipsec site-to-site peer R2 default-ike-group IKE2
set vpn ipsec site-to-site peer R2 default-esp-group ESP-1
set vpn ipsec site-to-site peer R2 local-address 198.51.100.1
set vpn ipsec site-to-site peer R2 remote-address 198.51.100.2

commit
save

A remote-access IKEv2 VPN with EAP and certificates:

configure
# IKE group
set vpn ipsec ike-group IKE2-RA ike-version 2
set vpn ipsec ike-group IKE2-RA proposal 1 encryption aes256gcm
set vpn ipsec ike-group IKE2-RA proposal 1 hash sha256
set vpn ipsec ike-group IKE2-RA proposal 1 dh-group 14

# ESP group
set vpn ipsec esp-group ESP-RA lifetime 3600
set vpn ipsec esp-group ESP-RA proposal 1 encryption aes256gcm
set vpn ipsec esp-group ESP-RA proposal 1 hash sha256

# RADIUS backend for user authentication
set vpn ipsec remote-access authentication mode eap-radius
set vpn ipsec remote-access authentication radius server 10.0.0.10
set vpn ipsec remote-access authentication radius secret "radius-secret"

# Server certificates (cert, key, CA)
set vpn ipsec remote-access connection ipsec-ra local-address 198.51.100.1
set vpn ipsec remote-access connection ipsec-ra authentication local id "vpn.example.com"
set vpn ipsec remote-access connection ipsec-ra authentication local x509 cert-file /config/auth/certs/server.crt
set vpn ipsec remote-access connection ipsec-ra authentication local x509 key-file /config/auth/certs/server.key
set vpn ipsec remote-access connection ipsec-ra authentication remote id "any"
set vpn ipsec remote-access connection ipsec-ra ike-group IKE2-RA
set vpn ipsec remote-access connection ipsec-ra esp-group ESP-RA
set vpn ipsec remote-access connection ipsec-ra default-gateway 10.10.10.1
set vpn ipsec remote-access connection ipsec-ra pool pool-ra

# IP pool for remote clients
set vpn ipsec remote-access pool pool-ra range 10.10.10.0/24

commit
save

The configuration supports:

• Multiple clients connecting with EAP authentication via RADIUS.
• Each client gets an IP from the configured pool.
• The server’s certificate is used for the IKEv2 authentication.

Validation

# IKEv2 SAs
swanctl --list-sas
# Shows the IKE SA and child SAs (ESP)

# Detailed connection state
swanctl --list-conns
# The configured connections (with proposal details)

# Logs
journalctl -u strongswan
# strongSwan logs (very useful for diagnosing negotiation failures)

# Capture on the wire
tcpdump -ni eth0 'udp port 500 or udp port 4500' -c 10 -vv
# Shows IKEv2 messages (with the proposal details)

# Verify MOBIKE
swanctl --list-sas --explain
# Shows the SA details; MOBIKE information is in the output

A clean validation: swanctl --list-sas shows IKE SA in ESTABLISHED state with the negotiated ciphers; child SAs are present for both directions; the data plane (ESP) has active SAs.

Production failure modes

IKEv2 proposal mismatch

The two peers do not have a common proposal (cipher, hash, DH group). The IKE SA is not established.

Diagnostic: swanctl --list-sas shows no SA; logs show “no proposal chosen”.

Fix: align the proposals on both peers.

PSK mismatch

The pre-shared secrets are different on the two peers. The authentication fails.

Diagnostic: logs show “PSK authentication failed”.

Fix: ensure both peers have the same PSK.

Certificate expired

A certificate in the chain has expired. The IKE SA does not establish.

Diagnostic: logs show “certificate expired” or “no certificate found”.

Fix: renew the certificate before it expires; configure auto-renewal if available.

MOBIKE not enabled

A mobile endpoint changes its IP, but MOBIKE is not enabled on the server. The tunnel breaks on the IP change.

Diagnostic: the tunnel establishes; the laptop moves; the tunnel does not re-establish.

Fix: enable MOBIKE on both peers.

RADIUS server unreachable

The RADIUS backend is unreachable. The EAP authentication fails; the tunnel does not establish.

Diagnostic: swanctl --list-sas shows no SA; logs show “RADIUS timeout” or similar.

Fix: ensure RADIUS is reachable from the IKE daemon; check firewall rules.

Rollback

# Enter configuration mode and write the running configuration to a
# file you can load back. `save` is a configuration-mode command that
# takes a path; operational mode has no `| save` pipe.
configure
save /config/pre-change-ipsec-ikev2-TICKET.conf

# Remove the IKEv2 configuration
delete vpn ipsec site-to-site peer R2

# Read the diff before committing anything
compare
commit

# Or restore a previous configuration
load /config/pre-change-ipsec-ikev2-TICKET.conf
commit
save

The rollback removes the IKEv2 configuration; the tunnel goes down.

Production discipline

Cross-course references

• Part XLII-01 (XLII-VyOS-IPsec / concept) covers the IPsec suite and where IKEv2 fits in.
• Part XLII-03 (XLII-VyOS-IPsec / ESP proposals) covers the cipher choices in detail.
• Part XLII-04 (XLII-VyOS-IPsec / route-based VTI) covers the VTI mode that IKEv2 typically uses.
• Part XLVII-06 (XLVII-VyOS-MgmtPlane / PKI and cert rotation) covers the certificate management that IPsec requires.

Quiz