Date: Tue, 15 Jan 2002 09:42:37 +0200 From: Ari Suutari <ari.suutari@syncrontech.com> To: Rene de Vries <rene@canyon.xs4all.nl>, "Kshitij Gunjikar" <kshitijgunjikar@yahoo.com> Cc: net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <200201150733.g0F7Xww91320@guinness.syncrontech.com> In-Reply-To: <E4E6F464-0917-11D6-AC08-00039357FA7A@canyon.xs4all.nl> References: <E4E6F464-0917-11D6-AC08-00039357FA7A@canyon.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > This kind of flag might be easy to add to ipfw, I think. Currently, in ip_input there is: if (ipsec_gethist(m, NULL) goto pass; 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 I think that this would be much cleaner than fake interfaces most implementations seem to use. Ari S. 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?200201150733.g0F7Xww91320>