What is a DH Group?

A DH group (Diffie-Hellman group) is a numbered set of parameters – a prime modulus or an elliptic curve – that two IKE or IPsec peers use to derive a shared secret without transmitting it over the network. Within the MODP family, higher-numbered groups use larger moduli and produce stronger keys – but group numbers are identifiers, not a strength ranking across families; Versa recommends Group 14 or above.

Key takeaways

• A DH group sets the modulus or curve strength for a key exchange.
• Group numbers are not a strength ranking: ECP Groups 25/26 are weaker than 14.
• IKE and IPsec each negotiate their own DH group; they can differ.
• Groups 19–21 and 25–26 use elliptic curves instead of a modulus.
• Versa recommends DH Group 14 or higher for new IKE and IPsec tunnels.

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

Why are DH groups important?

Every IKE and IPsec tunnel begins with a Diffie-Hellman exchange: two peers combine their own secret value with public math to compute the same shared key, without ever sending the key itself across the wire. The DH group picks which math they use – a prime modulus size, or an elliptic curve – and that choice directly sets how hard an attacker has to work to recover the key by brute force or precomputation.

Weak groups create real exposure. Group 1 (768-bit) and Group 2 (1024-bit), once common IKE defaults, are now considered too small – within reach of well-resourced attackers and below modern compliance baselines. Because IKE and IPsec Perfect Forward Secrecy negotiate their groups separately, a tunnel can end up strong in one phase and weak in the other unless an administrator sets both deliberately.

What is a DH group?

A DH group is one of a fixed set of parameter choices standardized for the Diffie-Hellman exchange used inside IKE. Each group specifies either a prime modulus of a given bit length (a MODP group) or an elliptic curve of a given bit length (an ECP group); both peers must select the same group so their independent calculations land on the same shared secret.

Within the MODP family, higher group IDs mean larger moduli, from 768 up to 4096 bits. The ECP family spans 192 to 521 bits – and its numbering breaks any higher-is-stronger intuition: Groups 19/20/21 (256/384/521-bit) are strong modern choices, while the older Groups 25 (192-bit) and 26 (224-bit) sit at or below Group 14’s approximately 112-bit security level despite their higher numbers. The group is one negotiated parameter among several – alongside encryption and hash algorithms – making up an IKE or IPsec transform; peers must agree on all of them before a security association can form, and mismatched groups are a common cause of failed negotiation.

Types of DH groups

Diffie-Hellman groups fall into two mathematical families. MODP groups (Groups 1, 2, 5, 14, 15, 16) derive their strength from prime modulus size, ranging from a 768-bit Group 1 up to a 4096-bit Group 16; larger moduli cost more CPU. ECP groups (Groups 19, 20, 21, 25, 26) use elliptic-curve cryptography instead, reaching equivalent strength with far smaller key sizes – a 256-bit Group 19 matches the ~128-bit security of a 3072-bit MODP Group 15 at a fraction of the compute cost. Mind the exceptions: Groups 25 (192-bit) and 26 (224-bit) are older, smaller curves at roughly 96- and 112-bit strength – at or below the Group 14 baseline, so “Group 14 or higher” does not include them.

A special case, No PFS, disables the extra Diffie-Hellman exchange for IPsec Perfect Forward Secrecy entirely, reusing IKE session key material instead of deriving a fresh one; it’s faster but removes the guarantee that a compromised long-term key can’t unlock past traffic. Most current guidance treats Group 14 as the practical minimum, with elliptic-curve or larger MODP groups reserved for higher-assurance deployments.

DH Group & Versa

On Versa Director, the DH group is set per IPsec VPN profile: the IKE tab’s Transform & DH Group section lets administrators pick one or more groups from Group 1 through Group 26 (MODP or elliptic curve) alongside the hash and encryption algorithm, defaulting to Group 2. The IPsec tab carries its own Perfect Forward Secrecy Group field – the identical Group 1–26 list – which defaults to No PFS unless explicitly changed.

The same pattern appears when configuring the Versa Secure Access Service and its Secure SD-WAN variant: the IKE/IPsec tab exposes separate PFS Group selectors for the IKE and IPsec phases of a SASE client tunnel. Because IKE and IPsec negotiate their groups independently across these profiles, Versa’s own guidance is to select Group 14 or higher consistently on both tabs rather than leaving either at its legacy default.

Frequently asked questions

What is the difference between MODP and ECP Diffie-Hellman groups?

MODP groups (1, 2, 5, 14, 15, 16) base their strength on prime modulus size, from 768 to 4096 bits. ECP groups use elliptic curves, which compute faster at equivalent strength – Groups 19/20/21 (256/384/521-bit) are the modern choices, while Groups 25 (192-bit) and 26 (224-bit) fall below the Group 14 baseline and should not be selected on the strength of their higher numbers.

Which DH group does Versa recommend?

Versa recommends DH Group 14 (2048-bit modulus) or higher for new IKE and IPsec tunnels. Group 14 balances strong security with reasonable CPU cost; elliptic-curve groups such as 19–21 offer even stronger keys at lower computational overhead where peer devices support them.

Why do IKE and IPsec each have their own DH group setting?

IKE negotiates a DH group to protect the initial key-exchange handshake, while IPsec’s Perfect Forward Secrecy group protects the data-plane session keys derived afterward. Configuring them separately lets an administrator harden PFS without renegotiating the whole IKE control channel, though best practice keeps both strong.

What happens if two IKE peers configure different DH groups?

Negotiation fails, or falls back to a group both sides support if multiple transforms are configured. A mismatch with only a single transform per side is a common cause of a tunnel that never comes up, and it shows up in IKE logs as a proposal mismatch.

What is No PFS, and when is it acceptable?

No PFS skips the extra Diffie-Hellman exchange for IPsec rekeying and reuses IKE-derived key material instead. It reduces CPU overhead but removes the guarantee that a compromised long-term key can’t decrypt past sessions, so it’s acceptable only where performance is critical and that risk is explicitly accepted.

More on DH groups

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

Related terms

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