Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

martin f krafft a écrit :
> also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.03.1707 +0200]:
> 
>>I'm not sure what you both mean. I tested the IPv6 conntrack on vanilla  
>>2.6.20 and 2.6.24 kernels built from kernel.org sources and everything  
>>worked as expected :
> 
> 
> I agree, it works if you don't have INVALID at all, but try:
> 
>   -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>   -A INPUT -m state --state INVALID -j DROP
>   -A INPUT -m state --state NEW -j in-new
> 
> and this will match echo-requests on my 2.6.24. echo-replies get
> matched by the first rule, but echo-requests should be NEW, not
> INVALID.
> 
> 
>>I do not see a reason why 2.6.22 would behave differently. Maybe
>>there is something special in Debian kernels ?
> 
> 
> This bug I see with 2.6.18

Of course, Debian's 2.6.18 does not support IPv6 conntrack.

> and someone else with 2.6.22.

Nicolas ? He just wrote he couldn't reproduce it.

> It's
> a different issue than what this thread is about: that pre-2.6.24
> kernels don't seem to register OUTGOING packets in the connection
> table.

This is higly unlikely IMHO. People would have noticed it.

> Or are you saying that if you ping6 from the machine with the
> iptables rules to somewhere else, the echo-reply gets matched by
> RELATED or ESTABLISHED?

Yes, of course. The outgoing echo request is in the NEW state and the 
incoming echo reply is in the ESTABLISHED state. Same with an incoming 
echo request.

> Because it certainly does *not* here.
> 
> $ ping6 ipv6.aerasec.de(2001:a60:9002:1::184:1) yields:
> 
> [INPUT6]: IN=eth2 OUT= MAC=00:16:3e:46:5a:86:00:0e:d6:b8:dc:1b:86:dd
> SRC=2001:0a60:9002:0001:0000:0000:0184:0001
> DST=2001:1620:2004:0000:0000:0000:0000:0002 LEN=104 TC=0 HOPLIMIT=57
> FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=34094 SEQ=1
> 
> which is logged after falling through the end of the chain and *not*
> being matched by ESTABLISHED,RELATED. Note that the source address
> is the same as the destination address to which I sent the
> echo-request.

There must be something wrong with your kernel.
Here is what I get :

[NEW]   IN= OUT=eth2 SRC=2001:07a8:6d23:#### 
DST=2001:0a60:9002:0001:0000:0000:0184:0001 LEN=104 TC=0 HOPLIMIT=64 
FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55565 SEQ=1

[ESTAB] IN=eth2 OUT= MAC=#### 
SRC=2001:0a60:9002:0001:0000:0000:0184:0001 DST=2001:07a8:6d23:#### 
LEN=104 TC=0 HOPLIMIT=53 FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=55565 
SEQ=1

with the following test ruleset :

ip6tables -t mangle -N logstate
ip6tables -t mangle -A logstate -m state --state NEW -j LOG \
   --log-prefix "[NEW]   "
ip6tables -t mangle -A logstate -m state --state ESTABLISHED -j LOG \
   --log-prefix "[ESTAB] "
ip6tables -t mangle -A logstate -m state --state RELATED -j LOG \
   --log-prefix "[RELAT] "
ip6tables -t mangle -A logstate -m state --state INVALID -j LOG \
   --log-prefix "[INVAL] "
ip6tables -t mangle -A logstate -m state --state UNTRACKED -j LOG \
   --log-prefix "[UNTRA] "

ip6tables -t mangle -A PREROUTING -j logstate
ip6tables -t mangle -A OUTPUT -j logstate