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
