"new not syn" packets.. false positive?

"new not syn" packets.. false positive?

[Technical Support]

Using Linux kernel 2.6.26 and iptables with this rule....

iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

...a certain group of known reputable sites have a copious number of packets 
dropped by that rule.  A capture of a conversation with one of those sites 
via Wireshark indicated that the following was the offending packet...

TCP      [TCP Window Update] http > 58666 [ACK] Seq=1 Ack=1 Win=1049248 Len=0 
TSV=1194040538 TSER=2055704

While this group of known sites accounts for 99% of all packets stopped by 
the 'new not syn' rule above, they suggest that it's a problem in our 
firewalling or TCP.implementation.  Their sites are a client/server operation 
where remote clients connect to their servers irregularly to send and receive 
data via HTTP.  I suspect the problem  lies somewhere in their server 
software, but knowing just enough about networking to be mildly dangerous I 
can't say that with any authority.  If the above infomation is pertinent, or 
if further data from the sniffer or kernel log would be useful, please let me 
know and I'll provide what I can. Thanks in advance.

Chuck Logan

Re: "new not syn" packets.. false positive?

[Paul Evans]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

'not syn' packets are any TCP packets that don't contain the SYN flag.

"NEW" packets are ones for which conntrack cannot find an existing
entry in the conntrack table.

Asymmetric routing, routing changes, timeouts, evictions from the table
caused by large amounts of traffic.. All of these could be reasons why
an entry doesn't exist in the table for a non-SYN packet.

-- 
Paul Evans <paul@mxtelecom.com>
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: "new not syn" packets.. false positive?

[Technical Support]

  Paul Evans replied:
> 'not syn' packets are any TCP packets that don't contain the SYN flag.
> "NEW" packets are ones for which conntrack cannot find an existing
> entry in the conntrack table.

Thanks, Paul.  I guess with all that said the question I still have is, is it 
safe to assume that there is a problem on the remote end, given that with 
virtually every contact with those sites, at least one packet is always 
dropped per the 'new not syn' rule?  Or is it still possible that, regardless 
of the frequency of the dropped packets from those sites, that there still 
could be a 'legitimate' cause for it to happen?  I'm just trying to get out 
of being the damp middle-man in a whizzing contest between the clients and 
the mighty keepers of the servers. :)  Thanks for the reply and info!

Chuck Logan