TCP window tracking

From kadlec@blackhole.kfki.hu Mon Sep 17 10:29:14 2001
Date: Mon, 30 Oct 2000 13:31:30 +0100 (CET)
From: Jozsef Kadlecsik 
To: netfilter@samba.org
Subject: Re: TCP conntrack patch 

Hello,

On Tue, 29 Aug 2000, Rusty Russell wrote:

> First comments:
> 1) It'd be nice if rcv_ip now matched gen_ip wrt RST/ACK and WIN=.
> 
> 2) Changed testsuite/tools/Makefile to only set KERNEL_DIR if not set
>    (eg. I set it in my environment).
> 
> 3) I'd prefer to get rid of the old stuff altogether with your patch
>    (ie. blow away ORIGINAL_TCP_CONNTRACKS).
> 
> 4) s/DDEBUGP/DEBUGP/ to match the rest of the code.
> 
> 5) Under 
> +		/* Attempt to reopen a closed connection,
> +		 * reuse the entry. */
>    I prefer the approach taken by the patch-test1-ac22-tcp-fastconn,
>    so that the new connection goes through the tables again (for
>    tracking, logging, and in case the rules have changed).
> 
> 6) Consider changing adding a net_ratelimit() printk to the DEBUGP
>    when TCP packet found outside the window, so even without debugging
>    testers can see if there's a problem.

All of your comments are implemented now.

>         And I was surprised to find that your 18tcptrack.sh test
> passes perfectly without your patch installed!
>
>        If I were you I would append more tests to it, which test that
> it does actually mark stuff outside the window as invalid (ie. check
> that bad packets *don't* get through).

I added a longish negative test to the testsuite patch, which catches an
out of window packet.

Actually, at fixing the test scripts, one could generate negative tests
quite easily :-).

> > I just updated a netfilter firewall to kernel 2.4.0-test8 + all
> > patch-o-matic-patches.
> > 
> > Trying ftp-connections with ncftp from a nat'ed host behind the firewall
> > works, but if I try "ls" or "get" commands I get the following in the
> > firewall log (ftp
>
> TCP window tracking breaks ftp NAT (well, technically it's the other
> way around, but you get the idea).
> 
> The window tracking code needs to keep (at minimum) an offset/sequence
> point in each direction, since the sequence/ack numbers may be being
> adjusted by the ftp code.  Probably the entire packet mangling code
> "replace this pattern with this" should be moved to the tcp code.

I applied another approach to cope with TCP packets mangled by NAT: the
window of accepted acks are enlarged, so that the reply to the mangled
packet is accepted by conntrack. If the new conntrack implementation is
accepted, then all modules which mangles TCP packets must be corrected in
a similar way like ip_nat_ftp.c in this patch. 

The window scaling support was non-functional on my previous patch: now it
is fixed and tested as well.

[Huhh, that was a big delay. Sorry, we had a little overload here and I
simply haven't had time to fix the problems.]