Re: conntrack bug?

[Pablo Neira Ayuso <pablo@netfilter.org>]

Jason Stubbs wrote:
> Hi,
> 
> While testing patches for IPVS, I found a strange behaviour of conntrack that 
> happens on an unpatched kernel too (2.6.24.4). Given the following rules:
> 
> iptables -A FORWARD -p tcp -d 192.168.1.3 --dport 80 \
>                     -m state --state NEW -j ACCEPT
> iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -P FORWARD DROP
> 
> And a network setup where replies from 192.168.1.3 don't go via the same 
> machine - ie, they appear to be being dropped - the following conntrack entry 
> appears when sending only an ACK packet to 192.168.1.3:
> 
> ipv4     2 tcp      6 431684 ESTABLISHED src=192.168.0.104 dst=192.168.1.3 
> sport=12345 dport=80 packets=2 bytes=95 [UNREPLIED] src=192.168.1.3 
> dst=192.168.0.104 sport=80 dport=12345 packets=0 bytes=0 mark=0 use=1
> 
> If a SYN has been sent the following state appears and no traffic (including 
> an ACK) is allowed to pass:
> 
> ipv4     2 tcp      6 119 SYN_SENT src=192.168.0.104 dst=192.168.1.3 
> sport=23456 dport=80 packets=1 bytes=50 [UNREPLIED] src=192.168.1.3 
> dst=192.168.0.104 sport=80 dport=23456 packets=0 bytes=0 mark=0 use=1
> 
> I would think that behaviour to be correct, but an entry appearing when only 
> an ACK packet has been sent seems wrong. Is it a bug or intentional?

Probably cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose says 1?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers