[strongSwan] Data transfer stops
Yu. E. Gutnikov
gutnikov at rnd.stcnet.ru
Fri Aug 4 19:51:20 CEST 2017
Hi, Tobias.I've used lifetimes from my first mail. I'll try to reproduce situation with normal lifetimes.
Отправлено с устройства Samsung
-------- Исходное сообщение --------
От: Tobias Brunner <tobias at strongswan.org>
Дата: 04.08.2017 18:31 (GMT+03:00)
Кому: "Yuri Е. Gutnikov" <gutnikov at rnd.stcnet.ru>, users at lists.strongswan.org
Тема: Re: [strongSwan] Data transfer stops
> I changed logging settings as you suggested. Full logs are in attachments.
Thanks. What lifetimes did you configure now? It seems the CHILD_SAs
are rekeyed immediately after they got established (i.e. the settings
you mentioned in your first email can't be in use here).
Anyway, I think I see what the problem is. With the new rekeying code
the old inbound IPsec SA will remain in the kernel for a few seconds in
order to process delayed packets (the default is 5 seconds, which can be
configured via charon.delete_rekeyed_delay). During that time the
CHILD_SA object remains in state CHILD_DELETING. However, CHILD_SAs in
that state will prevent the IKE_SA from getting reauthenticated ("unable
to reauthenticate in CHILD_SA DELETING state, delaying for Xs" is
logged). Because with your rekey lifetimes there is always a CHILD_SA
in state CHILD_DELETING (actually multiple, as they are rekeyed
immediately after establishing) the IKE_SA is never replaced until it
finally is destroyed due to the hard lifetime. I'd say with normal
rekey timings this shouldn't be a problem (i.e. when there is enough
time to retry the reauthentication before the IKE_SA is terminated if
such a collision should occur). It's also no issue if you use IKE
rekeying (reauth=no) as CHILD_SAs are then migrated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users