On Fri, 2 Feb 2024, at 7:05 PM, Timo Lindfors wrote:
> On Thu, 1 Feb 2024, Kerin Millar wrote:
>> Given that the rule is supposed to have been created with iptables-nft, I am surprised that it is presented in that way at all (the line you are showing doesn't match "handle 247" either).
>
> ah, I might have made an error while trying to format the lines for 80
> characters. Here's a fresh new situation:
>
> $ sudo nft -a list ruleset | grep "handle 125"
> # Warning: table ip filter is managed by iptables-nft, do not touch!
> fib daddr type broadcast counter packets 33859 bytes 6322835 jump
This gives the initial impression that iptables-nft was enlightened enough to generate a native nft rule for its input. It can do that in some cases and not others.
> ufw-skip-to-policy-input # handle 125
> # Warning: table ip6 filter is managed by iptables-nft, do not touch!
> chain ufw6-user-logging-output { # handle 125
> # Warning: table ip nat is managed by iptables-nft, do not touch!
> # Warning: table ip mangle is managed by iptables-nft, do not touch!
>
> $ sudo nft -a --json list ruleset | jq . | grep -B5 -A19 '"handle": 125'
> {
> "rule": {
> "family": "ip",
> "table": "filter",
> "chain": "ufw-after-input",
> "handle": 125,
> "expr": [
> {
> "xt": {
> "type": "match",
> "name": "addrtype"
> }
> },
> {
> "counter": {
> "packets": 33859,
> "bytes": 6322835
> }
> },
> {
> "jump": {
> "target": "ufw-skip-to-policy-input"
> }
> }
> ]
Yet, the above output indicates the use of an xtables match. Here's how it should look for a native rule.
# nft 'table t { chain c { fib daddr type broadcast counter; }; }'
# nft -j list ruleset
{
"nftables": [
{
"metainfo": {
"version": "1.0.9",
"release_name": "Old Doc Yak #3",
"json_schema_version": 1
}
},
{
"table": {
"family": "ip",
"name": "t",
"handle": 2
}
},
{
"chain": {
"family": "ip",
"table": "t",
"name": "c",
"handle": 1
}
},
{
"rule": {
"family": "ip",
"table": "t",
"chain": "c",
"handle": 2,
"expr": [
{
"match": {
"op": "==",
"left": {
"fib": {
"result": "type",
"flags": [
"daddr"
]
}
},
"right": "broadcast"
}
},
{
"counter": {
"packets": 0,
"bytes": 0
}
}
]
}
}
]
}
>
>
>
> $ sudo iptables -nvL | grep 33859
> 33859 6323K ufw-skip-to-policy-input 0 -- * * 0.0.0.0/0
> 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
>
>
>
>> # uname -r; nft -V | head -n1
>> 6.7.2-arch1-2
>> nftables v1.0.9 (Old Doc Yak #3)
>> # nft flush ruleset
>> # iptables-nft -A INPUT -m addrtype --dst-type LOCAL
>> # nft list ruleset 2>/dev/null | sed -n 4p
>> xt match "addrtype" counter packets 8 bytes 778
>
> I get different output on Debian 12:
>
> # uname -r; nft -V | head -n1
> 6.1.0-17-amd64
> nftables v1.0.6 (Lester Gooch #5)
> # nft flush ruleset
> # iptables-nft -A INPUT -m addrtype --dst-type LOCAL
> # nft list ruleset 2>/dev/null | sed -n 4p
> fib daddr type local counter packets 24 bytes 16144
>
> Is this perhaps a regression?
It might be that iptables-nft is supposed to generate a native rule and that we are both experiencing a regression in that respect.
On the other hand, it might be the opposite. That is, even though iptables-nft could, in principle, generate a native rule for "-m addrtype --dst-type BROADCAST", it might be that it has never been able to and that the output of "nft list ruleset" is simply misleading in your case.
Presently, it is unclear to me.
>
>>> 4) Create separate tools for parsing iptables and netfilter rules and
>>> hope that no system mixes these two.
>>
>> As things stand, this seems more realistic to me. Perhaps one of the developers would have a better idea, though.
>
> Ok, thanks for the insights. If I built the tool for netfilter first,
> which of the three formats should I try to analyze? netlink, text or json?
It's difficult for me to make a recommendation because I only fully understand the output of iptables-save, nft list ruleset, nft -j list ruleset etc. However, I would say that structured data is helpful, meaning that I would prefer "nft -j list ruleset" over "nft list ruleset".
--
Kerin Millar
