Avoiding natd overhead

[Anton Yuzhaninov]

Saturday, October 21, 2006, 1:58:08 PM, Matthew D. Fuller wrote:

MDF> On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of
MDF> 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?

MDF> Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might
MDF> fit here.  It should move the NAT'ing into the kernel and save all the
MDF> context switches and copies, and (what has me more interested) make it
MDF> much easier to change port forwarding and other rules.  The worst
MDF> thing about natd for me isn't performance, it's that I have to blow
MDF> away all the state to change anything.

libalis still have big overhead comparing to ipnat:

1. libalias allocate memory for create each new entry in NAT table.
   libalias use linear search in linked list to find entry in table.
   It very slow when you have thousands simultaneous connections via
   nat

2. ipnat allocate all memory at startup. It better.
   ipnat uses hash table to fine entry in nat table - it mach faster
   in heavy loaded case.

An next. As I can se libalias not limit maximum size of used memory.
When users generate many simultaneous connections (e. g. worm or net
scan), libalias may exhaust all kernel memory and so trigger panic.

-- 
 WBR, Anton Yuzhaninov