Peter Jeremy wrote: > On 2007-Feb-17 13:39:06 +1100, Peter Jeremy <[EMAIL PROTECTED]> wrote: > >> I've recently upgraded my home firewall from FreeBSD 5.4 (IPfilter >> v3.4.35) to FreeBSD 6.2-RELEASE (IPfilter v4.1.13) and am now having >> problems with IPfilter randomly blocking packets on both the internal >> and external interfaces. >> > > I've done some more investigating and this appears to be related to > the "keep state"+window-scaling bugs that other people have mentioned: > FreeBSD 6.x uses window-scaling by default. > > I've tried taking the ip_state.c fixes from FreeBSD -current but this > has not solved the problems. I have found what appear to be two > distinct symptoms. > > Part of the problem is that FreeBSD is re-using source ports more > frequently than IPfilter can handle, but since the TCP standard allows > port re-use after 2 minutes, why is IPfilter blocking the following? > In both cases, there is more than 3 minutes between the socket being > cleanly torn down and the reuse attempt. "ipfstat -t" does not show > any state being retained after the teardown. >
Can you include the state table log output in your ipfilter logs? Either start ipmon with "-a" (get ipf, ipnat and state logs) or "-o IS' to get just ipf and state. > ... > 08:03:47.133049 IP 192.168.234.64.50502 > 192.168.234.1.22: . ack 434039282 > win 33303 <nop,nop,timestamp 58307625 2215684> > > 08:07:17.907597 IP 192.168.234.64.50502 > 192.168.234.1.22: S > 2277772418:2277772418(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp > 58518399 0,sackOK,eol> > ... > Mar 3 08:07:18 fwall ipmon[575]: 08:07:17.907881 fxp1 @10:4 b > 192.168.234.64,50502 -> 192.168.234.1,22 PR tcp len 20 64 -S IN OOW > ... > The other problem occurs during data transfer with IPfilter > arbitrarily blocking the connection, even though "ipfstat -t" showed > that a state entry was present. This is more serious because it is > effectively preventing large data transfers. The following examples > show pairs of connections being broken at similar times - other > connections remain up (though they aren't showing any data transfer > at this time). > ... > This is tricker. In the first part of this log you have: 08:10:00.610395 IP 192.168.234.64.59384 > 192.168.234.1.22: . ack 4044806860 win 33168 <nop,nop,timestamp 58681107 2589277> 08:10:00.610702 IP 192.168.234.64.59384 > 192.168.234.1.22: F 3102426529:3102426529(0) ack 4044806860 win 33168 <nop,nop,timestamp 58681107 2589277> 08:10:00.611106 IP 192.168.234.1.22 > 192.168.234.64.59384: . ack 3102426530 win 33303 <nop,nop,timestamp 2589278 58681107> Mar 3 08:10:00 fwall sshd[2147]: fatal: Write failed: Network is unreachable Mar 3 08:10:00 fwall ipmon[575]: 08:10:00.306431 fxp1 @20:4 b 192.168.234.1,22 -> 192.168.234.64,59384 PR tcp len 20 324 -AP OUT Mar 3 08:10:00 fwall ipmon[575]: 08:10:00.358704 2x fxp1 @20:4 b 192.168.234.1,22 -> 192.168.234.64,59384 PR tcp len 20 324 -AFP OUT which makes it look like some tail end packets are being blocked, not those in the middle of the connection? If you can capture a trace with "tcpdump -s 1536 -w foo ..." and send it my way, that'd be great. Darren
