From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 13:08:40 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 399AC16A4CE; Wed, 2 Feb 2005 13:08:40 +0000 (GMT) Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C1D43D1D; Wed, 2 Feb 2005 13:08:39 +0000 (GMT) (envelope-from chris@wayforth.co.uk) Received: from [82.69.161.254] (helo=[192.168.168.119]) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1CwKFK-0001OV-TT; Wed, 02 Feb 2005 13:08:38 +0000 Message-ID: <4200D0D0.3090308@wayforth.co.uk> Date: Wed, 02 Feb 2005 13:08:32 +0000 From: Chris Cowen User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Crist J. Clark" References: <41FA6E06.8040309@wayforth.co.uk> <5a500d3088229b5786cedbe82665ece5@meta-x.org> <41FF8FEA.9050102@wayforth.co.uk> <20050202065006.GA14664@goku.cjclark.org> In-Reply-To: <20050202065006.GA14664@goku.cjclark.org> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Heisenberg-IP: [82.69.161.254] 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 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 13:08:40 -0000 > 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