From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 23:53:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D28437B401; Tue, 15 Apr 2003 23:53:14 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B092043F85; Tue, 15 Apr 2003 23:53:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0135.cvx40-bradley.dialup.earthlink.net ([216.244.42.135] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 195gn8-0001yq-00; Tue, 15 Apr 2003 23:53:11 -0700 Message-ID: <3E9CFD8A.89353F06@mindspring.com> Date: Tue, 15 Apr 2003 23:51:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Crist J. Clark" References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f9a4ca659417c43cd7e53de84b8267fa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: "Jacques A. Vidrine" cc: freebsd-hackers@FreeBSD.org Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 06:53:14 -0000 "Crist J. Clark" wrote: > On Thu, Apr 10, 2003 at 11:15:11AM -0500, Jacques A. Vidrine wrote: > > So, KAME/IPsec experts ... have I gone atray with my configuration? > > Or is this simply not doable within the KAME framework? > > Or is this a bug (assuming my theory that packets are matched against > > the SPD again after de-encapsulation is correct)? > > 'uname -a'? I can't reproduce this on a 4.8 to 4.7 tunnel. On > 192.168.64.70, > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; FWIW, we ran into this same problem. Deleting the default route fixed it, for some reason. I never did track it down because we stopped shipping with IPSEC enabled, because of the huge overhead it had for all IPv4 connections (each connection eats a large chunk of RAM, which doesn't happen in the IPv6 case). I keep meaning to fix this, but I'm always hoping that the KAME people get to it first (on the other hand, maybe they don't *want* it fixed, to encourage people to use IPv6 instead ;^)). -- Terry