From owner-freebsd-net Tue Jan 15 4:18:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id B1C0E37B416 for ; Tue, 15 Jan 2002 04:18:16 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0FCILJ27515; Tue, 15 Jan 2002 13:18:21 +0100 (CET) (envelope-from alexlh) Date: Tue, 15 Jan 2002 13:18:21 +0100 From: Alex Le Heux To: Ari Suutari Cc: Rene de Vries , Kshitij Gunjikar , net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020115121821.GU75815@funk.org> References: <200201150733.g0F7Xww91320@guinness.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201150733.g0F7Xww91320@guinness.syncrontech.com> User-Agent: Mutt/1.3.25i 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 On Tue, Jan 15, 2002 at 09:42:37AM +0200, Ari Suutari wrote: > Hi, > > On Monday 14 January 2002 19:55, Rene de Vries wrote: > > Kshitij, > > 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. > > [snip] > Maybe one could remove this, add 'ipsec' flag to ipfw > (which would use the above ipsec_gethist to match it) > so the syntax would be something like this: > > ipfw add pass tcp from a to b ipsec setup # matches only packets that came > via ipsec stack > ipfw add pass 50 from a to b # matches packets that didn't come via ipsec [snip] This looks like it would work for most situations. What one would not be able to do this way is prevent spoofing. In an ideal world I would also want to filter packets that come from the wrong tunnel. That would require the ipfw rules to somehow identify the tunnel. I'm not entirely sure if this could be accomplished without major pain though. Regards, Alex Le Heux -- "The difference between men and boys is the speed of their toys..." - Motul ad in Motor Magazine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message