Good day, Just to make sure we're talking about the same thing- you're asking for the dynamic entries that show up when "setkey -DP" is run?
When I was having the problem, the dynamically created ones showed up with "lifetime: 3600(s)", although looking right now, with this change and with a client still connected, they are all "lifetime: 0(s)". And yes, that is what my policy looks like now (the "out" rule is defined first, in case that matters). Could you (or someone) explain why this change seems to work, though? Thanks, ============================ Darren Gamble Planner, Regional Services Shaw Cablesystems GP 630 - 3rd Avenue SW Calgary, Alberta, Canada T2P 4L4 (403) 781-4948 > -----Original Message----- > From: Chris Andrews [mailto:[EMAIL PROTECTED] > Sent: June 23, 2004 12:21 PM > To: [EMAIL PROTECTED] > Subject: Re: IPSEC connectivity dies after a few hours > > > On 23 Jun 2004, at 18:40, Darren Gamble wrote: > > > I believe that I may have fixed the problem- I added an "in" rule to > > setkey > > as well, and reversed the order of the addresses for that rule. So > > far the > > connection has been up for an hour and a half- I'll let it run over > > the day > > and see if it dies at all. > > Can you tell what lifetime the SAs that are created have? It could be > that a > longer lifetime is being negotiated and the real rekeying problem > remains -- > having said that the longer lifetime may prove long enough for you. > > Just to confirm, is this what you're finding works ok: > > spdadd 0.0.0.0[0] a.b.c.d/0[1701] any > -P in ipsec esp/transport//require ; > spdadd a.b.c.d[1701] 0.0.0.0/0[0] any > -P out ipsec esp/transport//require ; > > If it proves OK, I'll add a note to the web page. > > Cheers, > Chris.
