Windows and strongSwan IKE Proposals: Matching Four Transforms
A shared cipher is not enough when the peers disagree on the key-exchange group. Compare all four transforms, then apply one scoped profile policy.
Two peers both support AES, both accept SHA-256, and the tunnel still does not come up. The proposal failed on a component nobody compared, usually the key-exchange group. This runbook reads the actual exchange before changing anything, applies one scoped policy, and leaves a rollback that restores the previous parameters.
Read the failure before you change a group
A "policy match error" is a summary, not a diagnosis. It means no mutually acceptable proposal was found, and it says nothing about which component was rejected. Treat it as the start of the investigation rather than as evidence about a specific group.
The server side usually carries the answer. A strongSwan log at an appropriate level lists the proposal it received from the client and the proposal it is configured to accept, and the difference between the two lists names the component that failed.
Do not assume the client offers what an older forum post says it offers. The active profile and its installed policy decide the offered list, and a Windows build that has been updated may offer a different set than the one in the screenshot you are copying from.
Write both lists down. Four transform positions and one group is a short list, and comparing it line by line takes less time than any experiment. Four positions are easy to hold in view. A log file is not.
Compare every transform, not one familiar name
An IKE proposal is a set of choices that all have to match. Encryption protects the negotiation, integrity or a PRF authenticates it, and a Diffie-Hellman group establishes fresh key material. A proposal that matches on the first two and differs on the third is still unacceptable to both peers.
The two Windows fields that get confused here belong to different phases. DHGroup applies to IKE key exchange, while PfsGroup applies to the child association that protects traffic. Changing the second one cannot repair a failure in the first.
Group names differ between implementations, which is a separate source of confusion. strongSwan writes modp2048 and ecp256 while Windows uses enumeration names such as Group14 and ECP256, so a comparison has to translate before it compares. Keep a two-column note with both names in it. The next mismatch then takes seconds to classify.
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
Apply one complete, scoped policy
The supported instrument for a native IKEv2 profile is a per-connection IPsec policy, set as one object rather than one field at a time. Preview it first, then apply it, and keep the previous parameters in the change record.
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIfThe -WhatIf switch previews the local change and applies nothing. That is useful, and it is also a common trap, because a preview proves only that the parameters are syntactically acceptable to the local cmdlet. It says nothing about whether the gateway will accept the resulting proposal.
Match the scope while you are at it. A connection in the all-user store needs the corresponding all-user parameter, and editing the per-user profile with the same display name changes a different object that the tunnel does not use.
Then adjust the strongSwan side to the same set before testing. A coordinated change on both ends is the only version of this that converges; changing one side and retrying repeatedly produces a log full of the same rejection.
Verify the exchange and the rekey separately
A successful connection is one observation, and the rekey is another. Initial IKE negotiation uses one set of parameters, and the child association that carries traffic can be renegotiated later with its own policy. A setup that connects and then drops after a while is usually the second case.
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *The first command shows the server's view of the established associations, including the child SA and its remaining lifetime. The second shows what the client profile now holds, which is the only way to confirm that the policy you set is the policy in effect.
Watch a full rekey before you declare success. That means leaving the connection up long enough for the child association to be replaced, then confirming that traffic continues. Most policy mismatches hide in that step because the initial negotiation can succeed with a set the rekey does not accept.
Rollback is the previous parameter set, not a permissive fallback. If the client offered only a weak legacy group, the answer is to improve the client and server common policy, not to add that group to the gateway where every future peer can negotiate down to it.
Record the four parameters, the group, the connection scope and the rekey result. That is a short note, and it is the difference between a runbook and a story about the time the tunnel came up.