Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #173603

Re: ICMPv6 and the conntrack table

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Hi,

Am 08.10.16 um 23:19 schrieb Henrique de Moraes Holschuh:
> 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?
Until that the host had not a configured IPv6 address. So I guess that
was Ipv6 autoconfiguration.

> 
>> 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.
> 
That helped me the most.
So it was really to the rescue.

>> $ 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).
> 
my provider offered me a public IPv6 address so I configured it and
disabled everything about DAD etc.

>> 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.
There are some packages which are not shown in the conntrack module. But
I couldn't figure out yet which and which not.
For example echo-requests will be shown.

> 
>> 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 thought ip route cache flush would flush the hole cache but it did
only for v4. That make it hard for me to debug because until that I was
not aware of net.ipv6.route.mtu_expires which is per default 600s.
> 
> 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.
I don't need neighbor discovery. So as mentioned I switched it off.
In fact I sticked pretty much to this guide[1] causes my server is a
standalone box.

[1]
https://www.ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf

Cheers
Flo

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

ICMPv6 and the conntrack table Florian Pelgrim <florian.pelgrim@craneworks.de> - 2016-10-08 20:20 +0200
  Re: ICMPv6 and the conntrack table Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-08 23:30 +0200
    Re: ICMPv6 and the conntrack table Florian Pelgrim <florian.pelgrim@craneworks.de> - 2016-10-19 17:50 +0200
  Re: ICMPv6 and the conntrack table Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-10-09 10:00 +0200
    Re: ICMPv6 and the conntrack table Florian Pelgrim <florian.pelgrim@craneworks.de> - 2016-10-19 17:50 +0200
      Re: ICMPv6 and the conntrack table Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-20 03:10 +0200

csiph-web