From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:19:27 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 CB21616A4CE for ; Tue, 1 Feb 2005 14:19:27 +0000 (GMT) Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F22E43D45 for ; Tue, 1 Feb 2005 14:19:27 +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 1CvysI-0005RA-7q for freebsd-net@freebsd.org; Tue, 01 Feb 2005 14:19:26 +0000 Message-ID: <41FF8FEA.9050102@wayforth.co.uk> Date: Tue, 01 Feb 2005 14:19:22 +0000 From: Chris Cowen User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <41FA6E06.8040309@wayforth.co.uk> <5a500d3088229b5786cedbe82665ece5@meta-x.org> In-Reply-To: <5a500d3088229b5786cedbe82665ece5@meta-x.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] 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: Tue, 01 Feb 2005 14:19:27 -0000 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). I have tried applying the suggested fix in fbsd4/530, which seems to be a similar problem, but this doesn't make any difference, unfortunately. Turning on debug messages seems to alter timings sufficiently that problems are harder to reproduce exactly and/or slightly different problems are encountered. Looks like I'm going to have to have a more detailed look at the source ....