Troubleshooting Duplicate IPsec SA Entries¶

In certain cases an IPsec tunnel may show what appear to be duplicate IKE (phase 1) or Child (phase 2) security association (SA) entries.

Lengthy testing and research uncovered that the main way this starts to happen is when both sides negotiate or renegotiate simultaneously. If both peers initiate, reauthenticate, or rekey phase 1 at the same time, it can result in duplicate IKE SAs. If both peers rekey phase 2 at the same time, it can result in duplicate child SAs.

Mitigating this problem involves ensuring that the chance of simultaneous negotiation is minimized or eliminated. The easiest way to reach that goal is to set higher phase 1 and phase 2 lifetimes on one peer, or at least make sure both sides are not set identically.

Specific values vary but the settings below are the best general advice. Using the suggested values may not be possible due to peer constraints, such as third party vendors which do not support these settings or insist upon other settings. Variations are mentioned which should accommodate most situations, however, use as many strategies as possible.

Note

The values in this document take precedence over default recommendations in other IPsec examples and recipes.

Current version (2.5.0 and later)¶

The values in this section can be found in the current GUI. Older versions may have different values or some settings may not be available. Always run the most recent released version to ensure the best experience.

Peer A¶

Phase 1 (IKE SA):

Key Exchange Version:

IKEv2 if supported by both peers.

Life Time:

The total IKE SA lifetime as a hard upper limit (e.g. 28800)

Rekey Time:

90% of total IKE SA lifetime (e.g. 25920).

Reauth Time:

0 to disable reauthentication.

If the peer requires IKEv1 or only supports IKEv2 reauthentication, set this as mentioned in Rekey Time above and also enable Make Before Break on the Advanced Settings tab.

Rand Time:

Defaults to 10% of IKE SA Life Time (e.g. 2880). A larger Rand Time will decrease the chances of both peers renegotiating simultaneously.

Child SA Close Action:

Restart/Reconnect so that this side will reconnect child SA entries when they expire or fail.

Phase 2 (Child SA):

Life Time:: Total Child SA lifetime (e.g. 3600 for 1 hour). This peer will attempt to rekey the Child SA before it reaches this limit.
Rekey Time:: Leave blank to automatically use 90% of the Life Time, or choose a lower amount.
Rand Time:: Defaults to 10% of Child SA Life Time (e.g. 360). A larger Rand Time will decrease the chances of both peers renegotiating simultaneously.

Peer B¶

Phase 1 (IKE SA):

Key Exchange Version:

IKEv2 if supported by both peers.

Life Time:

The total IKE SA lifetime as a hard upper limit, but use a higher lifetime than Peer A by at least 10% (e.g. 31680). With this peer set higher, Peer A will primarily manage IKE SA renegotiation, reducing the chance of conflicts.

Note

If the remote peer insists their lifetime be set to a specific value, then set peer A lower instead by a similar margin.

Rekey Time:

90% of total IKE SA Life Time

Reauth Time:

Blank (disabled) to disable reauthentication.

If the peer requires IKEv1 or only supports IKEv2 reauthentication, set this as mentioned in Rekey Time above and also enable Make Before Break on the Advanced Settings tab.

Rand Time:

Defaults to 10% of IKE SA Life Time (e.g. 3168). A larger Rand Time will decrease the chances of both peers renegotiating simultaneously. If using the same Life Time as Peer A, then increase this value further. If using a larger Life Time for Peer B, then leave this at the default or disable it (0).

Responder Only:

Checked so that this side will not automatically initiate IKE SA negotiation.

Note

This peer can still manually initiate a connection from Status > IPsec, but it won’t happen automatically.

Child SA Close Action:

Close connection and clear SA so that when a Child SA expires, this side will remove the SA and not attempt to renegotiate a new entry.

Phase 2 (Child SA):

Life Time:: A larger value than the Life Time set on Peer A by at least 10%. For example, if Peer A is set to 3600, set this to 5400. That way Peer A will primarily manage Child SA renegotiation.

Note

If the remote peer insists their lifetime be set to a specific value, then set peer A lower instead by a similar margin.
Rekey Time:: Leave blank to automatically use 90% of the Life Time, or choose a lower amount.
Rand Time:: Defaults to 10% of Child SA Life Time (e.g. 540). A larger Rand Time will decrease the chances of both peers renegotiating simultaneously. If using the same Life Time as Peer A, then increase this value further. If using a larger Life Time for Peer B, then leave this at the default or disable it (0).

Advanced IPsec Settings (both)¶

Make Before Break:: Checked if phase 1 uses IKEv2 and reauthentication, not relevant otherwise.

Version 2.4.5-p1 and older¶

The settings are almost all the same as the section above, with a couple changes. The primary difference is in the GUI settings for rekey and reauth. Only the differences are noted below, so follow the previous section except for the values noted here.

Warning

On 2.4.5-p1, setting Responder Only in the phase 1 options requires an extra patch, 9a69dd4b8ff6eeeaf5779b7388a10743afae8e91, which can be applied using the System Patches Package.

Peer A:

Lifetime:: The total time at which this peer will renegotiate the IKE SA (e.g. 28800)
Margin Time:: An amount of time, in seconds, before the Life Time is reached when renegotiation begins. Defaults to 540, but larger values can help reduce the chance of simultaneous renegotiation. Due to the default behavior of the IPsec daemon, this time can be randomly increased up to twice its value to further help avoid both sides choosing the same time. A larger value will help avoid potential collisions.
Disable Rekey:: Unchecked
Disable Reauth:: Checked

Peer B:

Lifetime:: A higher time than the same field on Peer A by at least 10%. (e.g. 32400)
Margin Time:: If using the same Life Time as Peer A, use a larger value to help avoid simultaneous renegotiation. If using a larger Life Time value, then leave this blank or set to the same value as Peer A.
Disable Rekey:: Unchecked
Disable Reauth:: Checked

Other notes¶

The strongSwan daemon introduces randomness into the renegotiation process which can help mitigate the problem, but still leaves it up to chance if both peers are using the exact same lifetime values. That is why setting one peer higher, beyond the randomness threshold, is a better practice. The randomness also explains why the problem can take a while to manifest in certain environments as the duplicates do not happen until both peers happen to land on the same random rekey time.