[strongSwan] Data transfer stops

[Yu. E. Gutnikov]

Hi, Tobias.I've used lifetimes from my first mail. I'll try to reproduce situation with normal lifetimes.
Sincerely,Yuri Gutnikov


Отправлено с устройства 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 

Hi Yuri,

> 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.

Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170804/f66d8a40/attachment-0001.html>