RSS

Troubleshooting ICMPv6 with tcpdump

I’ve previously written about my OpenBSD PF firewall in front of my VM server at my colo. I had a firewall rule which used the following variable: icmp6_types=”{ 2, 128 }". This wasn’t working properly on the LAN side, and I had to disable the ICMPv6 restrictions to get things back to working. I wanted to fix this permanently, the right way, by determining what needed to be allowed and what could be denied without breaking things.

I’ve previously written about my OpenBSD PF firewall in front of my VM server at my colo. I had a firewall rule which used the following variable: icmp6_types="{ 2, 128 }". This wasn’t working properly on the LAN side, and I had to disable the ICMPv6 restrictions to get things back to working. I wanted to fix this permanently, the right way, by determining what needed to be allowed and what could be denied without breaking things.

Tcpdump To The Rescue

I started to tcpdump on the internal interface, to establish exactly which ICMPv6 types were needed for regular operation. I was using tcpdump -i vlanXX ip6, which was WAY too verbose. I eventually found this really helpful blog post (now dead) web.archive.org link of the blog which suggested using the following to troubleshoot NDP issues.

tcpdump -i eth0 'ip6 && icmp6 && (ip6[40] == 133 || ip6[40] == 134 || ip6[40] == 135 || ip6[40] == 136)'

Looking at the table of Types of ICMPv6 Messages on Wikipedia, these numbers correspond to the following strings:

ICMPv6 ValueMeaning / Error Message
133Router Solicitation (NDP)
134Router Advertisement (NDP)
135Neighbour Solicitation (NDP)
136Neighbour Advertisement (NDP)
137Redirect Message (NDP)