Windows VPN Group24 vs MODP3072: Which Group Do You Need?
Group numbers are registry entries, not a size ranking. Map the name to its parameters, then check which groups the Windows parameter can express.
Group24 and MODP3072 are both names for a key-exchange group, and they are not the same group at different strengths. Group24 combines a 2048-bit modulus with a 256-bit prime-order subgroup, while MODP3072 is the 3072-bit group 15. Choosing one when the other was specified changes the requirement instead of meeting it. Four things decide the outcome, and none of them requires trusting a name that looks similar.
The Number Is a Registry Entry, Not a Rank
IANA numbers key-exchange groups in the order they were registered, so a larger number means a later registry entry rather than a stronger group. Group 14 is 2048-bit MODP, group 15 is 3072-bit MODP, and group 24 combines a 2048-bit modulus with a 256-bit prime-order subgroup. Reading the identifier as a size ranking produces exactly the mistake of treating 24 as a bigger 15. The name is a label, and the parameters behind it are what the negotiation actually uses.
| IANA group | What the group is | Expressible as Windows DHGroup | What a mismatch looks like |
|---|---|---|---|
| 14 | A 2048-bit finite-field modulus | Group14 | The gateway reports modp2048, which is the same group in other vocabulary |
| 15 | A 3072-bit finite-field modulus | Not in the documented enumeration | You cannot request it from this parameter; a gateway reporting modp3072 was configured elsewhere |
| 24 | A 2048-bit modulus with a 256-bit prime-order subgroup | Group24 | The gateway reports modp2048s256, so the two names differ while describing one group |
| 20 | The NIST P-384 curve | ECP384 | The gateway reports ecp384, and that 384 counts a field size rather than a modulus |
Elliptic-curve groups add their own confusion, because a curve's bit count describes a field rather than a modulus. Comparing P-384 against a 3072-bit finite-field group as though the numbers measured one thing tells you nothing.
What the Windows Enumeration Can Express
The IKE registry and the Windows client parameter are different interfaces with different vocabularies. Microsoft's VpnClient cmdlet reference documents DHGroup as accepting None, Group1, Group2, Group14, ECP256, ECP384 and Group24. Group15 does not appear in that documented set, which means the parameter cannot express the group you were asked for. That is a limitation of the interface rather than a statement about which groups the protocol supports.
Supplying an unlisted spelling, an integer or a copied policy string does not extend the enumeration. Check the reference for the Windows version you actually deploy, and if the group is unavailable, the honest outcome is a different approved policy or a different client.
Keep DHGroup, PfsGroup and Certificate Type Apart
DHGroup selects the group for the IKE key exchange, and PfsGroup governs forward secrecy for the protected-traffic associations that follow. They are separate fields, so setting one correctly says nothing about the other. The certificate's RSA or ECDSA key is a third property, belonging to authentication rather than to the ephemeral exchange. A single profile can therefore be right in one layer and wrong in another, and a successful connection will not reveal which.
Reports that a particular certificate type forced an ECP group on every IKEv2 connection describe one combination of settings. They do not establish a rule of the protocol, and treating them as one is how a local quirk becomes a policy.
Read the Group the Gateway Negotiated
The VpnClient module offers Set-VpnConnectionIPsecConfiguration as a write-only interface, and no matching Get- cmdlet reads that policy back on the host. Record the DHGroup and PfsGroup values you applied, then read what the exchange actually used from the gateway. Run the commands after a fresh connection rather than after a reconnect that reused an old association.
swanctl --list-sas
ipsec statusallA profile reporting Group24 while the gateway reports modp2048s256 is consistent, since those are the same group under two vocabularies. A gateway reporting modp3072 while the profile says Group24 is not consistent, and one endpoint is not enforcing what you believe. The certificate line answers the separate authentication question, and the PFS field answers the third. Compare all three before writing a compliance note.
Record the requested group, the negotiated group and the interface that accepted or rejected the setting. That trio is what a reviewer needs, and none of it can be inferred from the policy name.