--- Ralf Spenneberg <lists@xxxxxxxxxxxxxx> schrieb: > No bits in the header. It is simply matching the IP addresses, protocol > and ports. If you add the TCP-Window-Tracking patch it does more. > At the moment TCP is handled just like UDP, ICMP, and generic > protocols. > > If the client behind the firewall sends an ACK the connection is > automatically picked up by iptables. OK, i see (after *reading* some netfilter documentation as well....RTFM...sorry). I thought that netfilter is doing *real* tcp state tracking which is not true. to quote Joszef Kadlecsik (from "connection tracking" by James C. Stephens): ---- snip ---- "When a packet with the SYN+ACK flags set arrives in response to a packet with SYN set the connection tracking thinks: "I have been just seeing a packet with SYN+ACK which answers a SYN I had previously seen, so this is an ESTABLISHED connection." The important point here is that the conntrack states are not equivalent to tcp states. We have already seen that a connection doesn't achieve the tcp connection status of ESTABLISHED until the ACK after the SYN+ACK has been received. The representation of the tcp connection states in the state table is purely for timeouts. You can prove this to yourself by sending an ACK packet through your firewall to a non-existent machine (so that you don't get the RST back). It will create a state table entry no problem because it it is the first packet of a connection and so is treated as NEW (the entry will not be marked as ASSURED though). ---- snip ---- Well, that explains it. thank you very much! __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
