Date: Sun, 22 Oct 2006 16:09:08 +0200 From: Paolo Pisati <piso@freebsd.org> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: net@freebsd.org Subject: Re: Avoiding natd overhead Message-ID: <20061022140908.GA1275@tin.it> In-Reply-To: <20061021095808.GH75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 21, 2006 at 04:58:08AM -0500, Matthew D. Fuller wrote: > On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of > Brett Glass, and lo! it spake thus: > > > > How can I replace just the functionality of natd without moving to > > an entirely new firewall? Can I still select which packets are > > routed to the NAT engine, and when this occurs during the processing > > of the packet? > > Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might > fit here. It should move the NAT'ing into the kernel and save all the > context switches and copies, and (what has me more interested) make it > much easier to change port forwarding and other rules. The worst > thing about natd for me isn't performance, it's that I have to blow > away all the state to change anything. > > I think some of the support has been brought in, at least to -CURRENT, > but I'm not sure, and I'm pretty sure it isn't in RELENG_6 or earlier. > Paolo? i've imported in CURRENT the libalias side of work (mainly modules), while for the ipfw part (nat&c), there are two things still to talk about: 1) locking of libalias: put an embedded lock into libalias and grab it into the different LibAlias* functions? or leave it outside the library? 2) libalias+nat in kernel: Glebius suggested to make the nat part truly independent through ipfw_nat.ko. libalias+ipfw nat add 80kb to the entire kernel. bye -- Paolo Piso's first law: nothing works as expected!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061022140908.GA1275>