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
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
|
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
Monday, 03 August 2015, 22:07 GMT
Reason for closing: Works for me
$ 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
}
}