Date: Sun, 30 Nov 2003 11:20:19 +0000 (GMT) From: Alex Hayward <xelah-freebsd@xelah.com> To: cjc@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: Racoon(8) Deleting SPD Entries Message-ID: <Pine.LNX.4.58.0311301102000.10011@sphinx.mythic-beasts.com> In-Reply-To: <20031130073243.GA4474@blossom.cjclark.org> References: <20031130073243.GA4474@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Nov 2003, Crist J. Clark wrote: > Versions: Racoon(8) from ports racoon-20030826a. FreeBSD kernel > 4.8-RELEASE-p13. Running with net.key.prefered_oldsa=1, but flipping > to 0 does not seem to make a difference. I've never quite seen the point of this option; surely using the old SA just can't possibly work properly? > I am having some problems with racoon(8). Everything works fine for > the lifetime of the initial SA, but then things die. When the initial > SA is removed, racoon(8) seems to be clearing out the corresponding > entry in the SPD. However, when we had reached the soft timeout > earlier, racoon(8) had established new SAs. Since we have good SAs, > racoon(8) doesn't try to do new negotiations. Both ends have a good > SAD, but the responder no longer has SPD entries for the pair. I've come across this, too. It appears to be a bug in Racoon; I've submitted a bug report to KAME - bug fbsd4/530. When Racoon creates the security policy it gives it a timeout equal to the timeout on the SA. It doesn't renew this timeout when a new SA is negotiated and will only create a new SP if the existing SP has already timed out. My solution was to statically configure the security policies. This works OK for us because the clients have static IP addresses - but it means that their dial-up fallback won't work because their IP addresses will change. It looks like the SP timeout could be left unset as a quick fix. Ideally, though, I'd prefer to have some sort of 'security policy template' database which would allow clients with particular IDs to establish SPs tunnelling to/from only particular networks but with the remote tunnel endpoints being whatever IP addresses they have at the time. There is a possibility I'll get the chance to work on doing this. On the other hand we might just use Linux and FreeSWAN instead.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.58.0311301102000.10011>