heiko.helmle at horiba.com heiko.helmle at horiba.com
Wed May 20 18:20:04 EEST 2015

> So from my head, probably completely wrong type of before coffee
> calculation, that could be lifetime in seconds (00 00 00 01) for
> 1c00 seconds, aka 7168 seconds, prob 7200 (2h) when it started?

Well the message comes in during the initial Phase 1 - so it might be that 
Cisco defaults to something like 7168 seconds?
Peer admin configured 28800s on the GUI, but I couldn't find out what 

well... what phase is IPSEC_RESPONDER_LIFETIME related to? ikelifetime or 

I experimented and reduced both to 1800s. That at least takes the pressure 
from me babysitting the connection - but still the peer seems to throw the 
phase 1 away and Libreswan doesn't seem to notice, resulting in a broken 

000 State list:
000 #54: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established); 
EVENT_SA_EXPIRE in 144s; lastdpd=938s(seq in:0 out:0); idle; import:local 
000 #63: "remote":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); 
EVENT_v1_RETRANSMIT in 6s; lastdpd=-1s(seq in:0 out:0); idle; import:local 
000 #61: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established); 
EVENT_SA_REPLACE in 57s; newest ISAKMP; lastdpd=300s(seq in:0 out:0); 
idle; import:local rekey

with a dpdtimeout of 120 - shouldn't Libreswan have thrown away those (#54 
and #61)? Or does DPD only work on Phase 2?

> ps. pet peeve: It is "Libreswan" or "libreswan", not "LibreSWAN" - 
> SWAN is a trademark of RSA Inc.

I'll try to remember that :) 

Best Regards
 Heiko Helmle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20150520/f98508bd/attachment.html>

More information about the Swan mailing list