On Mon, 17 May 2021, Ivan Kuznetsov wrote:
Yes, all the bkp* has the same life times:
[root@vpn3 ipsec.d]# ipsec auto --status | grep bkp | grep ike_life
000 "bkp/0x1": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32;
rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
000 "bkp/0x2": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32;
rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
000 "bkp/0x3": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32;
rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
000 "bkp/0x4": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32;
rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
That's good
Just over one hour is really weird. Can you run with plutodebug=all,tmi
and show the log lines you see between these two messages?
It can be a bit problematic as this ipsec instance handle 20+ active
production connections with different peers/clients. It seems that 'ipsec
whack --name bkp/0xN --debug all,tmi' does not have any logging effect. I'm
afraid enable debug logging globally will slow down the connections and make
a huge log.
Ok, how about: ipsec status |grep STATE_ |grep bkp/
That should show our timers live, so it would tell us if we are
epxecting to rekey soon or not. But it might require some calculation
from when you brought the conns up.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
