IIRC, the problem occurs when racoon(8) is set to "create policy" on the
fly. What happens is that when the SA gets stale, but before it expires,
racoon(8) creates a new SA. But since there is an existing entry in the
SPD, a new one is cannot made. When the old SA times out, the its
accompanying S
Chris Cowen:
>A bit more investigation reveals that the SA is re-established but the
>SPD entries at the remote get dropped. This would explain the half duplex
>communication I am seeing with tcpdump (ping repsonses get back as far
>as the remote racoon machine and the lack of SPD means the machin
On Tue, Feb 01, 2005 at 02:19:22PM +, Chris Cowen wrote:
> Alex wrote:
> >Hi Chris,
> >
> >SA in IPsec can expire really quick, it depends how often it is required
> >for SPD key negotiation. Once SPD is established, the SA will be
> >required only when a new tunnel key is needed. Try to put
Alex wrote:
Hi Chris,
SA in IPsec can expire really quick, it depends how often it is required
for SPD key negotiation. Once SPD is established, the SA will be
required only when a new tunnel key is needed. Try to put a really low
delay on both SAD & SPD and turn racoon debug on to see why your
Hi
I am using a VPN in tunnel mode between two sites, using racoon to
negotiate the SA with x500 certs and everything works well. However,
when the default SA lifetime of 8 hours (28800 secs) expires, racoon
will not re-establish connection automatically. I'm using ipv4.
A workaround is to flush