We all know blocking ICMP is evil, and you cannot change my mind. However, allowing ICMP in your firewall does not mean you don’t block it. What happens when you drop ICMPv6 packets?

Sofia University had a multiple-years-long issue with IPv6 connectivity through some VPLS links. The first people to blame were the Telekom providing the service, and they always told us it’s not their fault…

Then we found one router with functional IPv6, thanks to previously being configured by a different colleague. This pointed us in the right direction, and allowed us to actually reproduce the issue.

Take a look at this ip6tables firewall chain:

-A INPUT -d ff00::/8 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
...
-A INPUT -p tcp -m tcp -j REJECT --reject-with tcp-reset

Well… IPv6 doesn’t work correctly on some interfaces. Cool, what happened?

Also, ip -6 nei add a:b:c::d laddr a:b:c:d:e:f fixes the issue. So neighbor discovery doesn’t work for some reason.

If we add -A INPUT -m state --state INVALID -j LOG to the chain, we see NA packets are dropped. Scouring through the Internets, we see something in the netfilter-devel mailing list.

The fix is simple, move the ICMPv6 rule above all the conntrack stuff:

-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
...

I have three takeaways from this:

  • don’t, don’t, don’t block ICMP
  • always check docs
  • don’t believe people just because they have more years of service than you