On 4. januára 2025 18:16:52 UTC, Binarus <lists@xxxxxxxxxx> wrote: >This table is worrying. I tried to reply in simple manner, but i fail. The nft provides far more flexibility to setup than iptables, and that flexibility is hard to describe in simple words ;-) > For example, we obviously should use priority 0 for our own filter chains. We can guess this from the fact that hopefully nftables does not apply any filtering unless explicitly told so (i.e., priority 0 should not be assigned to a chain or to an internal process by default) and from the fact that every tutorial we saw so far uses priority 0 for filter chains. Consider priority as ordering, it is number from min to max, and as it is signed number, zero is just in middle of range. >From the NF_IP_PRI_CONNTRACK description in the table: "Connection tracking processes run early in prerouting and output hooks to associate packets with tracked connections." I am understanding this in the sense that an internal process is assigned priority -200. Keep things simple. At start just use symbolic names for priority, or (if you really need) use simple math with these names, eg. "filter - 5". These symbolic names more or less follows iptables's table names, that simplifies migration. If you already use iptables-nft, you can list your iptables rules from nft (list ruleset). Not all rules can/will be translatec to nftables syntax, but you can see all your chains, including its type, hook and priority. Note, i don't suggest to build your firewal by that way, but it can help with chains priorities. >On the other hand, the table mentions prerouting and output being "typical hooks" for priority -200. This makes the impression that we should use priority -200 for custom prerouting and output chains, and contradicts the statements in the previous paragraph. That is because hooks are called at certain states of packet processing, eg in prerouting hook happens conntrack and (D)NAT, and you can add your own chain into it. The priority then defines, in what stage the packet in this (your) chain is, or in other words, if conntrack entry was already created for it or if its dest address was already changed, etc. That doesn't matter in input chain (as it was done already), but you can use these priorities too, but they are without special purpose, just ordering >I have read the nft man page on my debian system (bookworm, up-to-date at the time of writing, nftables 1.0.6, kernel 6.1.0) and found that it indeed contains a similar table. But that table is much smaller than the one in the wiki. Really, at least on start, use only symbolic names for priorities, unless you are willing go into sources (i am not, as i don't speak C). >I am unable to understand this. Why are there priorities with the nft keyword / names "dstnat" and "srcnat" although chains of type nat are not supported in the bridge family? It is about bridging (L2 firewall), it was separate from iptables (i never used/need it, thus i don't remember its name), now it is part of nft. If you not used it before, you can skip it. And if unsure, use nft's buil-in trace & monitor. regards -- Slavko https://www.slavino.sk/
