Peter Jeremy wrote: > ... > "ipnat -s" showed no "no memory" failures (though there was a > significant rate of "bad nat" failures). >
In this instance, what it probably amounts to is running out of unique address/port pairs on the outgoing side. To try and address this problem, make sure you have a rule like this first; map foo0 10.1.0.0/16 ->.0/32 portmap 1025:65535 tcp/udp It may also be a reference to the NAT hash bucket being too long.... to test this one, try "ipf -T fr_nat_maxbucket=100" and see if the problem you're seeing goes away. I'm hoping this is *not* the case though... The stats/reporting for NAT are quite bad at present - this will improve a lot for 5.1. Darren
