ip6 traffic and nftables/iptables backend change

[sydneymeyer]

Since version 0.6 has changed the default backend from iptables to nftables, icmpv6 traffic (and possibly other ip6 traffic) has stopped working, when ethernet and wireless interfaces are enabled simultaneously. [1] This appears to be causing problems with NetworkManager's "connectivity" feature, i.e. checking a http uri every 300 seconds. When choosing the iptables backend, everything appears to be working as expected again, e.g. "ping -6" bound to wireless interface.

[1] https://bugs.archlinux.org/task/61688

Is this perhaps intended behaviour?

Linux 4.20.7-arch1-1-ARCH from Arch Linux firewalld 0.6.3 (0.6.3-3 arch package) nftables 0.9 (1:0.9.0-3 arch package) NetworkManager 1.14 (1.14.5dev+17+gba83251bb-2 arch package)

[erig0]

Can you enable --set-log-denied=all and then show the logs? It'll let us know exactly what's causing the ICMPv6 packets to be dropped.

[sydneymeyer]

Where do i find these logs? I have tried starting firewalld with "LogDenied=all" in firewalld.conf and tried, which appears to have the same effect, "firewall-cmd --set-log-denied=all".

journalctl output

Also, if i set IPv6_rpfilter=no, the "problem" disappears, the option has no apparant effect, at least in this context, with the iptables backend.

[erig0]

Where do i find these logs?

They're logged by the kernel/netfilter. So they'll be in dmesg output. e.g.

[root@rhel8 ~]# dmesg |grep "\(REJECT\|DROP\)"
[977221.786771] FINAL_REJECT: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:XX:XX:XX:XX:XX:XX:XX:XX SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 

Also, if i set IPv6_rpfilter=no, the "problem" disappears, the option has no apparant effect, at least in this context, with the iptables backend.

You're probably checking the wrong table. rpfilter adds rules to the raw table.

# ip6tables -t raw -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp neighbour-solicitation
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp router-advertisement
DROP       all      anywhere             anywhere             rpfilter invert
...

With the nftables backend, it'll be added the the raw_PREROUTING chain.

# nft list chain inet firewalld raw_PREROUTING
table inet firewalld {
        chain raw_PREROUTING {
                type filter hook prerouting priority -290; policy accept;
                icmpv6 type { nd-router-advert, nd-neighbor-solicit } accept
                meta nfproto ipv6 fib saddr . iif oif missing log prefix "rpfilter_DROP: " drop
...
}

[sydneymeyer]

hi @erig0 , i am sorry for these constant delays, but this is the system log when i try to do e.g. "ping -6 -I wlan0 google.com" with the nftables backend enabled. These are the blocked echo replies from google.com.

https://gist.github.com/sydneymeyer/7420b2039e20177cbb5e0c9297a5ff0e

BTW, the referred bug report with NetworkManager, for which i opened this issue originally, has been closed due to a fix with curl [1]. https://github.com/curl/curl/commit/afc00e047c773faeaa60a5f86a246cbbeeba5819

Even tough NetworkManager doesn't hang anymore with one core at full chat, when logging denied packets there are still the denied response packets from NM connectivity check with that interface, which makes me wonder.. I just don't understand why the reverse path filter test drops packets with the nftables backend but does not with the iptables backend.

https://gist.github.com/sydneymeyer/ce293523a181392d4cfb11a079efd32e

Some more info:

https://gist.github.com/sydneymeyer/f08aea76327124273873f8e925470568

edit: format.