From owner-freebsd-stable Thu Nov 21 10:16: 6 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D1D537B401 for ; Thu, 21 Nov 2002 10:16:03 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9040E43E8A for ; Thu, 21 Nov 2002 10:16:02 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA83041; Thu, 21 Nov 2002 09:57:55 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gALHvtOS066239; Thu, 21 Nov 2002 09:57:55 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gALHvsQg066238; Thu, 21 Nov 2002 09:57:54 -0800 (PST) From: Archie Cobbs Message-Id: <200211211757.gALHvsQg066238@arch20m.dellroad.org> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS In-Reply-To: <20021121165237.GB98848@gvr.gvr.org> To: Guido van Rooij Date: Thu, 21 Nov 2002 09:57:54 -0800 (PST) Cc: David Kelly , "Patrick M. Hausen" , Helge Oldach , archie@dellroad.org, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Guido van Rooij wrote: > > An esp0 or ipsec0 device would provide the handle ipfw needs. > > That is excatly what I wanted to say earlier. > > But beware: this is only true in tunnel mode. > > In transport mode, the KAME stack calls the subprotocol handler > directly and, unless you set up your ipsec such that the decrypted > packets actually are tunneled packets using a gif interface, you will > never be able to catch the packets with a packet filter! This should be easy to fix though. Just have esp_input() requeue the packets on ipintrq instead of calling (*inetsw[ip_protox[nxt]].pr_input) directly. Of course, resetting m->m_pkthdr.rcvif to an appropriate value ("esp0" or whatever) would have to be done first. This shouldn't change the functionality in any way, except that the unencrypted packet will now pass through BPF and ipfw again. Note: fixing the ipfw and IPSec interaction is great, but another important benefit of fixing all this stuff is being able to use tcpdump on esp0 and gif0 to see packets at all of the various stages of encryption/decryption and encapsulation/de-encapsuation. We should make full BPF support another goal of our redesign. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message