[Openswan Users] Regarding the life time for IKE SA and

[Peter McGill]

Well as far as I know OpenSWAN's Pluto program logs to the syslog
facility by default.
Now exactly where that goes may vary on your system.
In my case it ends up in the /var/log/secure file, mostly.


Peter McGill
Software Developer / Network Administrator
Gra Ham Energy Limited
----- Original Message ----- 
From: "Shi Lang" <shilang at greenpacket.com>
To: "'Peter McGill'" <petermcgill at goco.net>
Sent: Wednesday, January 18, 2006 8:49 PM
Subject: RE: [Openswan Users] Regarding the life time for IKE SA and


> Hi peter,
>
> Would you please tell me in which way you can see log information like:
> Dec 14 11:40:32 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 14 11:40:33 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 14 11:43:23 sheridan pluto[31069]:
>> "sunoco-172-16-19-net-to-london-office-net" #449: received Delete SA
>> payload: deleting ISAKMP State #449
>> Dec 14 11:43:23 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> received and ignored informational message
>
> Regards,
>
> Shi Lang
> Quality Assurance Engineer
> GreenPacket Bhd
> www.greenpacket.com
> Tel: 006-03-89966022 ext: 105
> E-mail: shilang at greenpacket.com
>
>
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: Thursday, January 19, 2006 5:49 AM
> To: shilang at greenpacket.com
> Cc: users at openswan.org
> Subject: Re: [Openswan Users] Regarding the life time for IKE SA and
>
> I think I may have been wrong about the cause of my error.
>
> ikelifetime=8.0h, keylife=1.0h didn't work.
> The connection was disconnected by the Nortel switch at
> almost 2 hours.
> ikelifetime=2.0h, keylife=1.0h almost worked.
> The connection experienced temporary failure for a few
> minutes just before the 2 hour mark.
> I'm thinking that the information I have about the Nortel
> switch's settings is incorrect, that the Rekey Timeout is
> probably 1 hour not 8 hours. I think this would explain
> what's happening to me.
> I asked for confirmation on this value a month ago, but
> never got a response, the managers of the remote switch
> are not very helpful. :(
> It seems that if either ikelifetime or keylife is more than 1
> hour, I have connection problems after 1-2 hours.
> I'm setting both to 1.0h.
>
> Sorry if this confused anyone.
>
>
> Peter McGill
> Software Developer / Network Administrator
> Gra Ham Energy Limited
> ----- Original Message ----- 
> From: "Peter McGill" <petermcgill at goco.net>
> To: <shilang at greenpacket.com>
> Cc: <users at openswan.org>
> Sent: Wednesday, January 18, 2006 12:45 PM
> Subject: RE: [Openswan Users] Regarding the life time for IKE SA and
>
>
>> Shi Lang:
>>> Regarding the life time for IKE SA and IPsec SA, openswan seems that the
>>> default values are:
>>> IKE sa: 1 hour
>>> IPsec sa: 8 hour
>>>
>>> But when I refer to other document, even like Microsoft ipsec, the
>>> default
>>> values are:
>>> IKE sa: 8 hour
>>> IPsec sa: 1 hour
>>
>>> You said "however it did cause an inter-op problem with a Nortel 
>>> switch,"
>>> Can you explain it more details?
>>
>> Sure,
>> I discussed it in my "One Hour Disconnect?" thread/topic, Dec 15-20, 
>> 2005.
>> To summarize,
>>
>> My Setup: OpenSWAN 2.4.4 on Linux Kernel 2.4.31
>> /etc/ipsec.conf:
>> version 2.0
>>
>> config setup
>> interfaces=%defaultroute
>> uniqueids=yes
>>
>> include /etc/ipsec.d/examples/no_oe.conf
>>
>> conn sunoco-172-16-19-net-to-london-office-net
>> left=66.11.74.93
>> leftnexthop=%defaultroute
>> leftsubnet=172.21.0.0/16
>> alsoflip=sunoco-toronto
>> rightsubnet=172.16.0.0/14
>> auto=route
>>
>> conn sunoco-192-168-net-to-london-office-net
>> left=66.11.74.93
>> leftnexthop=%defaultroute
>> leftsubnet=172.21.0.0/16
>> alsoflip=sunoco-toronto
>> rightsubnet=192.168.0.0/16
>> auto=route
>>
>> conn sunoco-toronto
>> left=199.212.129.226
>> leftnexthop=%defaultroute
>> also=sunoco
>>
>> conn sunoco
>> # keyexchange=ike
>> # aggrmode=no
>> # auth=esp
>> # 3des-md5-modp1024
>> ike=3des
>> esp=3des
>> # pfs=yes
>> # ikelifetime=1.0h
>> # keylife=8.0h
>> # rekey=yes
>> # compress=yes
>> compress=no
>> # keyingtries=%forever
>> keyingtries=3
>> dpddelay=30
>> dpdtimeout=120
>> # dpdaction=hold
>> dpdaction=clear
>> authby=secret
>> End: /etc/ipsec.conf
>>
>> My Business Partner's Setup: Nortel Contivity VPN Switch (1700 I think)
>> Branch Office:
>> Group:
>> Connectivity:
>> Idle Timeout: 00:00:00 (none)
>> IPsec:
>> Encryption:
>> - ESP - Triple DES with MD5 Integrity: Enabled
>> IKE Encryption and Diffie-Hellman Group: Triple DES with Group 2 
>> (1024-bit
>> prime)
>> Aggressive Mode ISAKMP Initial Contact Payload: Disabled
>> Perfect Forward Secrecy: Enabled
>> Compression: Disabled
>> Rekey Timeout: 08:00:00 (8 hours)
>> Connection Configuration:
>> Text Pre-Shared Key
>> Local Networks:
>> 172.21.16.0, 255.252.0.0
>> 192.168.0.0, 255.255.0.0
>>
>> Results:
>> I would initiate the on demand (route) connection, by accessing a website
>> on
>> the far side of the tunnel. The connection would establish, and work fine
>> for a while.
>> At about 45-50 minutes into the connection, the ESP tunnel (phase 2)
>> would,
>> renegotiate the key; the connection would continue working as expected.
>> Tested with same website.
>> At 1 hour after the connection was first established, the Nortel box
>> would,
>> terminate the connection, like this:
>> Dec 14 11:40:32 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 14 11:40:33 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 14 11:43:23 sheridan pluto[31069]:
>> "sunoco-172-16-19-net-to-london-office-net" #449: received Delete SA
>> payload: deleting ISAKMP State #449
>> Dec 14 11:43:23 sheridan pluto[31069]: packet from 199.212.129.226:500:
>> received and ignored informational message
>> At this point, I would have to manually force the connection up, via 
>> ipsec
>> auto --up or --route.
>>
>> With the Nortel, it seems to track connections as follows:
>> OpenSWAN's IKE (phase 1), Nortel considers the connection (control
>> tunnel).
>> OpenSWAN's ESP (phase 2), Nortel considers a connected subnet of that
>> connection.
>>
>> I have had the following in my ipsec.conf for a month, and it works fine:
>> ikelifetime=1.0h
>> keylife=30m
>> Since it worked, I didn't bother testing other cases, although I had
>> tested
>> a few that didn't work, before this one, such as ikelifetime=2.0h, and
>> keylife=8.0h. I also, tried changing most of the other values in the 
>> conf,
>> such as keyingtries, compression and various dpd settings. The results,
>> for these other tests, were no different.
>> To be complete, today I set ikelifetime=8.0h, and keylife=1.0h, the
>> connection has been up for a hour and a half now. If I discover a
>> problem with this new setting, I'll let you know, but I expect it to be
>> fine.
>>
>> My guess is, that in Nortel's case when the ike conn expires, it expires
>> the
>> esp conn too, since it considers the esp to be a child conn of the ike?
>> So if in OpenSWAN, keylife < ikelifetime, and ikelifetime <= Nortel's
>> Rekey
>> Timeout, it should work?
>> Possibly other venders use this way too?
>>
>>
>> Peter McGill
>> Software Developer / Network Administrator
>> Gra Ham Energy Limited