conntrack bug?

conntrack bug?

[Jason Stubbs]

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?

-- 
Jason Stubbs <j.stubbs@linkthink.co.jp>
LINKTHINK INC.
東京都渋谷区桜ヶ丘町22-14 N.E.S S棟 3F
TEL 03-5728-4772  FAX 03-5728-4773
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conntrack bug?

[Jason Stubbs]

On Friday 18 April 2008 13:43:25 Jason Stubbs wrote:
> 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?

It seems it's intentional. After a bit more searching I finally found out 
about the net.netfilter.nf_conntrack_tcp_loose sysctl setting. Is this 
setting (and the others) documented anywhere other than the source?

-- 
Jason Stubbs <j.stubbs@linkthink.co.jp>
LINKTHINK INC.
東京都渋谷区桜ヶ丘町22-14 N.E.S S棟 3F
TEL 03-5728-4772  FAX 03-5728-4773
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conntrack bug?

[Pablo Neira Ayuso]

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