Hi Peter et al, Haven't used NAT with IPF, but do run host filters, and I have seen existing SSH sessions hang; seems to be when there's lots of TCP sessions being created (e.g. automated testing of web apps). Thought I saw a session disappear from "ipfstat -sl", but didn't get to capture it.
Doing web load testing: Tried increasing IPSTATE_SIZE and IPSTATE_MAX in ip_state.h (by 7x - too big?) but just now got a panic in unix:mutex_vector_enter+260 called by ipf:fr_tcpstate+144 (also tried changing fr_statesize & fr_statemax in /etc/system; got panic "sooner?" -- assumed that's not supposed to work?) Got lots (1,000s) of ipfstat -s "maximum", wondered if state table cleaning up was a bit aggressive? bug? Thinking about reducing some ICMP & TCP timer values... These tests used ipf 4.1.23 pfil 2.1.13 on Solaris 9 9/05. We've been running ipf 4.1.8 + pfil 2.1.6 and earlier for ages with few/no problems, but not under as high a network load either. Mix of Sun V240 to F25K. Rgds, Stuart. Stuart Remphrey RMIT ITS Infrastructure Services - Unix Systems Phone (03) 992 55 070 (or extension 55070) >>> Peter Jeremy <[EMAIL PROTECTED]> 26/06/07 5:56 PM >>> I'm using a FreeBSD 6.2 host (IPfilter 4.1.13) as a NAT/router to connect our test environment (with about 60 hosts) NAT'd onto our corporate network. I've recently noticed some problems with TCP connection setups failing and traced it to the NAT host - the SYN requests go in one side and nothing comes out the other side. We have been doing some SNMP testing, sending traps from some of the test machines to couple of hosts outside the NAT region. Looking at a NAT monitor trace, each trap is generated from a different source port and therefore instantiates a new NAT state object. The total load was just over 19 NAT:MAP and NAT:BIMAP records/sec. There were just under 11,000 NAT mappings at any time. When we reduced the number of SNMP traps being generated (to a total load of 3.6 NAT:MAP and NAT:BIMAP records/sec and about 2600 NAT mappings), the problem went away. "ipnat -s" showed no "no memory" failures (though there was a significant rate of "bad nat" failures). The box was showing no signs of stress, no messages were being logged and mbuf etc utilisation were all OK so I believe this is a bug in IPfilter. I have tcpdump's showing both sides of the router when connection failures occur - the SYN packets arrive and retry normally but no packets exit the other side. The fact that the retries are all lost suggests that the failure is not transient but suggests a problem in the way IPfilter is hashing packets. (This may be related to a problem I've previously reported where IPfilter appears to "lose" state information for existing connections). Has anyone else seen anything similar? -- Peter Jeremy
