For remote access IPsec VPN on FortiGate, use IKEv2 for almost all new deployments, and keep IKEv1 only when you need legacy mechanisms like XAuth or old clients that cannot run IKEv2. IKEv2 is faster, more robust for roaming users, and required by newer FortiClient versions.
Protocol behavior and performance
- IKEv2 uses a streamlined exchange with fewer messages to build SAs, so tunnels come up faster and rekeying is more efficient.
- IKEv1 uses main/aggressive modes and more round‑trips, which increases latency and makes it less efficient at scale.
- IKEv2 supports multiple child SAs under a single IKE SA, improving scalability and reducing overhead; IKEv1 essentially maps one SA per tunnel pair.
Authentication (XAuth vs EAP)
- IKEv1 supports XAuth for user authentication, which is why it’s often used with legacy IPsec “remote access” profiles that expect username/password in XAuth.
- IKEv2 does not support XAuth; instead it uses EAP (for example EAP‑MSCHAPv2, EAP with MFA, etc.) for user auth, which is more flexible and better aligned with modern identity systems.
- If your design requires XAuth specifically (for example existing RADIUS policies built around it), you must stay with IKEv1; if you want modern EAP‑based auth and better MFA integration, use IKEv2.
The Two Phases of IKE
IKE operates in two distinct stages to ensure that the negotiation itself is secure before any user data moves across the wire.
Phase 1: The Management Tunnel
The goal of Phase 1 is to create a secure, authenticated bidirectional communication channel between the two peers (called the IKE SA).
Negotiation: The peers agree on encryption (AES), hash (SHA256), and Diffie-Hellman (DH) groups.
Diffie-Hellman Exchange: They securely exchange keys over an unsecure medium to derive a shared secret.
Authentication: The peers prove who they are using Pre-Shared Keys (PSK) or Digital Certificates (RSA/ECDSA).
Phase 2: The Data Tunnel
Once the Phase 1 tunnel is secure, it is used to negotiate the IPsec SAs. These are the “child SAs” that actually handle your data.
Selection of Proxy IDs: Defining which traffic goes through the tunnel (e.g., Local Subnet A to Remote Subnet B).
Encapsulation: Agreeing on whether to use ESP (Encapsulating Security Payload) for encryption or just AH (Authentication Header) for integrity.
IKEv2 Message Exchange
Unlike IKEv1, which could take up to nine messages, IKEv2 is streamlined into a minimum of four messages (two exchanges).
Exchange Name Purpose
IKE_SA_INIT Negotiation of cryptographic algorithms and the Diffie-Hellman exchange.
IKE_AUTH Authentication of the peers and the creation of the first CHILD_SA (the data tunnel).
CREATE_CHILD_SA Used later to “rekey” the tunnel or create additional subnets within the same session.
INFORMATIONAL Used for keep-alives (Liveness Check), error reporting, or deleting SAs.
Key Technical Components
1. Diffie-Hellman (DH) Groups – DH allows two parties to create a shared secret without ever sending the secret itself over the wire. Higher group numbers (like Group 14, 19, or 21) provide stronger security but require more CPU to calculate.
2. Perfect Forward Secrecy (PFS) – If PFS is enabled, a new DH exchange is performed every time the Phase 2 tunnel rekeys. This ensures that if a long-term key is ever compromised, it cannot be used to decrypt past sessions.
3. NAT Traversal (NAT-T) – Because IPsec ESP packets do not have “ports” (like TCP/UDP), they often fail when passing through a router doing NAT. IKE detects this and wraps the IPsec packets in UDP Port 4500, allowing them to pass through home routers and firewalls easily.
Comparison: IKEv1 vs. IKEv2
-
Efficiency: IKEv2 requires fewer messages to establish a connection.
-
Reliability: IKEv2 has built-in “MOBIKE,” allowing a VPN session to stay alive if you switch from Wi-Fi to LTE.
-
Security: IKEv2 requires authentication of the
IKE_SA_INITmessages to prevent DoS attacks, which IKEv1 struggled with.
