Page MenuHomeVyOS Platform

ipsec: Subtle change in "pfs enable" behavior from equuleus -> sagitta
Needs testing, Requires assessmentPublicBUG


If I configure one router running equuleus and another router running sagitta as site-to-site peers using the following IKE/ESP group configs, the connection will die exactly after one hour.

esp-group VyOS-HS {
    compression disable
    lifetime 3600
    mode tunnel
    pfs enable
    proposal 1 {
        encryption aes256
        hash sha256
ike-group VyOS-HS {
    close-action none
    dead-peer-detection {
        action restart
        interval 15
        timeout 30
    ikev2-reauth no
    key-exchange ikev2
    lifetime 28800
    proposal 1 {
        dh-group 21
        encryption aes256
        hash sha256

Looking at logs on the machine, the connection seems to fail on re-key due to the ESP parameters subtly differing:

Sep 13 05:09:03 lcn-router charon: 08[ENC] <peer_52-205-98-246|3> generating CREATE_CHILD_SA response 103 [ N(NO_PROP) ]
Sep 13 05:09:03 lcn-router charon: 08[NET] <peer_52-205-98-246|3> sending packet: from[4500] to[1024] (80 bytes)
Sep 13 05:09:04 lcn-router charon: 09[NET] <peer_108-248-50-92|2> received packet: from[4500] to[4500] (368 bytes)
Sep 13 05:09:04 lcn-router charon: 09[ENC] <peer_108-248-50-92|2> parsed CREATE_CHILD_SA request 45 [ N(REKEY_SA) SA No KE TSi TSr ]
Sep 13 05:09:04 lcn-router charon: 09[CFG] <peer_108-248-50-92|2> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_521/NO_EXT_SEQ
Sep 13 05:09:04 lcn-router charon: 09[CFG] <peer_108-248-50-92|2> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_1024/NO_EXT_SEQ
Sep 13 05:09:04 lcn-router charon: 09[IKE] <peer_108-248-50-92|2> no acceptable proposal found
Sep 13 05:09:04 lcn-router charon: 09[IKE] <peer_108-248-50-92|2> failed to establish CHILD_SA, keeping IKE_SA

This can be confirmed by comparing the esp option in swanctl.conf (sagitta) and ipsec.conf (equuleus). The DH parameter is the ESP cipher string is different between the two configs. The same can be seen from parsing the above logs:
equuleus side: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_521/NO_EXT_SEQ
sagitta side: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_1024/NO_EXT_SEQ

Comparing source code, it appears the behavior and documentation string for the pfs enable value has changed between the two releases:
Equuleus: Enable PFS. Use ike-group's dh-group (default)
Sagitta: Use Diffie-Hellman group 2 (modp1024) - default

This is kind of a footgun, especially since a difference in values only produces a failure after the first ESP expiration. Likely we should either carry over the old "enable" behavior, or if there is a compelling reason to make always using "modp1024" the default, perform a one-time migration when upgrading to sagitta from equuleus that hard-codes the current IKE DH value into the PFS setting (I might also advocate disposing of the "enable" setting altogether if the old behavior is not desired—it is bound to cause confusion).


Difficulty level
Unknown (require assessment)
VyOS 1.4-rolling-202109110217
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change
Issue type
Bug (incorrect behavior)

Event Timeline

c-po changed the task status from Open to Needs testing.Mon, Sep 13, 8:28 PM
c-po reassigned this task from c-po to sdev.
c-po added a subscriber: c-po.

Booted my host with 1.4-rolling-202109140217 and confirmed pfs enabled is now generating the expected swanctl.conf file to match the old behavior. If I don't report back in exactly an hour from now that my tunnels died, we can assume the fix works.

However, looks like the docstring was missed :)

[edit vpn ipsec esp-group VyOS-HS]
lucas@lcn-router# set pfs
Possible completions:
   enable       Use Diffie-Hellman group 2 (modp1024) - default