I am running a kernel 2.4.18 (unpatched) on RedHat 7.2 (using RedHat's 1.2.4 userspace package). My firewall is running NAT, using the MASQUERADE target and accepts packets with ESTABLISHED and RELATED states in the FORWARD chain. My Internet connection is over ADSL. All web access goes through a transparent proxy (NetCache NetApp/5.2.1R1D3).
I am seeing a fair number of rejected packet logs like the following: IN=ppp0 OUT= MAC= SRC=aaa.bbb.ccc.ddd DST=eee.fff.ggg.hhh LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=51135 PROTO=TCP SPT=80 DPT=2100 WINDOW=32768 RES=0x00 ACK RST URGP=0 All the packets come from web sites that have recently been visited and appear to be the closing down of the TCP connection. It seems that the netfilter connection tracking is clearing up the connection before it actually gets closed. netstat on the client machine for the connection shows the connection in the state CLOSE_WAIT. So far I have only been seeing these logs for http connections on port 80. I have been searching around for anything on this problem and didn't find a lot. About the only suggestion I did see was to try modifying the CLOSE_WAIT value (from 60 SECS to 2 MINS) in tcp_timeouts in ip_conntrack_proto_tcp.c. > diff -urN -I \$.*\$ --exclude TAGS -X > /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal > linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c > working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c > --- linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c > Sun Apr 29 06:17:11 2001 > +++ working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c > Wed Oct 24 14:23:26 2001 > @@ -55,7 +55,7 @@ > 2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */ > 2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */ > 10 SECS, /* TCP_CONNTRACK_CLOSE, */ > - 60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */ > + 2 MINS, /* TCP_CONNTRACK_CLOSE_WAIT, */ > 30 SECS, /* TCP_CONNTRACK_LAST_ACK, */ > 2 MINS, /* TCP_CONNTRACK_LISTEN, */ > }; (See http://groups.google.com/groups?hl=en&selm=20011028114500.A27656%40orthanc.cipherdyne.com) Is this a recommended course of action to stop these packets from being dropped? Are there any other solutions to the problem? Is there anything else in my networking configuration that could be causing the problem? Could the ISP's transparent proxy be causing the problem? Thanks, Philip Ross
