7

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?

Improve this question
7
  • probably it can't deduce from the initial destination IP what would be the expected reply source IP. has to be expected with multicast Commented Jan 15, 2019 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? Commented Jan 16, 2019 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 Commented Jan 16, 2019 at 12:08
  • So you're saying it's a bug? Commented Jan 16, 2019 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. Commented Jan 16, 2019 at 22:25

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.