What is IKE?

Internet Key Exchange (IKE) is the protocol that authenticates the two ends of an IPsec tunnel, negotiates the cryptographic algorithms and Diffie-Hellman group they will use, and produces the keys an IPsec security association runs on. Without IKE, IPsec peers would have no secure way to agree on keys before encrypting traffic.

Key takeaways

• IKE authenticates IPsec peers and negotiates their crypto parameters.
• It runs in two phases: a secure channel, then the data-plane SAs.
• IKEv2 is the modern default; IKEv1 remains for legacy peers.
• Diffie-Hellman groups set the strength of the negotiated keys.
• Versa VOS devices support IKEv1, IKEv2, or either, per tunnel.

On this page: Why it matters · How it works · Types · IKE & Versa · FAQ

Why is IKE important?

IKE is the control-plane companion to IPsec’s data-plane encryption. Without automated key negotiation, every tunnel would need manually configured, manually rotated keys – a process that does not scale. IKE authenticates each peer before traffic flows, preventing impersonation, and automatically negotiates the cipher suite and Diffie-Hellman group both sides will use.

IKE also keeps tunnels alive without interruption: it rekeys sessions on a time or volume schedule, refreshing keys before they expire, and detects a silent peer so a stale tunnel can be rebuilt rather than left half-open. Because IKE is an open, vendor-neutral standard, a Versa device can negotiate a tunnel with a Cisco, Palo Alto, or cloud-provider gateway using the same protocol – the interoperability that makes site-to-site VPNs and SD-WAN overlays practical across mixed-vendor networks.

What is IKE?

IKE negotiates in two phases. Phase 1 builds a secure, authenticated channel between the peers – the IKE security association – using a Diffie-Hellman exchange to derive a shared secret and either certificates or a preshared key (PSK) to prove identity. Phase 2 uses that protected channel to negotiate the IPsec security associations that protect data traffic: encryption transform, hash algorithm, and key lifetime.

Every negotiation draws on the same building blocks. Diffie-Hellman groups let both sides derive an identical secret without transmitting it. Hash algorithms such as SHA-256 verify negotiated messages were not tampered with. Dead-peer detection periodically checks the peer is still reachable, and rekeying – timed or volume-based – replaces keys before they expire so protected traffic never pauses.

Types of IKE

Two protocol versions exist. IKEv2 is the modern standard: it establishes a tunnel in four messages instead of IKEv1’s six or more, natively handles NAT traversal and network changes, and simplifies rekeying. IKEv1 persists mainly for compatibility with older peers; new tunnels should default to IKEv2, or to “either version” when the peer’s capability is unknown.

Authentication forms a second axis. Certificate-based (PKI) authentication scales best for large deployments and supports revocation checking. Preshared keys (PSK) suit a small number of point-to-point tunnels. Remote-access deployments can add EAP on top of IKEv2 to authenticate individual users rather than devices. Diffie-Hellman groups – from legacy 768-bit modulus groups to modern elliptic-curve groups – complete the picture, trading negotiation cost for key strength.

IKE & Versa

On Versa Director, IKE settings live inside IPsec VPN profiles: administrators choose IKE version v1, v2, or v2-or-v1, set the rekey timer, dead-peer-detection timeout, and fragment size, and select hash, encryption, and Diffie-Hellman group transforms – as a single transform or a prioritized list. Peer and local authentication use either certificates, with a CA chain and optional OCSP revocation checking, or a preshared key.

Site-to-site tunnel configurations show IKE interoperating with third-party gateways: IKEv2 route-based tunnels to Cisco ASR and CSR devices, IKEv1 policy-based tunnels to Cisco ASA devices – each confirmed by checking that Event History reports IKE Done before verifying the tunnel interface is up. Device templates also set a per-organization default IKE authentication mode, PSK or PKI, applied to every branch.

Frequently asked questions

What is the difference between IKEv1 and IKEv2?

IKEv2 establishes tunnels in fewer messages than IKEv1, natively supports NAT traversal and network mobility, and simplifies rekeying so it rarely drops a session mid-refresh. IKEv1 remains in use mainly for compatibility with older peers; new deployments should default to IKEv2, or v2-or-v1 when the peer is unknown.

What is the difference between IKE and IPsec?

IKE is the control-plane protocol that authenticates peers and negotiates keys and parameters. IPsec – specifically ESP – is the data-plane protocol that encrypts and authenticates the traffic itself, using the keys IKE produced. A working tunnel needs both: IKE to set up the security association, IPsec to protect the packets.

What authentication methods does IKE support?

IKE authenticates peers using digital certificates, with a CA chain and optional OCSP revocation checking, or a preshared key (PSK) shared out of band. Remote-access deployments can layer EAP methods such as MSCHAPv2 or TLS on top of IKEv2, authenticating individual users rather than device identities.

What is a Diffie-Hellman group in IKE?

A Diffie-Hellman group is a numbered set of parameters – a modulus size or elliptic curve – that IKE uses so two peers can derive an identical shared secret without ever transmitting it over the network. Higher-numbered groups provide stronger keys at the cost of more negotiation time.

What happens when an IKE tunnel’s peer goes silent?

Dead-peer detection sends a probe if no traffic arrives from the peer within a configured timeout. If the peer does not respond, the device tears down the security association and renegotiates a fresh tunnel rather than leaving a stale, one-sided connection in place indefinitely.

More on IKE

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about IKE, these are worth looking at next.