[strongSwan] Data transfer stops

Yuri Е. Gutnikov gutnikov at rnd.stcnet.ru
Fri Aug 18 13:03:14 CEST 2017


Hi, Tobias.

I reproduced situation with our normal lifetimes

     ikelifetime=60m
     lifetime=20m
     margintime=3m

Data transfer also stops, but after longer time.

Sincerely,

Yuri Gutnikov


04.08.2017 20:51, 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/20170818/305d411b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initiator_charon.log.bz2
Type: application/x-bzip
Size: 616621 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170818/305d411b/attachment-0002.bin>
-------------- next part --------------
config setup

conn %default
	ikelifetime=60m
	lifetime=20m
	margintime=3m
	lifepackets=10240
	marginpackets=2048
	rekeyfuzz=100%
	keyingtries=%forever
	keyexchange=ikev2

conn test1
	left=10.76.7.161
	leftcert=hostCert.pem
	leftsubnet=192.168.22.0/24,10.0.0.1/32
	right=10.76.7.129
	rightid="C=RU, O=Atlas, CN=host1.stcnet.ru"
	rightsubnet=192.168.23.0/24,10.0.1.1/32
	auto=add

conn host-host-natt
	left=192.168.0.10
	leftcert=hostCert.pem
	leftsubnet=192.168.1.0/24
	right=192.168.0.11
	rightid="C=RU, O=Atlas, CN=host1.stcnet.ru"
	rightsubnet=192.168.2.0/24
	forceencaps=yes
	auto=add
-------------- next part --------------
A non-text attachment was scrubbed...
Name: responder_charon.log.bz2
Type: application/x-bzip
Size: 613774 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170818/305d411b/attachment-0003.bin>


More information about the Users mailing list