Sstrhsrtj

I was playing arround with the Multicast feature of IPv6.

$ ping ff02::2%wlp3s0

This should normally result in an echo-reply from all the routers on your local network segment (Wikipedia - IPv6).
So in my case my home router.

However, I found out that my original nftables rules where blocking the echo-replies:

Original nftables rules preventing echo-reply

table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;

        iifname "lo" accept

        ct state { established, related } accept

        ct state invalid drop

        ip protocol icmp accept

        ip6 nexthdr ipv6-icmp accept        

    }



    chain forward {

        type filter hook forward priority 0; policy drop;

    }



    chain output {

        type filter hook output priority 0; policy accept;

    }

}

With this setup no reply came through.

$ ping ff02::2%wlp3s0

PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes

Fixed nftables rules which allowed echo-reply

table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;

        iifname "lo" accept

        ct state { established, related } accept

        ip protocol icmp accept

        ip6 nexthdr ipv6-icmp accept

        ct state invalid drop

    }



    chain forward {

        type filter hook forward priority 0; policy drop;

    }



    chain output {

        type filter hook output priority 0; policy accept;

    }

}

With this setting it worked:

$ ping ff02::2%wlp3s0

PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes

64 bytes from fe80::----:----:----:----%wlp3s0: icmp_seq=1 ttl=64 time=1.82 ms

CT state invalid is the culprit

You might have figured out by yourself that the only difference is that once ct state invalid drop comes before ip6 nexthdr ipv6-icmp accept and once afterwards.

Thus, the echo reply to ping ff02::2%wlp3s0 seems to have the ct state invalid. (I even checked this with a more specific rule and logging just to make sure)

My Question

Shouldn't the ct state of the echo-reply be "related" ore "established", since it's a direct result of my echo-request?

If not: Why is a a "normal" unicast ping (ping 2001:470:20::2) working in both cases?