Re: ICMPv6 and the conntrack table
On Sat, 08 Oct 2016, Florian Pelgrim wrote:
> This is the expected result without a firewall:
> $ ip route get 2404:6800:400a:800::1012
> 2404:6800:400a:800::1012 from :: via fe80::1 dev eth0 src
> fe80::d481:11ff:feee:4908 metric 0
> cache hoplimit 64
Why do you have a default route via fe80::1 ? Where did it came from?
> Now I setup some basic ip6tables firewall settings.
"Basic" IPv6 firewalling is, unfortunately, anything but basic... mostly
because ICMPv6 overloads both L2 and L3 control-plane functions.
RFC 4890 "to the rescue" :-(
https://tools.ietf.org/html/rfc4890
*do* read the errata to RFC4890, it is relevant if you use the iptable
examples.
> $ ip route get 2404:6800:400a:800::1012
> unreachable 2404:6800:400a:800::1012 from :: dev lo table unspec proto
> kernel src fe80::d481:11ff:feee:4908 metric 4294967295 error -101
Your firewalling apparently broke the IPv6 DAD (which requires a subset
of ICMPv6, and multicast). That would cause any interface address of
link-local scope or higher to be declared invalid (for failing DAD), and
unusable.
And the kernel is not about to send locally-originated packets with an
invalid source address (unless you override it with evil black magic).
> Uh? So lets look this up in conntrack. The results are pretty low...
> There is nothing to see. No v6 package in any state.
I don't think link-local L2 control-plane traffic ends up creating
conntrack entries, at least not in any reliable way (it can't).
It is best to do stateless firewalling for everything L2, including the
subset of ICMPv6 that deals with L2 functions and multicast control.
> And another question is how can I flush the cached results from `ip
> route get`? `ip route cache flush` is not working since I guess they
> changed the caching in kernel version 3.6.
"ip route cache flush" is supposed to still work, yes. But I don't
think your problem is in the routing table (or cache) in the first
place.
I'd try to fix the IPv6 DAD issues, first. Check the output of "ip -6
addr" for every relevant interface... it should say when an address is
invalid for failing DAD, AFAIK.
After that, keep in mind that the forwarding destination for link-local
addresses must be resolved through neighbor tables, not routing tables.
You can manipulate the IPv6 neighbor table using "ip -6 neigh". For
more details, refer to RFCs 4007 and 4291.
--
Henrique Holschuh
Reply to: