<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi, Tobias.</p>
<p>I reproduced situation with our normal lifetimes</p>
<p> ikelifetime=60m<br>
lifetime=20m<br>
margintime=3m<br>
</p>
<p>Data transfer also stops, but after longer time. <br>
</p>
<p>Sincerely,</p>
<p>Yuri Gutnikov<br>
</p>
<br>
<div class="moz-cite-prefix">04.08.2017 20:51, Yu. E. Gutnikov
пишет:<br>
</div>
<blockquote type="cite"
cite="mid:gclqrdu0eu9efcu5krh76icd.1501869079899@email.android.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div>Hi, Tobias.</div>
<div>I've used lifetimes from my first mail. I'll try to reproduce
situation with normal lifetimes.</div>
<div><br>
</div>
<div>Sincerely,</div>
<div>Yuri Gutnikov</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div id="composer_signature">
<div style="font-size:88%;color:#364f67" dir="auto">Отправлено с
устройства Samsung</div>
</div>
<br>
<br>
-------- Исходное сообщение --------<br>
От: Tobias Brunner <a class="moz-txt-link-rfc2396E" href="mailto:tobias@strongswan.org"><tobias@strongswan.org></a> <br>
Дата: 04.08.2017 18:31 (GMT+03:00) <br>
Кому: "Yuri Е. Gutnikov" <a class="moz-txt-link-rfc2396E" href="mailto:gutnikov@rnd.stcnet.ru"><gutnikov@rnd.stcnet.ru></a>,
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a> <br>
Тема: Re: [strongSwan] Data transfer stops <br>
<br>
Hi Yuri,<br>
<br>
> I changed logging settings as you suggested. Full logs are in
attachments.<br>
<br>
Thanks. What lifetimes did you configure now? It seems the
CHILD_SAs<br>
are rekeyed immediately after they got established (i.e. the
settings<br>
you mentioned in your first email can't be in use here).<br>
<br>
Anyway, I think I see what the problem is. With the new rekeying
code<br>
the old inbound IPsec SA will remain in the kernel for a few
seconds in<br>
order to process delayed packets (the default is 5 seconds, which
can be<br>
configured via charon.delete_rekeyed_delay). During that time the<br>
CHILD_SA object remains in state CHILD_DELETING. However,
CHILD_SAs in<br>
that state will prevent the IKE_SA from getting reauthenticated
("unable<br>
to reauthenticate in CHILD_SA DELETING state, delaying for Xs" is<br>
logged). Because with your rekey lifetimes there is always a
CHILD_SA<br>
in state CHILD_DELETING (actually multiple, as they are rekeyed<br>
immediately after establishing) the IKE_SA is never replaced until
it<br>
finally is destroyed due to the hard lifetime. I'd say with
normal<br>
rekey timings this shouldn't be a problem (i.e. when there is
enough<br>
time to retry the reauthentication before the IKE_SA is terminated
if<br>
such a collision should occur). It's also no issue if you use IKE<br>
rekeying (reauth=no) as CHILD_SAs are then migrated.<br>
<br>
Regards,<br>
Tobias<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>