Date: Mon, 14 Jan 2002 18:55:28 +0100 From: Rene de Vries <rene@canyon.xs4all.nl> To: "Kshitij Gunjikar" <kshitijgunjikar@yahoo.com> Cc: net@freebsd.org Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <E4E6F464-0917-11D6-AC08-00039357FA7A@canyon.xs4all.nl> In-Reply-To: <DJEEIBCKNENADJJIMPLFAEGNCDAA.kshitijgunjikar@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rene@tunix.nl> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4E6F464-0917-11D6-AC08-00039357FA7A>