1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1109942: strongswan-charon: upgrade to 6.0.1-6 causes "key derivati

    From Gabriel Filion@21:1/5 to All on Sat Jul 26 21:30:01 2025
    Package: strongswan-charon
    Version: 6.0.1-6
    Severity: important

    Hello!

    One of our servers got its strongswan-charon package upgraded from
    6.0.1-5 to 6.0.1-6 last night. It has ipsec connections to another
    trixie machine that's still using 6.0.1-5 and to a bookworm machine
    that's using 5.9.8-5+deb12u1

    No changes to the configuration happened for a while. Since the upgrade happened, the host with 6.0.1-6 can't establish connection to the other
    two hosts anymore. If I start the connection manually I can see the
    followup output (peer IP replaced by 1.2.3.4; local IP replaced by 1.2.1.2):

    ipsec up connection-name
    initiating IKE_SA connection-name[6] to 1.2.3.4
    generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
    sending packet: from 1.2.1.2[500] to 1.2.3.4[500] (972 bytes)
    received packet: from 1.2.3.4[500] to 1.2.1.2[500] (280 bytes)
    parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
    N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
    selected proposal:
    IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
    KDF_PRF with PRF_HMAC_SHA2_256 not supported
    key derivation failed
    establishing connection 'connection-name' failed


    Is this an expected compatibility break or is that an unexpected regression?


    -- System Information:
    Debian Release: 13.0
    APT prefers unstable
    APT policy: (500, 'unstable')
    Architecture: amd64 (x86_64)
    Foreign Architectures: i386

    Kernel: Linux 6.12.38+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
    Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE
    not set
    Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages strongswan-charon depends on:
    ii debconf [debconf-2.0] 1.5.91
    ii iproute2 6.15.0-1
    ii libc6 2.41-10
    pn libstrongswan <none>
    pn strongswan-libcharon <none>
    pn strongswan-starter <none>

    strongswan-charon recommends no packages.

    strongswan-charon suggests no packages.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gabriel Filion@21:1/5 to Tobias Brunner on Mon Jul 28 16:10:01 2025
    Close: 1109942
    thanks


    We ended up figuring out that the problem was on our side. I'm not sure
    what actually caused this situation, but a reboot fixed the problem.

    So there was actually no issue with the contents of the strongswan
    package. sorry for the noise!


    On 2025-07-28 01:58, Tobias Brunner wrote:
    Hi Gabriel,

    One of our servers got its strongswan-charon package upgraded from
    6.0.1-5 to 6.0.1-6 last night. It has ipsec connections to another
    trixie machine that's still using 6.0.1-5 and to a bookworm machine
    that's using 5.9.8-5+deb12u1

    No changes to the configuration happened for a while. Since the upgrade
    happened, the host with 6.0.1-6 can't establish connection to the other
    two hosts anymore. If I start the connection manually I can see the
    followup output (peer IP replaced by 1.2.3.4; local IP replaced by 1.2.1.2): >>
    ipsec up connection-name
    initiating IKE_SA connection-name[6] to 1.2.3.4
    generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
    N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
    sending packet: from 1.2.1.2[500] to 1.2.3.4[500] (972 bytes)
    received packet: from 1.2.3.4[500] to 1.2.1.2[500] (280 bytes)
    parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
    N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
    selected proposal:
    IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
    KDF_PRF with PRF_HMAC_SHA2_256 not supported
    key derivation failed
    establishing connection 'connection-name' failed


    Is this an expected compatibility break or is that an unexpected regression?

    If you have OpenSSL 3.5.1 installed, then this is unfortunately
    expected. It requires the patches at [1] and [2], which were released
    with 6.0.2.

    Regards,
    Tobias

    [1] https://github.com/strongswan/strongswan/commit/2dbeecfc029ba26647c756b0882bc6e85e2e6b64
    [2] https://github.com/strongswan/strongswan/commit/43b805b2daed48bdf835ca8eeb87b9b71a42781f

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)