Project

General

Profile

Issue #3599

Compatibility issue between Strongswan 5.6.3 and 5.1.0 when sha256_96 and reauth=no is used

Added by Ravi Trivedi 13 days ago. Updated 11 days ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.6.3
Resolution:
No change required

Description

We are facing an issue between strongswan version 5.6.3 (Initiator) and 5.1.0 (Responder). Both the strongswan are configured to use sha256_96 algorithm. On initiator side reauth is disabled but rekey is enabled. On responder side rekey is disabled.

Initiator kernel version is 2.6.27 and responder is having latest kernel.

Everything works fine until the first IKE_SA rekey (inline since reauth is disabled). Once the IKE_SA is rekeyed, the next CHILD_SA rekey starts failing with NO_PROPOSAL_CHOSEN.

Dec 28 15:11:33 16[ENC] parsed CREATE_CHILD_SA request 34 [ N(REKEY_SA) SA No TSi TSr ]
Dec 28 15:11:33 16[CFG] selecting proposal:

Logs and config files are attached
Dec 28 15:11:33 16[CFG] no acceptable INTEGRITY_ALGORITHM found
Dec 28 15:11:33 16[CFG] selecting proposal:
Dec 28 15:11:33 16[CFG] an algorithm from private space would match, but peer implementation is unknown, skipped
Dec 28 15:11:33 16[CFG] no acceptable INTEGRITY_ALGORITHM found
Dec 28 15:11:33 16[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_96/NO_EXT_SEQ
Dec 28 15:11:33 16[CFG] configured proposals: ESP:AES_CBC_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_96/NO_EXT_SEQ
Dec 28 15:11:33 16[IKE] no acceptable proposal found
Dec 28 15:11:33 16[ENC] added payload of type NOTIFY to message
Dec 28 15:11:33 16[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 28 15:11:33 16[ENC] added payload of type NOTIFY to message
Dec 28 15:11:33 16[ENC] generating CREATE_CHILD_SA response 34 [ N(NO_PROP) ]

ipsec_initiator.conf (525 Bytes) ipsec_initiator.conf Ravi Trivedi, 16.10.2020 15:00
ipsec_responder.conf (603 Bytes) ipsec_responder.conf Ravi Trivedi, 16.10.2020 15:00
ipsec_responder.log (1.05 MB) ipsec_responder.log Ravi Trivedi, 16.10.2020 15:01

History

#1 Updated by Tobias Brunner 13 days ago

  • Category changed from interoperability to configuration
  • Status changed from New to Feedback
  • Priority changed from High to Normal

Dec 28 15:11:33 16[CFG] an algorithm from private space would match, but peer implementation is unknown, skipped

You need to enable the strongSwan vendor ID via charon.send_vendor_id in strongswan.conf.

#2 Updated by Ravi Trivedi 13 days ago

Tobias Brunner wrote:

Dec 28 15:11:33 16[CFG] an algorithm from private space would match, but peer implementation is unknown, skipped

You need to enable the strongSwan vendor ID via charon.send_vendor_id in strongswan.conf.

vendor id is enabled on both. If the vendor id is not enabled, it would fail even in the first attempt. That's not the case.

Everything works fine until the first IKE_SA rekey (inline since reauth is disabled). Once the IKE_SA is rekeyed, the next CHILD_SA rekey starts failing with NO_PROPOSAL_CHOSEN.

I am looking for a solution on the responder side. It's fine if we can atleast close IKE_SA when CHILD_SA rekey fails. Application software can recover from this and can re-initate the connection.

#3 Updated by Tobias Brunner 11 days ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

I see. That's due to a bug in versions before 5.2.0 (you should really not use such old versions). See 094963d1b160 for the fix.

Also available in: Atom PDF