[strongSwan] Tunnel established, but 'no acceptable ENCRYPTION_ALGORITHM found'

[Jafar Al-Gharaibeh]

Very Helpful,

Thanks,
Jafar

On 5/2/2018 3:22 AM, Tobias Brunner wrote:
> Hi Jafar,
>
>>       Makes sense, but just to understand what is going on and know how
>> to read the logs, are you saying that each "ESP:" prefix signifies a
>> separate proposal that is parsed independently (log below)? A single
>> proposal might have one or more algorithms separated by slashes, correct ?
> Yes, they each are separate proposals that were all contained in the
> same SA payload sent by the client (see section 3.3 of RFC 7296 [1] for
> an illustration).  During proposal selection they are treated separately
> (i.e. we can't pick and choose algorithms from different proposals).
> And for each transform type (encryption, integrity, DH etc.) multiple
> algorithms may be contained in each proposal (in the log and status
> output separated with /).
>
> When configuring it you'd separate proposals with commas and the
> algorithms with dashes. For instance,
>
>> ESP:AES_GCM_16_128/AES_GCM_16_256/CHACHA20_POLY1305_256/NO_EXT_SEQ,
>> ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ,
>> ESP:AES_CBC_256/HMAC_SHA2_384_192/NO_EXT_SEQ,
>> ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/NO_EXT_SEQ
> would be configured like this in swanctl.conf:
>
> esp_proposals =
> aes128gcm16-aes256gcm16-chacha20poly1305,aes128-sha256,aes256-sha384,aes128-aes192-aes256-sha1-sha256-sha384-sha512
>
> Regards,
> Tobias
>
> [1] https://tools.ietf.org/html/rfc7296#section-3.3
>