Date: Fri, 6 Jun 2003 12:44:18 +0300 From: Vandyuk Eugene <duke@irpen.kiev.ua> To: freebsd-security@freebsd.org Cc: Darren Reed <avalon@caligula.anu.edu.au> Subject: Re: Statefull filtering with IPFW + IPFilter (was: Packet flow Message-ID: <20030606124418.A33769@irpen.kiev.ua> In-Reply-To: <200306050339.h553dPUJ002919@caligula.anu.edu.au>; from avalon@caligula.anu.edu.au on Thu, Jun 05, 2003 at 01:39:25PM %2B1000 References: <20030604133021.H24576-100000@cactus.fi.uba.ar> <200306050339.h553dPUJ002919@caligula.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 05, 2003 at 01:39:25PM +1000, Darren Reed wrote: > In some mail from Fernando Gleiser, sie said: > > > > > OUTGOING: IPF -> IPNAT -> IPFW > > > INCOMING: IPFW -> IPNAT -> IPF > > > > There was some discusion some time ago in ipf's mailing list. I don't remember > > Darren's position on this. > > My perspective is that it best serves IPFilter for it to be like that. > > I'm not sure why it isn't, except to say that it's entirely possible that > I have applied a patch incorrectly. > > Darren But it's no so hard to move IpHack section in ip_input.c to call after IPFW proxessing? In this way we can keep all of the functionality all of IPFW, IPFilter and IPNAT. Because now people who want to use IPNAT with his kernel processing (versus NATd with userland processing) forced to use IPFilter and fully rebuild their firewall. It's some trouble with this changes in ip_input.c processing ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030606124418.A33769>