linux-ipsec: Fun with fryed default expire/rekey timings in Pluto

  I had a report from a user that LFS was just jaming up. So off I went to test things out. Sure enough after a few minutes of running just fine all traffic stopped!
  Urg.
  Now I know why, check out the last two lines here:

root@west# ipsec whack --status
000 "ew": 209.157.90.160/29<->209.157.90.146:500<--->209.157.90.145:500<->209.157.90.152/29 000 ike_life: 3600s; ipsec_life: 480s; rekey_window: 540s; rekeytries: 3 000 goal: GOAL_ENCRYPT+GOAL_TUNNEL+GOAL_PFS; interface: eth0; routed; eroute owner: #6 000
000 #6: "ew" OAKLEY_QUICK_I_2; EVENT_SA_EXPIRE in 83s 000 #4: "ew" OAKLEY_MAIN_I_4; EVENT_SA_REPLACE in 2105s

  Now why would this be? Humm, the ipsec_auto man page says:

       rekeystart


                 (optional)  how  long  before  connection expiry


                 should  attempts  to  negotiate  a   replacement
                 begin;   acceptable   values   as  for  lifetime


                 (default 9m)

  Now I had done this in /etc/ipsec-auto:

        ...
        # SA lifetime (before automatic rekeying)
        lifetime=8m

  So my guess is that the 2000+ second REPLACE is comming from some code trying to do ( 8m - 9m ) and failing only slightly badly.   So I go and set "rekeystart=1m" to fix things up, run "ipsec auto ew replace" on both hosts and now I get more strangeness, once again check out the last two lines:

root@west# ipsec whack --status
000 "ew": 209.157.90.160/29<->209.157.90.146:500<--->209.157.90.145:500<->209.157.90.152/29 000 ike_life: 3600s; ipsec_life: 480s; rekey_window: 60s; rekeytries: 3 000 goal: GOAL_ENCRYPT+GOAL_TUNNEL+GOAL_PFS; interface: eth0; routed; eroute owner: #8 000
000 #8: "ew" OAKLEY_QUICK_I_2; EVENT_SA_REPLACE in 177s 000 #7: "ew" OAKLEY_MAIN_I_4; EVENT_SA_REPLACE in 3297s root@west#

  While on the other machine I get only expires(since there is no time stamp you will have to trust me that I ran both the above and below with in a second of each other)!:

root@east# ipsec whack --status
000 "ew": 209.157.90.152/29<->209.157.90.145:500<--->209.157.90.146:500<->209.157.90.160/29 000 ike_life: 3600s; ipsec_life: 480s; rekey_window: 60s; rekeytries: 3 000 goal: GOAL_ENCRYPT+GOAL_TUNNEL+GOAL_PFS; interface: eth0; routed; eroute owner: #6 000
000 #6: "ew" OAKLEY_QUICK_R_2; EVENT_SA_EXPIRE in 118s 000 #5: "ew" OAKLEY_MAIN_R_3; EVENT_SA_EXPIRE in 3238s

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

  Then on east I get:

000 #7: "ew" OAKLEY_QUICK_R_2; EVENT_SA_EXPIRE in 475s
000 #6: "ew" OAKLEY_QUICK_R_2; EVENT_SA_EXPIRE in 54s
000 #5: "ew" OAKLEY_MAIN_R_3; EVENT_SA_EXPIRE in 3174s

  Is it Ok to have two expire events on the same state?   Off the top of my head I would expect each end to have both a REPLACE and a EXPIRE.

  Well for all of my carping here it seems to work. The leading host (the one with out expires and with replace's) does seem to keep the link up, so the bug I am reporting seems to be in ever having REPLACE times larger then EXPIRE times or at least generating them by default.   I would like to see some logic in there ranther then a fixed 9m number.

                ||ugh Received on Sat Jan 23 08:53:01 1999