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 Value Meaning / Error Message
133 Router Solicitation (NDP)
134 Router Advertisement (NDP)
135 Neighbour Solicitation (NDP)
136 Neighbour Advertisement (NDP)
137 Redirect Message (NDP)