FS#44651 - [nftables] 1:0.4-4 Default nftables.conf blocks some ICMPv6 requests

Attached to Project: Arch Linux
Opened by isomarcte (isomarcte) - Monday, 20 April 2015, 02:58 GMT
Last edited by Sébastien Luttringer (seblu) - Monday, 03 August 2015, 22:07 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The default /etc/nftables.conf file blocks some icmpv6 packets, even though the config file appears as though it should allow them. This is because some icmpv6 packets are matched as `ct state invalid`. Since the default `ct state invalid drop` rule appears before the `ip6 nexthdr icmpv6 accept` rule, these icmpv6 packets are dropped.

I do not know *why* these packets are matched as invalid, although a similar behavior is noted in this article on iptables (https://wiki.archlinux.org/index.php/Simple_stateful_firewall), search for "ICMPv6" and you should find the note.

Steps to reproduce:
You can demonstrate this behavior by changing the /etc/nftables.conf file as follows,

table inet filter {
chain input {
type filter hook input priority 0;

# allow established/related connections
ct state {established, related} accept

# early drop of invalid connections

ct state invalid counter drop

# allow from loopback
iifname lo accept

# allow icmp
ip protocol icmp accept
ip6 nexthdr icmpv6 accept

# allow ssh
tcp dport ssh accept

# everything else
reject with icmp type port-unreachable
}
chain forward {
type filter hook forward priority 0;
drop
}
chain output {
type filter hook output priority 0;
}

}

Then from the shell
# systemctl restart nftables
# ping6 ff02::1%eth0 &# Replace with your interface
# watch "nft list chain inet filter input"

You can see that the `ct state invalid counter drop` rule is steadily being incremented. And you will also notice that the `ping6` command returns nothing.

There are two simple fixes for this, one is to alter the config so that the `icmp` rules come before the `ct state invalid drop` rule, the other is just to add something to the comments that certain `icmpv6` packets will be matched by the `ct state invalid drop` rule and thus the user *may* want to make adjustments himself. I am partial to the first solution because it just *works*, but either are better than the current state where it is mysterious as to why *some* icmpv6 packets are blocked.

I have attached updated config files for either solution you may prefer.

Additional info:
* package version(s): 1:0.4-4
* /etc/nftables.conf

This task depends upon

Closed by  Sébastien Luttringer (seblu)
Monday, 03 August 2015, 22:07 GMT
Reason for closing:  Works for me
Comment by Sébastien Luttringer (seblu) - Wednesday, 22 July 2015, 19:05 GMT
I'm not able to confirm that.

$ ping6 fe80::a00:27ff:feb0:8519%vboxnet0
PING fe80::a00:27ff:feb0:8519%vboxnet0(fe80::a00:27ff:feb0:8519) 56 data bytes
64 bytes from fe80::a00:27ff:feb0:8519: icmp_seq=1 ttl=64 time=0.169 ms
64 bytes from fe80::a00:27ff:feb0:8519: icmp_seq=2 ttl=64 time=0.184 ms
64 bytes from fe80::a00:27ff:feb0:8519: icmp_seq=3 ttl=64 time=0.203 ms

# nft list chain inet filter input
table inet filter {
chain input {
type filter hook input priority 0;
ct state { established, related} counter packets 4458 bytes 246613 accept
ct state invalid counter packets 0 bytes 0 drop
iifname "lo" counter packets 0 bytes 0 accept
ip protocol icmp counter packets 0 bytes 0 accept
ip6 nexthdr ipv6-icmp counter packets 5 bytes 376 accept
tcp dport ssh counter packets 1 bytes 60 accept
counter packets 0 bytes 0 reject
}
}
Comment by Sébastien Luttringer (seblu) - Friday, 24 July 2015, 23:03 GMT
are you still able to reproduce with recent kernel?

Loading...