Project

General

Profile

Issue #3359

unique = keep seems to behave like replace

Added by Glen Huang 5 months ago. Updated 5 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.8.2
Resolution:

Description

I have set unique = keep in my only connection, which can be verified by charon's unique = UNIQUE_KEEP message for load-conn.

When the second initiator connects with the same IDi, charons destroys the IKE SA instead of rejecting the connection:

IKE_SA ike-name[1] successfully checked out
destroying duplicate IKE_SA for peer 'name', received INITIAL_CONTACT
checkin and destroy IKE_SA ike-name[1]
IKE_SA ike-name[1] state change: ESTABLISHED => DESTROYING
CHILD_SA child{1} state change: INSTALLED => DESTROYING
...

I think either my understanding of keep (rejects the new one, keeps the old one) is incorrect or I didn't configure it right. Would like some help.

Also I noticed after the SAs were destroyed on the responder, the first initiator didn't destroy its SAs and resulting dead network (curl anything on the internet won't return results). The first initiator is also strongswan. Is there any way to make it automatically destroy SAs so the system can fall back to its original network settings? Should I enable DPD? (that sounds like pull mode, I'd like to have a push mode if possible)

History

#1 Updated by Tobias Brunner 5 months ago

  • Category set to configuration
  • Status changed from New to Feedback

When the second initiator connects with the same IDi, charons destroys the IKE SA instead of rejecting the connection:

As can be seen in the log message, that's because of the INITIAL_CONTACT notify. To ignore these notifies, you have to configure never (as documented), but that won't reject the new SA.

Is there any way to make it automatically destroy SAs so the system can fall back to its original network settings? Should I enable DPD? (that sounds like pull mode, I'd like to have a push mode if possible)

There is no notification by the server because it assumes any old connection is dead (the client sent an INITIAL_CONTACT notify after all) so it doesn't attempt to delete any existing SAs, they are just destroyed. The only way to detect this is on the client via DPD (or on the application layer).

#2 Updated by Glen Huang 5 months ago

As can be seen in the log message, that's because of the INITIAL_CONTACT notify.

So INITIAL_CONTACT can make "new connection" seem like an existing one, got it. Thanks a lot.

#3 Updated by Tobias Brunner 5 months ago

As can be seen in the log message, that's because of the INITIAL_CONTACT notify.

So INITIAL_CONTACT can make "new connection" seem like an existing one, got it. Thanks a lot.

No, it says "this is my first connection with you, so please forget any existing SA with me". Whether it is sent depends on the client and its config (and whether an existing IKE_SA between the same identities exists).

#4 Updated by Glen Huang 5 months ago

Tobias Brunner wrote:

As can be seen in the log message, that's because of the INITIAL_CONTACT notify.

So INITIAL_CONTACT can make "new connection" seem like an existing one, got it. Thanks a lot.

No, it says "this is my first connection with you, so please forget any existing SA with me". Whether it is sent depends on the client and its config (and whether an existing IKE_SA between the same identities exists).

Thanks, noted.

I was referring to the phrase from the doc

keep rejects new connection attempts if the same user already has an active connection

In my case the second initiator was a Mac. Before it started to connect, I had restarted strongswan while the Mac was still connected, so it dropped connection abruptly. I guess that's why it sent INITIAL_CONTACT when I connected it as the second initiator.

In that case, it did appear to be a "new connection" comparing to the one established by the first initiator.

I'm not saying the doc is wrong, these are all edge cases, and strongswan's doc is probably one of the best I have seen.

Discussing with you makes things much clearer for me. Thanks again.

#5 Updated by Tobias Brunner 5 months ago

I was referring to the phrase from the doc

keep rejects new connection attempts if the same user already has an active connection

Yeah, it doesn't explicitly mention INITIAL_CONTACT there (it's mentioned in the sentence before that). But the notify basically overrides the configured behavior, unless never is configured.

I guess that's why it sent INITIAL_CONTACT when I connected it as the second initiator.

Yes, that decision is made individually. A client obviously can't know if any other clients are connected using the same identity, it decides for itself (unless it's configured to not send INITIAL_CONTACT notifies at all).

Also available in: Atom PDF