[strongSwan] policy mismatch

[Jafar Al-Gharaibeh]

The selection is not based on "best", but rather on the order of 
algorithms at the initiator side first and the responder side second.  
AFAIK, strongSwan accepts  the first  proposed algorithm that is also 
configured configured locally. The first algorithm proposed by windows 
and also accepted at your server is

Windows: "IKE:AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024"
strongSwan:   proposals = 
aes256gcm16-aes128gcm16-sha384-sha256-prfsha384-prfsha256-modp1024

If you want the better algorithm, then move it first in your windows 
configuration, or  change strongSwan to only accept the algorithms you 
prefer, i.e drop "-aes128gcm16"

proposals = aes256gcm16-sha384-sha256-prfsha384-prfsha256-modp1024

Regards,
Jafar

On 5/1/2018 4:59 PM, Christian Salway wrote:
> *version: strongSwan 5.6.2*
>
> When I connect from Windows 10, strongSwan replies with a different 
> policy than requested, causing a policy mismatch
>
> ```
> connections {
>    default {
>       version = 2
>       send_cert = always
>       encap = yes
>       pools = pool1
>       unique = replace
>       proposals = 
> aes256gcm16-aes128gcm16-sha384-sha256-prfsha384-prfsha256-modp1024
>       local {
>          id = vpnserver
>          certs = vpnserver.crt
>       }
>       remote {
>          auth = eap-mschapv2
>          eap_id = %any
>       }
>       children {
>          net {
>             local_ts = 10.0.0.0/20
>             inactivity = 1h
>          }
>       }
>    }
> }
> ```
>
> 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).
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180501/7fe0c794/attachment.html>