Peter Jeremy wrote:
> On 2007-Feb-17 13:39:06 +1100, Peter Jeremy <peter@turion.vk2pj.dyndns.org>
> 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
|