Thanks Slavko, that's good information!
-----Original Message-----
From: Slavko <linux@xxxxxxxxxx>
Sent: Tuesday, August 27, 2024 5:19 AM
To: netfilter@xxxxxxxxxxxxxxx
Subject: RE: Understanding output from "nft list"
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
Dňa 26. augusta 2024 23:55:20 UTC používateľ "Atkins, Brian" <Brian.Atkins@xxxxxxxxxx> napísal:
OK, thus in our topic, the chain is in mean of chain with hook defined, nested chains (jump/goto, without hook) ends whole chain.
>If, say, you had a table of type ip, and another table of type inet, and they both had input hook chains, I don't think accept in one chain would have an impact on the other table's chain, although I don't know that for sure.
I asked about that in this ML some time ago. IIRC, it doesn't matter on table, all chains with input hooks goes into input hook. The inet family table just register its input chain into both family (ip/ip6) hooks.
The order of processing is based only on priority value, in case of the same priority, the order is unspecified.
In other words, it doesn't matter if input hook chains are one eg. in ip family table and second in inet table, or both input hooks chains are in the same table, they both ends in the same netfilter hook. If packet have to be accepted in that hook, all chains (in that hook) must not drop/reject it.
You can simply test that by enabling trace and then monitor it, i created ip table (for you) just with one accept in input chain (redacted)::
trace id be75f3b8 inet filter input packet: ...
trace id be75f3b8 inet filter input rule ... (verdict accept)
trace id be75f3b8 ip filter input packet: ...
trace id be75f3b8 ip filter input rule ... (verdict accept)
Note "verdict accept" in both, in the inet filter input and in the ip filter input chains.
Another note, both these chains has the same priority and the ip table is defined before inet table in config, but packet goes into inet table first.
regards
--
Slavko
https://www.slavino.sk/
