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

Tobias Brunner tobias at strongswan.org
Wed May 2 10:22:59 CEST 2018


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


More information about the Users mailing list