I am not sure you are fighting the same issue I was, but...

I was trying to load some very large block ranges using ipf
and was running out of memory. After much digging, I solved
the problem by increasing available resources in the kernel config
using the following swithches:

# VM Releated Options
options         NKMEMPAGES=65568
options         NMBCLUSTERS=32784

# RLIMIT Options
# more info in param.c and a tech-kern article
# http://mail-index.netbsd.org/tech-kern/2002/06/21/0030.html
options         MAXFILES=4096
options         NOFILE=4096

As I recall, it was the Rlimit options that got me what I wanted.

Keep in mind that I had plenty of ram available, but still snuck up
on my needs gradually. I think I blocked over 100,000 ip ranges
using ipf!

Sorry, but I've slept a few hundred times since then.
--gene


> 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
>