Windows has got its setup all messed up then… it also offers the weakest ciphers first. What a pain! I notice OSX does it correctly though - strongest ciphers offered first.
For the record, the IKE proposals that work for OSX and Windows (with weak or strong ciphers enabled) is as follows aes256-sha256-prfsha256-modp2048-modp1024 > On 2 May 2018, at 09:05, Tobias Brunner <[email protected]> wrote: > > Hi Christian, > >> When Windows connects, strongSwan gives it the wrong policy and hence >> Windows 10 reports a*policy match error* >> >> May 1 21:53:12 08[CFG] *received proposals*: >> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >> IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >> IKE:AES_GCM_16_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:AES_GCM_16_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >> IKE:AES_GCM_16_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >> IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >> IKE:AES_GCM_16_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024 >> May 1 21:53:12 08[CFG] *configured proposals*: >> IKE:AES_GCM_16_256/AES_GCM_16_128/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/MODP_1024 >> May 1 21:53:12 08[CFG] selected proposal: >> IKE:*AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_1024* >> >> Expected response (I'm guessing) >> *AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024 *(although >> I dont know why it doesnt chose the better ciphers). > > No, with AES-GCM there is no integrity algorithm (HMAC_SHA* here) needed > as combined-mode ciphers like AES-GCM provide both encryption and > integrity protection (see section 8 in RFC 5282 [1] and section 3.3 in > RFC 7296 [2]). > So the problem is that the client proposes invalid proposals and > probably expects an invalid proposal back. > > Regards, > Tobias > > [1] https://tools.ietf.org/html/rfc5282#section-8 > <https://tools.ietf.org/html/rfc5282#section-8> > [2] https://tools.ietf.org/html/rfc7296#section-3.3 > <https://tools.ietf.org/html/rfc7296#section-3.3>
