TL;DR:
if direct rules are really needed, just always use INPUT rather than INPUT_direct: it will always work.
if you don't know what priority value to use, just increase the priority value by one for each new direct rule to add.
This chain is (sometimes) used by the direct rules interface of firewalld. This interface/feature allows to store custom iptables rules (and always iptables even when firewalld's backend is nftables) using firewalld and ensure that these rules are the first seen by any packet (here in the filter table and INPUT chain). Normally you should use it only if something can't be handled by firewalld including by firewalld's rich language.
And this is a deprecated feature:
deprecated
The direct interface has been deprecated. It will be removed in a
future release. It is superseded by policies, see
firewalld.policies(5).
I'm not really sure it's superseded by policies for all of its uses, anyway...
Just as deprecated is the iptables backend. A typical installation on a recent system also includes in /etc/firewalld/firewalld.conf:
# FirewallBackend
# Selects the firewall backend implementation.
# Choices are:
# - nftables (default)
# - iptables (iptables, ip6tables, ebtables and ipset)
# Note: The iptables backend is deprecated. It will be removed in a future
# release.
FirewallBackend=nftables
firewalld can use either iptables or nftables as backend, but the direct rules are always using iptables. There is no concept of nftables direct rule even when the backend is nftables: that's probably one of the reasons that made direct rules deprecated.
when the backend is iptables
firewalld creates the INPUT_direct chain and adds as first rule in INPUT a jump to INPUT_direct so it's always the first chain to see packets (in the INPUT path).
any reference to INPUT in a direct rule is switched to a reference to INPUT_direct
when the backend is nftables
- firewalld doesn't create by itself any iptables chain or rule, but ensures its own nftables rules are hooked to Netfilter at the priority iptables would have used +10.
So for INPUT it hooks at priority 10 instead of 0. This ensures again that anything iptables does will do it first
- direct rules referencing builtin chains are not changed. This time
INPUT is used.
This peculiarity can be seen in the python code fw_direct.py:
# if nftables is in use, just put the direct rules in the chain
# specified by the user. i.e. don't append _direct.
if not self._fw.nftables_enabled \
and backend.is_chain_builtin(ipv, table, chain):
_chain = "%s_direct" % (chain)
In both cases anything created using firewall-cmd --direct --add-rule ipv4 filter INPUT 0 (followed by the same syntax as what would be provided to an iptables command without including the table and chain) will be seen by a packet before firewalld itself sees it.
For the prority value: this affects the order of the rules you want to use in case their order matters. If, by the way rules were chosen by the administrator, a rule doesn't depend on previous rules, then its priority doesn't matter and can even stay the same. To ensure a rule is added after other rules, increase its priority:
If you want to make sure that a rule will be added after another one,
use a low priority for the first and a higher for the following.
