The question, in my opinion, is a bit tricky about the rules of nftables

Installing and Using OpenWrt
1

This rule was extracted from the "nft list ruleset" dump.
Who thinks they understand how the rule processes packets?
"ip ttl != 15-5 counter drop".

2

As written above, itā€™s not valid input for nft.

root@router:~# nft -c -d netlink add rule inet fw4 input ip ttl != 15-5 counter drop
Error: Range negative size
add rule inet fw4 input ip ttl != 15-5 counter drop
                                  ^^^^

If you reverse the 15 and 5, you see the expanded byte code that checks the TTL is not within the range of 5 to 15.

root@router:~# nft -c -d netlink add rule inet fw4 input ip ttl != 5-15 counter drop
inet fw4 input
  [ meta load nfproto => reg 1 ]
  [ cmp eq reg 1 0x00000002 ]
  [ payload load 1b @ network header + 8 => reg 1 ]
  [ range neq reg 1 0x00000005 0x0000000f ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 drop ]

TTL isnā€™t part of firewall4, so what inserted that rule into your ruleset? Iā€™ve seen nftables have problems displaying rules the same way they were created.

1 Like
3

OWRT 24.10.4 vanil.
Loaded from ā€/etc/nftables.d/10-custom-filter-chains.nft" as one of my rules. And yes, the original rule looks different. But this rule works as intended!!!
I just can't interpret it this way.
So I decided to ask, maybe someone has succeeded in performing the reverse transformation.
Ultimately, I'll certainly explain how the original rule was written.
Now, of course, I'm curious if anyone can do it themselves.

1 Like
4

Don't reveal if you want to think about it.

Summary

chain marathon {
ip ttl <15 ip ttl >5 counter drop
}

chain my_postrouting_filter_filter {
type filter hook postrouting priority filter; policy accept;

oifname $wan_devices jump marathon
}

5

Ah, a puzzle. But you revealed the answer too quickly. :grinning_face:

Iā€™ve seen similar ā€œinversionā€ with meta hour when crossing midnight.

6

I would have kept the suspense going longer.
But I realized it wasn't really good for you.
Maybe I should hide it under a spoiler. :grinning_face:

7

It is unusual. But why not just use ip ttl 6-14 counter drop?

1 Like
8

For a long time, this rule looked like this

Summary

ip ttl >5 ip ttl <15 counter drop

and loaded/unload as written.

At one point, I rearranged.
Obviously, why bother tinkering with something that works?
And today my eye just happened to catch this strange construction that's mind-boggling.

1 Like
9

This strange rule works.
I just want to understand how to interpret it.

10

It checks that the TTL is not ā€œfrom 15 to maximum or zero to 5ā€, which is an unusual way of saying ā€œgreater than 5 and less than 15.ā€

You have to agree with nft that the TTL value can make a circle and go from 15 to 5. This ā€œoptimizationā€ works better with times.

1 Like
11

:waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :upside_down_face:

1 Like
12

nftables does many tricks loading rules and parsing them back for sake of optimisation. While your example is positive there are negative ones too

(printed rule puts slow strcmp iifname before instant l4proto filter)
But it is a superb sanity check to try to reload rules and compare optimized/pessimized "new" bytecode and statement.

1 Like
13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.