0

I have a Arch Linux system where link-local packets are not being routed properly. I have 4 interfaces on this machine (wan, lan0, lan1 and lan2). All three of the lanX interfaces are bridged together.

When I run

ping6 fe80::8e89:a5ff:feda:fa%lan

or

ping6 ff02::1%lan

the packets are being sent out the wan interface instead of the lan bridge and lan2 interface (which is directly connected to the machine with that fe80 address). The kernel seems to be disregarding the IPv6 scope id being specified. I have double checked that I do not have a route for the fe80 address (there is however one ff0::/8 route per IPv6 device but this is the same on other systems of mine where providing the scope works).

Is there any setting that could make the kernel operate this way and disregard explicit ipv6 scopes for link-local addresses (including ff02::/16 which according to the IPv6 spec is still considered link-local).

migrated from stackoverflow.com Dec 19 '15 at 15:13

This question came from our site for professional and enthusiast programmers.

  • It would not be completely accurate to describe ff00::/8 as link-local. There is link-local multicast, and ff02::/16 is that range, but there is also node-local (ff01::/16) multicast which will not leave the node, site-local multicast (ff05::/16), etc. IPv6 multicast can be complex with various flags and scopes. There are newer RFCs which have added to and refined IPv6 multicast since the release of RFC 4291. – Ron Maupin Dec 12 '15 at 18:03
  • Could you include the output from brctl show in the question? – kasperd Dec 22 '15 at 20:01
0

It turns out the problem was related to my configuration. I am running Suricata in inline IPS using nfqueue and was using its 'repeat' mode to reinsert packets back at the beginning of the chain if they got the okay from the IPS. Then I had rules to look for the mark Suricata added to the packet and not redeliver to Suricata. However the reinsertion back into the chain from Suricata seemed to make the kernel forget about how to route the packet. Simply removing the nfqueue rule fixed the problem but didn't utilize the IPS. So what I ended up doing was to replace all my -j ACCEPT iptables rules to -j NFQUEUE iptables rules. In this form Suricata does not see ALL the traffic, particularly it doesn't see the packets for things the firewall would block. This is unfortunate but does work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.