From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 13:53:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3364216A4CE; Thu, 22 Jan 2004 13:53:31 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6423943D2F; Thu, 22 Jan 2004 13:53:28 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1])i0MLrHKi070645 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2004 22:53:18 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.10/8.12.10/Submit) id i0MLrGt8070644; Thu, 22 Jan 2004 22:53:16 +0100 (CET) (envelope-from hmo) Message-Id: <200401222153.i0MLrGt8070644@sep.oldach.net> In-Reply-To: from Alex Hayward at "Nov 30, 2003 11:20:19 am" To: xelah-freebsd@xelah.com (Alex Hayward) Date: Thu, 22 Jan 2004 22:53:16 +0100 (CET) From: Helge Oldach <1822661512@oldach.net> X-Message-Flag: No HTML mail please MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Racoon(8) Deleting SPD Entries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 21:53:31 -0000 [Yes, this is an old issue, but I have been biten by it today, googled a bit, and here's a dirty fix] Alex Hayward wrote on Sun Nov 30 03:20:24 2003: > On Sat, 29 Nov 2003, Crist J. Clark wrote: > > 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. Yep. Racoon appears to check if an SP entry is already there, and since it is (because it hasn't been expired already), it doesn't install a fresh SP upon SA renewal. I have simply fixed this by avoiding the "it SP already there?" check. See the very simple-minded patch below. Yes, this will install an additional (in fact, identical) SP, so you will see two of them during the period when the old SA is dying and the new SA is already there, but it appears that it works fine and doesn't harm. Helge --- racoon/isakmp_quick.c.ORIG Tue Oct 21 09:18:03 2003 +++ racoon/isakmp_quick.c Thu Jan 22 22:26:13 2004 @@ -2012,7 +2012,7 @@ /* get inbound policy */ sp_in = getsp_r(&spidx); - if (sp_in == NULL) { + /* if (sp_in == NULL) */ { if (iph2->ph1->rmconf->gen_policy) { plog(LLV_INFO, LOCATION, NULL, "no policy found, "