Re: conntrack-0.9.6 bug (?)

Re: conntrack-0.9.6 bug (?)

[Pablo Neira Ayuso]

Stefan Behte wrote:
> I managed to get the connection deleted before with:
> conntrack -D -s 212.202.252.50 -d 192.168.40.88 -p tcp --sport 23854
> --dport 22
> 
> It did not show up in conntrack -L -s 212.202.252.50 anymore, but was
> still in "ESTABLISHED" state, the packets kept flowing.
> 
> So thought, that might be an error?!
> 
> Also, this does not work:
> 
> [root@haq ~]# conntrack -L | grep "dport=22 "
> tcp      6 431999 ESTABLISHED src=192.168.0.2 dst=192.168.0.1 sport=22
> dport=33555 packets=11 bytes=1324 src=192.168.0.1 dst=192.168.0.2
> sport=33555 dport=22 packets=18 bytes=1272 [ASSURED] mark=0 use=1
> [root@haq ~]# conntrack -D -s 192.168.0.2 -d 192.168.0.1 -p tcp --sport
> 22 --dport 33555
> [root@haq ~]# conntrack -L | grep "dport=22 "
> tcp      6 431999 ESTABLISHED src=192.168.0.2 dst=192.168.0.1 sport=22
> dport=33555 packets=5 bytes=628 src=192.168.0.1 dst=192.168.0.2
> sport=33555 dport=22 packets=8 bytes=560 [ASSURED] mark=0 use=1
> 
> Or am I doing it all wrong?!
> If that is really a bug, where would be the appropriate place to file a
> bug report so that I do not have to bug you directly via mail (which
> might be regarded as inappropriate)?

Probably your stateful rule-set is not well-formed or you have the
connection pickup facility enabled
(/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal must be 0,
otherwise the connection tracking can recover connections from the
middle with no complain). There's an example of a sane and simple
stateful ruleset in [1].

Don't forget that the connection tracking system does not drop packets
by itself, you need a correct iptables configuration to enable the flow
deletion, otherwise it won't work.

[1] http://conntrack-tools.netfilter.org/testcase.html

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