From owner-freebsd-net@FreeBSD.ORG Thu Apr 13 22:06:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3C24A16A404 for ; Thu, 13 Apr 2006 22:06:02 +0000 (UTC) (envelope-from kbyanc@posi.net) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id EECF143D49 for ; Thu, 13 Apr 2006 22:06:00 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k3DM68YA010939 for ; Thu, 13 Apr 2006 18:06:09 -0400 X-ORBL: [71.141.241.167] Received: from gateway.posi.net (adsl-71-141-241-167.dsl.snfc21.pacbell.net [71.141.241.167]) by pimout5-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k3DM5g4X011888; Thu, 13 Apr 2006 18:05:44 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 44FC175E05F; Thu, 13 Apr 2006 16:13:35 -0700 (PDT) Date: Thu, 13 Apr 2006 16:13:34 -0700 (PDT) From: Kelly Yancey To: "Bjoern A. Zeeb" In-Reply-To: <20060411213528.F13011@maildrop.int.zabbadoz.net> Message-ID: <20060413155210.R73176@gateway.posi.net> References: <442D8E98.6050903@vineyard.net> <20060331222813.GA29047@zen.inc> <20060331223613.GD80492@spc.org> <20060402130227.G99958@atlantis.atlantis.dp.ua> <20060402113516.D76259@maildrop.int.zabbadoz.net> <20060402151039.R51461@atlantis.atlantis.dp.ua> <20060411153224.L55107@gateway.posi.net> <20060411213528.F13011@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Dmitry Pryanishnikov , freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: tcpdump and ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2006 22:06:02 -0000 On Tue, 11 Apr 2006, Bjoern A. Zeeb wrote: > On Tue, 11 Apr 2006, Kelly Yancey wrote: > > Hi, > > > On Sun, 2 Apr 2006, Dmitry Pryanishnikov wrote: > > > >> On Sun, 2 Apr 2006, Bjoern A. Zeeb wrote: > >>>> Why not? IMHO it will be very useful feature: think about e.g. traffic > >>>> shaping for several different networks which are routed via the same > >>>> ipsec tunnel. Without the enc0, you can only shape them together, e.g.: > >>> > >>> why not shaping on the internal interface in case this is a gateway? > >>> You know src and dst there too. > >> > >> Gateway can also contain sources of traffic, and we should be able > >> to shape all outgoing or incoming traffic (not only transit packets, > >> but also locally-originated). > >> > >>> The only difference enc0 makes is for host-only-setups or if you want > >>> to see all your unencrpyted ipsec traffic on a gateway in one place. > >> > >> It seems to me that it's also useful for general traffic > >> shaping/accounting/filtering purposes. > >> > > I agree 100%. At work, we implemented the enc interface for FreeBSD > > 4.7 and 4.10 along with extending the divert interface such that we > > could perform filtering and NAT on packets after tunnel decapsulation. > > you know you can do this with what's in there already w/o enc(4)? > At least I have been doing it for more than two years now with 5.x > and greater. Actually this mail will get to you via such a setup. > Really? We aren't likely to move our product to 5.x or 6.x, but I'm curious: how are you performing NAT on your tunnelled traffic? If we were just talking about filtering, I would assume you were referring to the "ipsec" rule (which was introduced circa 4.9, hence not available when we implemented the enc interface on 4.7). However, I cannot figure out for the life of me how one would perform NAT on packets *inside* the IPsec tunnel without the enc interface. For example, the only pfil hook in the packet output path is is ip_output *after* IPsec encapsulation has occurred. Perhaps I'm missing something. > > > Just because one person doesn't have a use for the enc interface, does > > not mean that no one does. > > agreed. > > good arguments for example would also be that filtering IPSec traffic > with pf would becomen possible easily as long as there is no such > thing like the ipsec flag in ipfw... > I'm really looking forward to hearing how you are diverting traffic to natd before IPsec encapsulation. Thanks, Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com