Regression in strongSwan 5.9.4 causes N2N connections with one passive side to be reestablished every 10 seconds

[pmu-ipf]

System (please complete the following information):

• OS: IPFire 2.27 - Core Update 161 and HardenedBSD 13
• Kernel version (if applicable): Linux 5.10.76 and 13.0-STABLE-HBSD
• strongSwan version(s): 5.9.4 on both sides
• Tested/confirmed with the latest version: yes

Describe the bug
The HBSD server establishes an N2N connection to the IPFire machine, which is configured to wait for incoming IPsec traffic, not to establish the connection on its own. As long as either the HBSD server or IPFire machine runs strongSwan 5.9.3 or lower, this works fine and stable.

After subsequent upgrades, both systems are running strongSwan 5.9.4 now, and the IPsec tunnel is not stable anymore. Instead, it gets reestablished every 10 seconds due to uniqueids=yes and duplicate IKE_SA detected:

Nov 30 21:31:19 maverick charon: 13[IKE] schedule delete of duplicate IKE_SA for peer 'C=DE, O=x, CN=x' due to uniqueness policy and suspected reauthentication

Setting uniqueids=no on one of those systems causes the IPsec connection to be stable again, but sometimes leaves IPsec with multiple SAs established for the same connection, which is unnecessary. Despite, this setup worked for years with uniqueids=yes on both ends.

Especially with regards to

Several corner cases with reauthentication have been fixed (48fbe1d, 36161fe, 0d373e2).

in the 5.9.4's release announcement, it looks as if strongSwan 5.9.4 introduced a regression here, causing such IPsec connections to be mistakenly reestablished.

To Reproduce
Steps to reproduce the behavior:

1. Set up strongSwan 5.9.4 on two machines (in theory, any Linux distribution should be fine, but I have only had HBSD machines at hand for testing purposes).
2. On one machine, install this configuration (copied from an IPFire system, please adjust paths etc. accordingly)

conn x
	left=%defaultroute
	leftsubnet=10.71.163.1/32,10.71.163.128/25
	leftfirewall=yes
	lefthostaccess=yes
	right=x
	rightsubnet=10.95.163.2/32
	leftcert=/var/ipfire/certs/hostcert.pem
	rightcert=/var/ipfire/certs/xcert.pem
	leftid="@x"
	rightid="@x"
	type=tunnel
	ike=aes256gcm128-sha2_512-curve25519!
	esp=aes256gcm128-curve25519!
	keyexchange=ikev2
	ikelifetime=3h
	keylife=1h
	dpdaction=clear
	dpddelay=10
	dpdtimeout=30
	authby=rsasig
	leftrsasigkey=%cert
	rightrsasigkey=%cert
	auto=add
	fragmentation=yes

3. Set up this configuration on the other machine:

conn x
	rightsubnet=10.71.163.1/32,10.71.163.128/25
	left=x
	right=x
	leftsubnet=10.95.163.2/32
	leftcert=/usr/local/etc/ipsec.d/certs/x.pem
	rightcert=/usr/local/etc/ipsec.d/certs/x.pem
	rightid="@x"
	leftid="@x"
	type=tunnel
	ike=aes256gcm128-sha2_512-curve25519!
	esp=aes256gcm128-curve25519!
	keyexchange=ikev2
	ikelifetime=3h
	keylife=1h
	dpdaction=restart
	dpddelay=10
	dpdtimeout=30
	authby=rsasig
	leftrsasigkey=%cert
	rightrsasigkey=%cert
	auto=start
	fragmentation=yes
	installpolicy=no
	reqid=163
	closeaction=restart
	keyingtries=%forever

4. Bring up the IPsec connection by conducting

ipsec up [CONNECTIONNAME]

on the system where auto=start is set.

Expected behavior
The IPsec connection is established and running stable.

Logs/Backtraces
Similar to this sample. For some reason, the strongSwan instance on the system where auto=add is set tears down the IPsec connection after 10 seconds due do uniqueness policy. Setting uniqueids to no on that system mitigates the problem, but does not really solve it - see initial description.

Additional context
See also: https://bugzilla.ipfire.org/show_bug.cgi?id=12725

Cc: @mtremer

[tobiasbrunner]

My guess is that this is a side effect of 23e46ea. Since the host you consider to be a responder only may now initiate the reauthentication, instead of requesting the other peer to initiate it earlier, the closeaction=restart setting on the original initiator will cause duplicates to get created once the old IKE_SA is deleted, which in turn will trigger the duplicate check.

So to fix this, configure reauth=no on the host you only want to act as responder (or on both to only use rekeying, which is way more stable anyway).

[pmu-ipf]

So to fix this, configure reauth=no on the host you only want to act as responder (or on both to only use rekeying, which is way more stable anyway).

Thanks for this hint. Sorry for replying late on this.

I would prefer adding reauth=no for such connections in IPFire then, since this seems to be the lesser-intrusive change. While I consider it to be a safe change, I have no idea whether it will introduce side-effects to our userbase.

@mtremer: Do you have an opinion on this?

[mtremer]

@mtremer: Do you have an opinion on this?

IPFire does not configure closeaction. Therefore we should not run into this problem on our side. I played around with it, because in my mind it seemed to make sense to try to re-establish the connection after it was closed for whatever reason, but I always ended up in this swinging up/down/up/down cycle.

I wouldn't generally want to disable re-authentication in IPFire.

[pmu-ipf]

Apologies for my late reply on this.

So to fix this, configure _reauth=no_ on the host you only want to act as responder (or on both to only use rekeying, which is way more stable anyway).

I can confirm that this solves the flapping IPsec tunnel issue. In my scenario, however, it leads to initiators being unreachable if strongSwan on the responder is stopped (for example, during an update) and started again shortly afterwards. The initiators will then never try to establish the IPsec tunnel again. With `reauth=yes`, they do, so there is no manual interaction required for bringing the IPsec connections back up in such a case. Of course, I could use a Cron job or something similar to work around this, but that is a "solution" I would like to avoid. :-)

[tobiasbrunner]

closeaction=restart on the client? Or use trap policies to automatically create the connection again if there is matching traffic?

[pmu-ipf]

closeaction=restart on the client?

Of course, this was it; I completely forgot about that one. Thank you for the hint.