Date: Wed, 02 Feb 2005 13:08:32 +0000 From: Chris Cowen <chris@wayforth.co.uk> To: "Crist J. Clark" <cjc@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: racoon behaviour when SA expires Message-ID: <4200D0D0.3090308@wayforth.co.uk> In-Reply-To: <20050202065006.GA14664@goku.cjclark.org> References: <41FA6E06.8040309@wayforth.co.uk> <5a500d3088229b5786cedbe82665ece5@meta-x.org> <41FF8FEA.9050102@wayforth.co.uk> <20050202065006.GA14664@goku.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 SPD entry is killed, leaving no SPD entry at all. Yes, that would appear to describe exactly the behaviour we are seeing. Would it be better to turn off policy generation and manually add the SPD entries at the remote end? We have also had one or two other intermittent niggles which would appear to be caused by one or other of the racoon daemons entering a state from which it cannot gracefully recover (i.e. trying to remove something which is no longer there etc). This bears the all hallmarks of a program whose internal state is not explicitly controlled by a FSM, and is this supposition is further supported by the fact that the timing and behaviour appears to be affected by turning on debugging. I do however, like racoon's configuration syntax and the fact we got it up and running very quickly, so we may well come back to racoon again, and try the more comprehensive fix that Helge suggested but in the meantime we are also going to spend a couple of days evaluating OpenS/WAN to see how it compares. Thanks Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4200D0D0.3090308>