From owner-freebsd-net Mon Jan 14 9:55:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by hub.freebsd.org (Postfix) with ESMTP id 6089537B419 for ; Mon, 14 Jan 2002 09:55:28 -0800 (PST) Received: from grand.canyon.xs4all.nl (canyon.xs4all.nl [194.109.195.185]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0EHtQP5033818; Mon, 14 Jan 2002 18:55:26 +0100 (CET) Received: by grand.canyon.xs4all.nl (Postfix, from userid 1000) id C56EF5FA9; Mon, 14 Jan 2002 18:55:25 +0100 (CET) Received: from meandrix.tunix.nl (localhost [127.0.0.1]) by grand.canyon.xs4all.nl (Postfix) with ESMTP id 8CC785DB2; Mon, 14 Jan 2002 18:55:25 +0100 (CET) Date: Mon, 14 Jan 2002 18:55:28 +0100 Subject: Re: Filtering packets received through an ipsec tunnel Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: net@freebsd.org To: "Kshitij Gunjikar" From: Rene de Vries In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kshitij, As some other people already mentioned: It might be the case that both ends of the tunnel are not within the same administrative domain. The connection is secure, this does not mean that the traffic is also so. A good solution, from my point of view, would be, instead of passing evering thing from an ipsec tunnel, using ip-filter (&co, but without dummyet) on emerging packets. These packets should then have a different interface or a special flag for easy testing in ip-filter (&co). I don't know what the best solution would be, extending ip-filter with an extra flag or adding a special (dummy) interface. My gut feeling is a special flag makes more sense, but will break current ip-filter/ipfw syntax/configurations. I think it is generally usefull to be able to filter/nat traffic into/from an ipsec tunnel. When you trust the other side as your own, simply don't use it, but otherwise it is essential. The filtering in ipsec (with setkey) is simply not enough. Rene On Monday, January 14, 2002, at 01:02 , Kshitij Gunjikar wrote: > I'm wondering why do you want to filter Secure traffic? > > The very fact that you have a tunnel to a place means you trust that > network. Hence, why filter? > > What are the complex situations you have in mind? > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > Sent: Sunday, January 13, 2002 10:32 PM > To: net@freebsd.org > Subject: Filtering packets received through an ipsec tunnel > > > Hello, > >> This message was already posted to hackers@freebsd.org, but with >> limited success. I'm hoping that someone on net@freebsd.org can give me >> some more information. > > By experimenting with ipsec and looking at the source of "ip_input.c" a > co-worker and I found the following out. > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > passed through ip-filter (& co). After filtering and when it has been > determent that the current host is the destination (tunnel end-point), > this packet is decrypted/verified. The decrypted packet is then pushed > back into the queue that leads to ip_input(...). So far so good.... > > But once in ip_input(...) the filtering code is skipped and we were > wondering why. > > I know that ipsec has some handles to be able to filter on address, > protocol and/or port. But for more complex situations this is not > enough. In these situations it would be nice to be able to use > ip-filter (& co) on traffic from the tunnel (and also for traffic going > into the tunnel). > > I was wondering why this is implemented the way it is. Maybe someone on > this list could shed a light on this? -- Rene de Vries To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message