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 Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1136 +0200]:
> 
>>I noticed the same behaviour on Etch + kernel 2.6.22 (from
>>backports.org): ICMPv6 echo replies are matched by INVALID.
> 
> See http://marc.info/?l=netfilter&m=120717177831833&w=2
> And this is still the case with 2.6.24.

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 :

- ping6 :
ICMPv6 echo request -> NEW
ICMPv6 echo reply -> ESTABLISHED

- UDP packet to a closed port :
UDP packet -> NEW
ICMPv6 port unreachable -> RELATED

- TCP connection to a closed port :
TCP SYN -> NEW
TCP RST -> ESTABLISHED

- TCP connection to an open port :
TCP SYN -> NEW
TCP SYN/ACK and the following -> ESTABLISHED

I do not see a reason why 2.6.22 would behave differently. Maybe there 
is something special in Debian kernels ?

Did you check that the echo reply source address matches the echo reply 
destination address ? I observed that some kernels may reply using a 
different source address when the box/interface has several IPv6 
addresses. When this happens the reply gets the INVALID state of course.

However it appears that ICMPv6 types related to neighbor discovery 
(router advertisement, neighbor solicitation/advertisement...) are 
always in the INVALID state.