From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 06:50:49 2005 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 C4D8F16A4CE for ; Wed, 2 Feb 2005 06:50:49 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C1843D31 for ; Wed, 2 Feb 2005 06:50:49 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from goku.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (rwcrmhc13) with ESMTP id <20050202065044015009jii0e>; Wed, 2 Feb 2005 06:50:45 +0000 Received: from goku.cjclark.org (localhost. [127.0.0.1]) by goku.cjclark.org (8.12.11/8.12.8) with ESMTP id j126oMk2014732; Tue, 1 Feb 2005 22:50:23 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by goku.cjclark.org (8.12.11/8.12.11/Submit) id j126o76B014731; Tue, 1 Feb 2005 22:50:07 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 1 Feb 2005 22:50:06 -0800 From: "Crist J. Clark" To: Chris Cowen Message-ID: <20050202065006.GA14664@goku.cjclark.org> References: <41FA6E06.8040309@wayforth.co.uk> <5a500d3088229b5786cedbe82665ece5@meta-x.org> <41FF8FEA.9050102@wayforth.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FF8FEA.9050102@wayforth.co.uk> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: racoon behaviour when SA expires X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 06:50:49 -0000 On Tue, Feb 01, 2005 at 02:19:22PM +0000, 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 a really low > >delay on both SAD & SPD and turn racoon debug on to see why your SA is > >not renegotiated. > > > > 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 machine can't > route the packet back through the tunnel). 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. -- Crist J. Clark | cjclark@alum.mit.edu