The problem is, that there is no easy answer. The packets are probably dropped due to incorrect sequence numbers or TCP flags. Or they might arrive untimely. Netfilter will then not see them as part of an established connection and mark them invalid. The point is, that many application servers (especially those from that horrible company in Redmond) do not fully adhere RFC's, or they are configured incorrectly. This often causes issues with firewalls dropping packes. There also might be incorrectly configured networking devices (routers, concetrators etc) in between the connection end-points. I would say the change is about 0-1% that it is netfilter causing the issue. It just inspects all the packet conforming RFC's, the way it should be done. There is therefor a 99-100% change the problem lies elsewhere and most likely it's incorrectly working or configured clients and/or servers. Though you probably will not find this answer useful in solving your problem, I hope it still clarifies some things. -Sietse ________________________________ From: netfilter-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Justin Schoeman Sent: Wed 24-May-06 15:25 To: netfilter@xxxxxxxxxxxxxxxxxxx Subject: Connection tracking looses packets? Hi all, I am having problems with a firewall here. The basic configuration works perfectly, but we have occasional problems with DNAT. Long running sessions (we have found the problem on ftp, http, pop and smtp sessions) occasionally stall, and transfer no more data. Looking at the firewall logs, I see: INVALID NAT: IN=eth3 OUT= MAC=00:02:55:d6:eb:ae:00:11:bc:25:96:80:08:00 SRC=196.x.x.x DST=10.50.18.22 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=37995 PROTO=TCP SPT=57952 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0 (This is logged by a -m state --state INVALID rule in the mangle table.) The packet is then not natted, but drops into the INPUT chain for the firewall itself, where it is dropped. This seems to be the problem, as there are always one or more of these messages on a stalled connection. Looking at /proc/net/ip_conntrack immediately after the above message is logged, I see: tcp 6 295 ESTABLISHED src=196.x.x.x dst=10.50.18.22 sport=57952 dport=80 packets=5 bytes=633 src=192.168.1.22 dst=196.x.x.x sport=80 dport=57952 packets=12 bytes=13793 [ASSURED] mark=0 use=1 So the connection seems to be valid. Any idea why this packet may be dropped, or are there other possible reasons why the connection may be stalling? Googling reveals a significant number of people having problems with random stalls within a connection, but so far I have not seen a single answer to the problem. Any help/advice will be greatly appreciated. Thanks, Justin
