From owner-freebsd-net Sun Jan 27 7:41:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id EB0A337B400 for ; Sun, 27 Jan 2002 07:41:22 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g0RFfGw67547 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Sun, 27 Jan 2002 10:41:18 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020127163105.01e35eb0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Jan 2002 16:50:48 +0100 To: "Matthew Emmerton" From: "Rogier R. Mulhuijzen" Subject: Re: natd restart Cc: "BSD NET-List" In-Reply-To: <00b501c1a742$9a89d950$1200a8c0@gsicomp.on.ca> References: <003c01c1a701$da5209e0$1200a8c0@gsicomp.on.ca> <20020127101854.B267@idefix.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 (order of quoted mail slightly altered) >I'm looking at making natd into a kernel option ("options IPNAT") and using >a combination of sysctls and a front-end program to manage how nat operates, >much like "options IPFIREWALL" and ipfw works today. I've been kicking around the idea of making it a netgraph node. And I know several other people have too. >Not yet. One of the things that I don't like about this patch is that old >rules still stay around (re-reading the configuration will only modify >existing rules and add new rules.) I'm also taking a lot of flak on my side >of the fence since NAT runs as a userland process, so every packet gets >copied between the kernel and userland twice (once on the way in, once on >the way out.) Apparently Linux doesn't do this. libalias is very nice, natd to me has a hackey feeling to it. Try setting up a firewall that nats and uses dynamic rules.... I haven't been able to, have had to rely on natd to do my state checking, resulting in ipfw rule lists that are not easily read by the layman. So maybe that's another reason to re-evaluate our current NAT solution. Would it be hard to keep using libalias? I know we can't just link against userland libraries in kernel land, but would there be much difficulty in making use of the exact same code? Because the beauty of having libalias is of course the -nat switch on ppp for instance.... Then again, ppp already knows about Netgraph, so if it's done as a netgraph node, that might as well be converted =) Does anything but ppp and natd use libalias? >This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and >keep those Linux people from bashing us (or me, at least.) Would be very nice indeed =) BTW, I hereby volunteer as junior kernel hacker to help on this project. To me NAT has been one of the strongpoints of FreeBSD (very nice features, works very well with FTP/DCC/PPTP) and making it even better would be a pleasure. >-- >Matt Emmerton Just my $0.02, Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message