Patrick Welche wrote:
> Should ipnat's statistics really be monotonically increasing?
> 
> # ipnat -s
> mapped  in      17877109        out     15501105
> added   442065  expired 0
> no memory       14499   bad nat 19
> inuse   2491
^^^^^^^^^^^^^^
The inuse count seems to be the critical statistic for me. When I was 
using my acorn32 machine as a firewall it would get to about 5000 inuse 
before panicing due to lack of kmem address space. This was only an 
issue when using a bittorrent client.

I've now switched to a Soekris i386 box which seems to handle about 7500 
inuse connections without problems. Not found anything that can push my 
configuration any further than this in normal use.

In my experience the NAT timeouts (especially for UDP connections) are 
far longer than the same state timeouts in the ipf code. It may be 
possible to configure ipnat to timeout these NAT entries more quickly 
but config options that may have done this have no documentation at all!


> There comes a point where it seems one can't make new connections (as in
> you have to be lucky, or try often). The ipf side of things is fine..
> The "no memory" part above looks worrying - what type of memory is ipnat
> running out of? What can one do about it?
>
No memory means unable to allocate space for the NAT table entry. Kernel 
memory address space (and physical RAM) seem to be the limiting factor here.

Mike