Re: [strongSwan] policy mismatch

[1] worked for me in the past. I also came across [2] which allows more options but I couldn't get that to work. I changed the encryption/integrity algorithms. I restated windows, but the proposal sent by windows didn't seem to be affected by changes using [2]. Regards, Jafar [1]

Re: [strongSwan] policy mismatch

Good to know! Thanks, Jafar On 5/2/2018 3:11 AM, Tobias Brunner wrote: AFAIK, strongSwan accepts  the first  proposed algorithm that is also configured configured locally. The behavior depends on the charon.prefer_configured_proposals setting (enabled by default). If enabled, the first local

Re: [strongSwan] policy mismatch

Thats what I meant by using stronger ciphers and adding the two DHG’s in the proposal. > On 2 May 2018, at 09:37, Tobias Brunner wrote: > > Hi Christian, > >> For the record, the IKE proposals that work for OSX and Windows (with >> weak or strong ciphers enabled) is as

Re: [strongSwan] policy mismatch

Hi Christian, > 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 If you want to use a stronger DH group with Windows clients see [1]. Regards, Tobias [1]

Re: [strongSwan] policy mismatch

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

Re: [strongSwan] policy mismatch

> AFAIK, strongSwan accepts  the first  proposed algorithm that is also > configured configured locally. The behavior depends on the charon.prefer_configured_proposals setting (enabled by default). If enabled, the first local proposal accepted by the client's proposals is used (similarly for the

Re: [strongSwan] policy mismatch

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, >

Re: [strongSwan] policy mismatch

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

[strongSwan] policy mismatch

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 =