[strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Thu Mar 8 11:46:27 CET 2018


Hi,

That's because charon doesn't reestablish tunnels in any case, like pluto did. Use auto=route, instead of auto=start.
An example of such a case is if the other peer deletes the iKE SA or CHILD SA without establishing a new one at the same time.
You can have different IKE SAs for CHILD_SAs by setting the strongswan.conf option charon.reuse_ikesa to 0.

>       charon.reuse_ikesa [yes]
>              Initiate  CHILD_SA  within  existing IKE_SAs (always enabled for
>              IKEv1).

Kind regards

Noel

On 07.03.2018 22:20, Justin Pryzby wrote:
> On Wed, Mar 07, 2018 at 10:52:54AM +0100, Martijn Grendelman wrote:
>> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
>> for a long time.
> [...]
>
>> Last week, I upgraded the system to Debian Stretch (with StrongSwan
>> 5.5.1), and since then, a number of tunnels (but not all of them) have
>> stability issues. The issue appears to be that CHILD_SA's are not
>> established when needed,
> Maybe you know that in 5.0, IKEv1 was integrated into charon and separate pluto
> daemon was retired:
> https://www.strongswan.org/blog/2012/07/02/strongswan-5.0.0-released.html
> https://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1
> https://www.strongswan.org/blog/2012/06/20/bye-bye-pluto.html
> https://wiki.strongswan.org/projects/strongswan/wiki/500
>
> Just wondering: are all the tunnels with issues have multiple child SAs (or,
> the tunnels without issues all have only one child SA).
>
> I recently reported an issue here, also related to a migration/update from 4.5,
> and started to suspect that multiple child SAs may be involved..
> https://wiki.strongswan.org/issues/2535
>
> Note, I believe swanctl.conf allows configuring child SAs to use separate IKEs
> - avoiding the non-configurable behavior in starter+ipsec.conf: "added child to
>   existing configuration".  However that doesn't work for everyone(us) due to
> unique policy on remote peers.
>
> Justin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180308/3b638c37/attachment.sig>


More information about the Users mailing list