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
Attachment:
signature.asc
Description: OpenPGP digital signature