Hi Merlin, On Thu, Feb 08, 2018 at 04:14:15AM +0100, Merlin Büge wrote: > On Wed, 7 Feb 2018 20:26:32 +0100 > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > Could you possibly post all of the output from nft list ruleset? > > Of course, I attached a textfile showing all the commands and output, > and commenting what I don't understand / does not seem to work. > > I also uploaded the textfile: http://termbin.com/8zql > > Let me know if you need anything else. > > > > We need to keep ip6 nexthdr around, since this is implicitly > > restricting to match only IPv6 in the inet chain, where we can see > > IPv4 and IPv6 traffic. > > > > Looking into this. > > So, are you saying that nftables is not behaving as intended, or am I > doing something wrong? I'm new to networking and nftables, so I'm not > sure my commands in the attached textfile are actually correct... > > > Thanks! > > -- > Merlin Büge <toni@xxxxxxxxxxxx> > [root@host test]# nft flush ruleset > [root@host test]# nft add table inet filter > [root@host test]# nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; } > [root@host test]# # filtering all IPv6 SSH traffic doesn't work: > [root@host test]# nft add rule inet filter input ip6 nexthdr tcp tcp dport ssh accept > [root@host test]# nft add rule inet filter input meta nfproto ipv6 tcp dport ssh accept > [root@host test]# nft list ruleset > table inet filter { > chain input { > type filter hook input priority 0; policy drop; > tcp dport ssh accept > tcp dport ssh accept > } > } > [root@host test]# # filtering all IPv6 traffic or all IPv6 TCP traffic seems to work: > [root@host test]# nft add rule inet filter input meta nfproto ipv6 accept > [root@host test]# nft add rule inet filter input ip6 nexthdr tcp accept > [root@host test]# nft list ruleset > table inet filter { > chain input { > type filter hook input priority 0; policy drop; > tcp dport ssh accept > tcp dport ssh accept > meta nfproto ipv6 accept > ip6 nexthdr tcp accept > } > } > [root@host test]# # but this also does not work: > [root@host test]# nft add rule inet filter input meta nfproto ipv6 meta l4proto tcp accept > [root@host test]# nft list ruleset > table inet filter { > chain input { > type filter hook input priority 0; policy drop; > tcp dport ssh accept > tcp dport ssh accept > meta nfproto ipv6 accept > ip6 nexthdr tcp accept > meta l4proto tcp accept > } > } > [root@host test]# > Merlin, there are a number of actions you can take to clarify what's going on: - add a *counter* action to each rule. You then see which rules match and act on packets. - rather than use stand-alone nft commands, incorporate them into an nft script. The commands become shorter owing to the block-structured nature of the script, AND: - Put *nft list ruleset* as the last line of the script. This will show you the ruleset as will be presented to the kernel via netlink. This will usually differ from stand-alone *nft list ruleset* output - more on that later. - Put a *counter* as the last rule of any chain with policy *drop*. That can warn you if you are losing packets unexpectedly. - When experimenting (with low packet volumes), add a *log* action to the *counter* above. - When developing a ruleset, run *watch "nft list ruleset"* inside an xterm. I use: > xterm -geometry 130x45 -font 7x14 -bg rgb:30/00/00 -e watch "nft list ruleset"& but you can adjust the xterm size to fit as it's running and miss all options except -e. - Similarly, I like to watch what's actually going into the debug log: > xterm -sl 2000 -sb -geometry 361x28 -font 7x14 -bg rgb:18/32/10 -e "tail --follow=name /var/log/debug"& I added your rules to my existing nft script with a couple of extras: 1. Only filter wlan0 traffic so as not to lock out wired ethernet 2. Run the filter hook at a lower priority than in the existing (ip4) rules > #!/usr/sbin/nft -f > flush ruleset > > # (existing table omitted) > > table inet filter \ > { > chain input \ > { > type filter hook input priority 100; policy drop; > > # Only for wlan0 > iif ne "wlan0" accept > > ip6 nexthdr tcp tcp dport ssh counter drop; > meta nfproto ipv6 tcp dport ssh counter accept > counter log prefix "nft6: " level debug > } > } > list ruleset *list ruleset* above produced the following: > table inet filter { > chain input { > type filter hook input priority 100; policy drop; > iif != "wlan0" accept > meta nfproto ipv6 ip6 nexthdr tcp tcp dport ssh counter packets 0 bytes 0 accept > meta nfproto ipv6 meta l4proto tcp tcp dport ssh counter packets 0 bytes 0 accept > counter packets 0 bytes 0 log prefix "nft6: " level debug > } > } while stand-alone *nft list ruleset* shows: > table inet filter { > chain input { > type filter hook input priority 100; policy drop; > iif != "wlan0" accept > tcp dport ssh counter packets 0 bytes 0 accept > tcp dport ssh counter packets 0 bytes 0 accept > counter packets 0 bytes 0 log prefix "nft6: " level debug > } > } Trying an ssh still fails to connect. The debug log shows why: > Feb 18 14:38:58 smallstar kernel: [13373.966329] nft6: IN=wlan0 OUT= MAC=33:33:ff:5a:fe:38:00:03:47:e0:7b:e7:86:dd SRC=fe80:0000:0000:0000:0203:47ff:fee0:7be7 DST=ff02:0000:0000:0000:0000:0001:ff5a:fe38 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 Add a rule to let in ICMPv6: > meta l4proto ipv6-icmp counter packets 0 bytes 0 accept Retry the ssh - now successful: > table inet filter { > chain input { > type filter hook input priority 100; policy drop; > iif != "wlan0" accept > tcp dport ssh counter packets 23 bytes 3909 accept > tcp dport ssh counter packets 0 bytes 0 accept > meta l4proto ipv6-icmp counter packets 2 bytes 136 accept > counter packets 0 bytes 0 log prefix "nft6: " level debug > } > } There were 2 ICMPv6 messages as part of the transaction. Your first rule accepts the ssh traffic. (If I switch the order, the other rule accepts them instead). This isn't what I meant to say originally. But it seems to work, Cheers ... Duncan. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
