On Sun, 3 Mar 2002 [EMAIL PROTECTED] wrote: =>On Sun, Mar 03, 2002 at 10:22:55PM -0500, Steven W. Orr wrote: =>> I'm getting some firewall messages here and I'm suspecting that they're =>> not attacks; that they are some fault in the firewall. =>> =>> Mar 2 21:07:29 saturn kernel: TCP drop IN=eth0 OUT= =>> MAC=00:e0:81:05:43:80:00:30:19:31:73:a8:08:00 SRC=66.120.90.134 =>> DST=146.115.228.77 LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP =>> SPT=80 DPT=35854 WINDOW=0 RES=0x00 RST URGP=0 => =>You're correct, they're probably not attacks. The problem is that the =>conntrack expires before both ends agree that the connection is closed. => =>Unfortunately, it's at your end. You could try to correct it by extending =>the TCP conntrack timeouts in the source and recompiling, but the tradeoff =>is that you'll have more connections consuming memory for longer, =>especially if the remote host up and dies. => =>You could also put in a few rules to ignore the RST packets and reset the =>other wayward packets. This would certainly be more friendly to the remote =>hosts that are waiting for a reply. (Out of curiosity, is the =>--reject-with tcp-reset rate-limited?) Well this is actually more progress than I hoped to get.
If I wanted to "extend the TCP conntrack timeouts in the source and recompiling" how would I do this? Or should the firewall hits I'm getting be considered to be harmless? Bob: Can you tell me if the --reject-with tcp-reset is rate limited? (I don't really understand it yet.) -- -Time flies like the wind. Fruit flies like a banana. Stranger things have - -happened but none stranger than this. Does your driver's license say Organ -Donor?Black holes are where God divided by zero. Listen to me! We are all- -individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED]
