From owner-freebsd-net Sun Jan 27 10:17:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by hub.freebsd.org (Postfix) with ESMTP id 3379D37B41F for ; Sun, 27 Jan 2002 10:17:22 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.128.21]) by tomts10-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20020127181721.TJVQ3328.tomts10-srv.bellnexxia.net@xena.gsicomp.on.ca>; Sun, 27 Jan 2002 13:17:21 -0500 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id g0RI7HX41071; Sun, 27 Jan 2002 13:07:21 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <002001c1a75e$dca52760$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Rogier R. Mulhuijzen" Cc: "BSD NET-List" References: <003c01c1a701$da5209e0$1200a8c0@gsicomp.on.ca> <20020127101854.B267@idefix.local> <5.1.0.14.0.20020127163105.01e35eb0@mail.drwilco.net> Subject: Re: natd restart Date: Sun, 27 Jan 2002 13:17:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 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 told that 'options IPFILTER' with ipf(8) and ipnat(8) does NAT in the kernel, whereas 'options IPDIVERT' and ipfw(8) and natd(8) is a userland solution. > I've been kicking around the idea of making it a netgraph node. And I know > several other people have too. This is probably the easiest starting point. > 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. See the alternatives above. Perhaps ipf might handle dynamic rules better? ( I don't know, since I've used ipfw since I started using FreeBSD.) > 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.... It would be nice to keep libalias functionality, since it is a very easy interface to use. > Does anything but ppp and natd use libalias? A quick check of the sources says no. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message