From owner-freebsd-stable Fri Nov 22 0:28:40 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 4CE6537B401 for ; Fri, 22 Nov 2002 00:28:39 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B60DB43E42 for ; Fri, 22 Nov 2002 00:28:37 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.12.6/8.12.6/hmo29jun02) with ESMTP id gAM8ROgm090721 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Nov 2002 09:27:24 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gAM8RNYD090720; Fri, 22 Nov 2002 09:27:23 +0100 (CET) (envelope-from hmo) Message-Id: <200211220827.gAM8RNYD090720@sep.oldach.net> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS In-Reply-To: <200211211757.gALHvsQg066238@arch20m.dellroad.org> from Archie Cobbs at "Nov 21, 2002 9:57:54 am" To: archie@dellroad.org (Archie Cobbs) Date: Fri, 22 Nov 2002 09:27:23 +0100 (CET) Cc: guido@gvr.org, dkelly@hiwaay.net, hausen@punkt.de, freebsd-stable-21nov02@oldach.net, archie@dellroad.org, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG From: Helge Oldach MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Archie Cobbs: > 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. While I (very roughly) understand how it could be implemented, I don't understand how this would work with ESP transport mode. With transport mode, the IP addresses remain unchanged, so essentially we are using publicly routable addresses, and commonly these are on the physical interfaces. How do we make the packets go to esp0 first instead of directly to the physical interface (where the routing table points them to)? Seems to me that we need some trickery routing using shadow routes to make this work, similar to using gif interfaces with ESP tunnel mode. This would add another point of confusion and violate POLA. Seems to me that an esp0 interface is really only useful for ESP tunnel mode. In that case it should be a point-to-point interface similar to gif. Perhaps worth mentioning: ESP transport mode over a gif tunnel is *not* the same as ESP tunnel mode. Having a FreeBSD box with transport mode/gif work against a non-FreeBSD machine in ESP tunnel mode will not work. Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message