On Wed, 20 May 2015, [email protected] wrote:
I have to communicate to a cisco peer that seems to disagree on lifetimes - it
sends informational payload IPSEC_RESPONDER_LIFETIME and
sometimes just deletes SAs and then ignores any further attempts to
reestablish, resulting in a stale ISAKMP. That means I have to --down
and --up the connection to force a new Phase 1.
I'm suspecting that thie IPSEC_RESPONDER_LIFETIME might contain information
that brings me closer to getting this connection stable -
unfortunately I cannot do anything with the payload:
May 20 12:06:40 millhouse pluto[1584]: | ISAKMP Notification Payload
May 20 12:06:40 millhouse pluto[1584]: | 00 00 00 1c 00 00 00 01 03 04 60 00
How do I interpret those values? Or do I have to enable debug logging to see
what Lifetime the Cisco sends?
I guess we should really parse those payloads. See
https://tools.ietf.org/html/rfc2407#section-4.5.2
https://tools.ietf.org/html/rfc2408#section-3.3
and the attribute registry at
https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-13
Note you might need to convert network order to host order of that byte
stream.
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?
And in a related question: My peer seems to have enabled some sort of
inactivity (or idle) timeout. Does LibreSWAN have a similar feature?
Or will auto=ondemand suffice once the SAs have timed out?
Not currently. It is on the radar though. We can already ask the kernel
about SA activity, and I believe we could even tell the kernel to let
us know when it is idle via the "soft use" parameter (on xfrm/netlink
anyway)
Paul
ps. pet peeve: It is "Libreswan" or "libreswan", not "LibreSWAN" - SWAN is a
trademark of RSA Inc.
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
