|
||||||||
On Fri, 30 Jul 2004 eric at ericmagny dot com wrote: > When I pick a look to my filter log, I can see a lot of these errors: > > Jul 30 16:19:25 router1 ipmon[75]: 16:19:25.174400 sis1 @0:18 b x.x.209.66,80 - > > x.x.209.75,1579 PR tcp len 20 48 -AS IN > Jul 30 16:19:25 router1 ipmon[75]: 16:19:25.174452 sis1 @0:18 b x.x.209.66,80 - > > x.x.209.75,1577 PR tcp len 20 48 -AS IN IPFilter is picky about sequence and ACK numbers, and unfortunately doesn't include them in the log. I haven't seen failures on SYN/ACK packets before - is it possible the HTTP server in question is actually buggy? > Jul 30 16:26:46 router1 ipmon[75]: 16:26:45.484354 sis1 @0:14 b > x.x.24.181,5554 -> x.x.71.229,4331 PR tcp len 20 40 -AR IN > Jul 30 16:26:47 router1 ipmon[75]: 16:26:46.156576 sis1 @0:14 b > x.x.24.181,9898 -> x.x.71.229,4790 PR tcp len 20 40 -AR IN [...] These I have seen before, although not reproducibly. I suspect another IPFilter bug (there seem to be quite a number of them). The good news is that the presence of RST indicates that it's an "effectively dead" connection anyway. > Jul 30 16:28:39 router1 ipmon[75]: 16:28:38.775352 4x sis0 @0:18 b > 142.217.205.70,80 -> x.x.209.76,1100 PR tcp len 20 762 -A IN I've also seen these, though as usual one can't tell from the log whether the packet was really bad. [...] > I'm using now Monowall 1.1b15 (previously last release, I try beta to solve > this probs..) That could fix *some* cases. :-) The chronology of some *known* problems in IPFilter is: m0n0wall IPFilter ACK check ICMP checksum (NAT) -------- -------- --------- ------------------- 1.0 3.4.31 ignores wscale OK 1.1b1-1.1b13 3.4.33 uses wrong wscale broken 1.1b14-1.1b16 3.4.33+pat uses wscale broken I've sent Manuel the fix for the ICMP checksum problem, so it will probably be fixed in the next beta. I haven't identified the cause of the other troubles, other than in one case where the blocking was defintely harmless. > Last thing, I'm using monowall as 'real' router. No NAT. On all 3 interface Then you probably aren't affected by the ICMP checksum problem. :-) > there is a public IP add. And when one error occurs in filter log, a web > page (or outlook freeze in retreiving mail) cannot be displayed in browser. I've not seen that exact symptom, although I have seen it stop responding in a case where it had probably gotten into a routing loop. Is it really *one* error in the log, or a flurry of them that are keeping it bogged down with logging? Fred Wright |