Date: Wed, 30 Dec 1998 04:11:24 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Eric J. Schwertfeger" <ejs@bfd.com> Cc: current@FreeBSD.ORG Subject: Re: wanton Atticizing is bad Message-ID: <199812292011.EAA82011@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 29 Dec 1998 09:05:18 PST." <Pine.BSF.4.05.9812290853110.22573-100000@harlie.bfd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Eric J. Schwertfeger" wrote: > > > Date: Mon, 28 Dec 1998 17:14:01 -0500 > > From: Christian Kuhtz <ck@ns1.adsu.bellsouth.com> > > Subject: Re: wanton Atticizing is bad > > > > On Mon, Dec 28, 1998 at 04:04:16PM -0600, Phillip Salzman wrote: > > > > You can do that with natd. > > > > > > That is possible, but not logical. Say you have 2000 > > > dialup users attempting to access the web at the same time... all > > > coming from different IP addresses -- would you want the packet > > > scanning to go at the Cisco, or at the NATd? Its simple to do > > > a transparent proxy from the cisco, and does not require too much on > > > the squid side (IPFILTER), with less on the router. > > > > I thought the issue was, given IPFILTER or IPFW, can we do everything with > > IPFW that IPFILTER and other kludges did? So that we can start to phase > > out IPFILTER. > > There's two areas that IPFILTER seems to work better than IPFW, and both > are NAT-related. I've been discussing this with various folks. What I see as the "best" solution to overcome the problem of a poorly maintained (and old) copy in the tree is to make a port out of it and remove the bulk of the code from the tree. What this gets us: - upgrading to the latest release becomes easier. - getting ipfilter in the src tree was like fitting a square peg into a round hole. It's an unhappy arrangement to say the least. - using a loadable kernel module from the port at startup time gets us pretty much the same functionality as the in-kernel version. - hopefully a clean cutover from the old to the current ipfilter. The only folks directly inconvenienced would be router floppy type people. Of course there will be bumps along the way, but I think this is the best outcome considering that the copy in the tree is getting stale quickly, and leaving the hooks there (or implementing pfil) makes modules the job of the pot a lot easier. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812292011.EAA82011>
