4

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 "normal" unicast ping (ping 2001:470:20::2) working in both cases?

  • probably it can't deduce from the initial destination IP what would be the expected reply source IP. has to be expected with multicast – A.B Jan 15 at 21:17
  • That would have been my guess as well. However, isn't this a violation of the IPv6 protocol? In other words is this a bug or a feature? – Hermilton Jan 16 at 10:16
  • it can still know that an icmp reply has to come after an icmp request. the same with UDP would have instead created a NEW state – A.B Jan 16 at 12:08
  • So you're saying it's a bug? – Hermilton Jan 16 at 22:04
  • nope. saying it's an impossible feature, or a feature that would allow too much (as in add an expectation for any ping reply). Also a firewall probably violates a lot of protocols, its role is to not allow things expected in the protocol, so saying that a firewall violates a protocol is perhaps a bit too much. IPv4 relies on underlying ARP (which is almost never firewalled anywhere even if it can) for link local discovery etc. IPv6 relies on ICMPv6 ie: IPv6 alone. So some things have to be blindly allowed anyway. – A.B Jan 16 at 22:25

Your Answer

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

Browse other questions tagged or ask your own question.