MyNixOS website logo
option

services.strongswan-swanctl.swanctl.connections.<name>.children.<name>.esp_proposals

ESP proposals to offer for the CHILD_SA. A proposal is a set of algorithms. For ESP non-AEAD proposals, this includes an integrity algorithm, an encryption algorithm, an optional Diffie-Hellman group and an optional Extended Sequence Number Mode indicator. For AEAD proposals, a combined mode algorithm is used instead of the separate encryption/integrity algorithms.

If a DH group is specified, CHILD_SA/Quick Mode rekeying and initial negotiation use a separate Diffie-Hellman exchange using the specified group. However, for IKEv2, the keys of the CHILD_SA created implicitly with the IKE_SA will always be derived from the IKE_SA's key material. So any DH group specified here will only apply when the CHILD_SA is later rekeyed or is created with a separate CREATE_CHILD_SA exchange. A proposal mismatch might, therefore, not immediately be noticed when the SA is established, but may later cause rekeying to fail.

Extended Sequence Number support may be indicated with the esn and noesn values, both may be included to indicate support for both modes. If omitted, noesn is assumed.

In IKEv2, multiple algorithms of the same kind can be specified in a single proposal, from which one gets selected. In IKEv1, only one algorithm per kind is allowed per proposal, more algorithms get implicitly stripped. Use multiple proposals to offer different algorithms combinations in IKEv1.

Algorithm keywords get separated using dashes. Multiple proposals may be specified as a list. The special value default forms a default proposal of supported algorithms considered safe, and is usually a good choice for interoperability. If no algorithms are specified for AH nor ESP, the default set of algorithms for ESP is included.

StrongSwan default: ["default"]

Declarations
Type
null or (list of string)
Default
null