Windows Roadwarrior IPSec connections can be made to work if you use the default Windows encryption settings, but those are weak (SHA1 and MODP1024). So, I was trying to use PowerShell to enable stronger encryption, including AES-GCM and ECP. These are the two commands I was using, first to add the connection, and then to modify the encryption settings: Add-VpnConnection -name "Rymes - Concord IKEv2" -ServerAddress "rymes.com" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate -EncryptionLevel Required Set-VpnConnectionIPsecConfiguration -ConnectionName "Rymes - Concord IKEv2" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup ECP256 -PfsGroup ECP256 -Force Unfortunately, each and every time I ran the command to enable the stronger encryption, Windows complained that "IKE failed to find a valid machine certificate." Some sleuthing around brought me to this link, which indicates that Windows requires an ECDSA certificate for use with ECP (see the last comment): https://social.technet.microsoft.com/Forums/ie/en-US/b1d8b473-b05d-413b-8afe-2eeab00d263a/ike-failed-to-find-valid-machine-certificate?forum=win10itprosecurity Based on this, I then re-ran the second command from above, but modified to swap from ECP256 to MODP2048: Set-VpnConnectionIPsecConfiguration -ConnectionName "Rymes - Concord IKEv2" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup Group14 -PfsGroup PFS2048 -Force With those settings, the tunnel works quite well. I am not certain if Windows allows an ECDSA cert to be used with non-ECP encryption, but if it does, perhaps it makes sense to change the certificates to work with ECP? Unfortunately, I am not really certain where to start testing this.
Interesting, but actually the algorithm of the certificate does not have anything to do with the IKE handshake. It would make sense to use the modern EC cryptography throughout the whole system, but I do not see any technical reason why this would be a requirement. However, I am not sure what you are asking for right now. I would say, keep using MODP4096 or higher if possible. This won't have any disadvantage for the performance of the tunnel.
Michael, while the RFC does not require it, the Windows implementation does require it. This is actually a big deal, as the only group types that the built-in Windows IKE client supports at present are: Group1 Group2 Group14 ECP256 ECP384 Group24 Of those, only Group14, ECP256, and ECP384 are considered secure, and since it is not currently possible to use ECP256 or ECP384 with IPFire due to the certificate algorithm, that means IPFire users on Windows are currently limited to MODP2048 (Group14). I do not know if the actual IPFire Host and root certs need modifying, or just the certificate for the connection itself.
Rereading the linked comment, it appears that this may be more complex than initially acknowledged: "The ECDSA key length of the certificate used has to match the DH group length." I'm thinking that this means that the connection parameters need to be specified before the key is generated, and that it will only work with one specific DH Group.