IKEv2 on Windows and FortiGate: Three Settings People Merge
IKE key exchange, CHILD SA protection and peer authentication are three separate rows. Matching group numbers in two dialogs does not merge them.
An IKEv2 agreement between a Windows client and a FortiGate gateway keeps failing, and the search for a mismatched number produces a longer list of numbers. The list only becomes manageable when it is split into three rows that fail independently: the key exchange that protects IKE, the protection applied to the CHILD SA, and the authentication that proves who each side is. Group numbers appear in two of those rows and mean different things.
Three rows that fail independently
The first row is the key exchange inside IKE itself, which produces the keys that protect the negotiation. The second is the proposal for the CHILD SA, which protects the traffic the tunnel carries. The third is authentication, which decides what each side presents and how the other validates it.
Failures land in different places. An exchange failure stops the negotiation before any tunnel exists. A CHILD SA failure happens after authentication succeeds, sometimes only on a rekey. An authentication failure can look like an exchange failure in the logs if you only read the first error.
Splitting the rows is not bookkeeping. It changes which setting is worth changing, and it prevents the most expensive move in this whole area, which is regenerating working certificates to fix a proposal mismatch. One row changing should never force the other two to change with it. That independence is the whole point of writing them separately.
What the two Windows fields control
Windows keeps two fields apart: DHGroup configures the IKE exchange itself, while PfsGroup configures the IPsec policy that protects tunneled traffic. They belong to different phases. Comparing a Windows IKE field against a FortiGate phase-2 value tests the wrong pair, and the numbers can match while the underlying exchange still fails.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAThe second and third commands report the security associations that actually exist, which is the closest thing to an answer that a client can give you. A main-mode association with no quick-mode association is a CHILD SA problem, and it is the signature of a phase-2 mismatch rather than a certificate problem.
Record what was offered and what was selected in one attempt. An offered list that contains an acceptable proposal and a selected proposal that does not match the gateway's policy is a configuration disagreement, not an interoperability mystery.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
An elliptic-curve group does not choose your signature key
The most persistent wrong inference in this area is that selecting an elliptic-curve DH group requires an elliptic-curve certificate. A DH group supplies key-exchange material; the signature algorithm is negotiated by the authentication framework, and the two are separate decisions in IKEv2.
RFC 7427 exists precisely because those decisions were previously entangled, defining how signature algorithms are advertised and selected independently of the key exchange. A gateway can support a curve group and a choice of signature schemes at the same time.
So when a negotiation fails after a group change, look at the authentication method before looking at the certificate's key type. Changing a certificate is a slow, risky operation that is rarely the answer, and doing it first destroys your ability to tell which change actually helped. Read the authentication row before touching the certificate store.
Keep the two in separate rows of the agreement sheet and the mistake stops being tempting. One row lists groups, the other lists signature schemes and identities, and neither is evidence about the other.
Put each private key with its actual owner
A gateway that presents its own certificate needs the private key that matches it. A peer that validates a chain needs the CA certificate, and it specifically does not need the CA's signing key. Confusing those three artefacts is how people end up importing a CA private key into a VPN device to make a certificate appear in a different category.
On FortiOS the roles are distinct: a local certificate with its key, a remote certificate used to identify a peer, and a remote CA entry that establishes trust in certificates that CA signed. A remote CA entry without a private key is not incomplete; it is correct for its purpose.
Imported CA signing keys widen the authority of anyone who can read that device. They also do not solve ordinary peer validation, because validation needs the public certificate and the trust decision, not the ability to mint new certificates.
Keep the CA signing key with the issuer's own process, and record which device holds which key. A short table of owners is worth more than a longer table of algorithms when an audit asks who could impersonate what. Nobody imports a key they know is inventory-only. Write the inventory before the incident, not after it.