On a host managed by firewalld or ufw, you add your own rules with `nft add rule`. What happens to those rules, and how should hand-written nftables rules coexist with a firewall frontend?

## The frontends own their ruleset firewalld and ufw are not thin wrappers that hand your rules to the kernel and step back. Each keeps a declarative configuration — zones, services and rich rules for firewalld; profiles and rule files for ufw — and *generates* the kernel ruleset from it. Generation is not incremental: on reload, restart, or a change that requires it, the tool tears down what it owns and builds it again from its configuration. That is the whole answer to the first half of the question. A rule you appended into firewalld's chains with `nft add rule` exists only in the kernel; it is in no configuration file the tool reads. The next `firewall-cmd --reload`, package update or reboot rebuilds those chains and your rule is gone, with nothing logged to explain it. The same holds for ufw's chains and `ufw reload`. ## firewalld specifics Modern firewalld uses the nftables backend (selected by `FirewallBackend=` in `/etc/firewalld/firewalld.conf`, and the default on current RHEL-family and Fedora systems) and builds a table named `firewalld` in the `inet` family with its own base chains. `nft list ruleset` shows the whole thing, which is genuinely useful for understanding what a zone actually did — but reading it is not the same as being allowed to edit it. To make a rule stick, express it in firewalld's own vocabulary and mark it permanent: ```bash firewall-cmd --permanent --zone=public --add-service=https firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="5432" protocol="tcp" accept' firewall-cmd --reload ``` Without `--permanent` the change applies to the running configuration only and is itself lost on reload — the mirror image of the same trap. ## ufw specifics ufw is an iptables frontend. On current Ubuntu the `iptables` command it drives is the nft-backed one, so ufw's rules do appear in `nft list ruleset`, but ufw itself thinks and writes in `iptables-restore` syntax. Its rule files live in `/etc/ufw`, and that is where custom rules belong: `/etc/ufw/before.rules` for rules that must be evaluated before ufw's generated ones, `/etc/ufw/after.rules` for the tail. Because those files are inputs to the generator rather than kernel state, they survive `ufw reload` and reboots. ## Coexistence semantics when you keep your own table Suppose you refuse to use the frontend's vocabulary and instead create `table inet mypolicy` with its own base chain. Nothing stops you, and the frontend will not delete it, because it only manages its own objects. What you need to understand is how the two interact: - Every base chain registered on a hook is evaluated, in ascending priority order. - `accept` terminates evaluation **of that chain** and the packet proceeds to the next base chain on the hook. - `drop` is immediate and final. So the effective policy is the intersection: a packet must be dropped by nobody. Your accept cannot rescue traffic the frontend drops, and the frontend's accept cannot rescue traffic you drop. Choosing a lower priority number makes your chain run *earlier*, not *decisively* — the only way to end evaluation from an earlier chain is to drop. This is also the shape of the well-known surprise where a container runtime's published ports remain reachable despite a host firewall: the runtime installs its own tables and chains, and whether traffic survives depends on what each of them does at which hook — not on which tool is considered "the firewall". ## The practical rule Pick one owner per host and write it down: - **Frontend owns the firewall** — every rule goes through `firewall-cmd --permanent` or `/etc/ufw/*.rules`, and `nft` is used read-only, for `nft list ruleset` during an incident. This is the right default on a host where other people or other tooling also manage firewall state. - **You own the firewall** — disable and mask the frontend (`systemctl disable --now firewalld`, `ufw disable`), manage `/etc/nftables.conf` as a reviewed artefact, and enable the `nftables` service to load it at boot. This is the right choice when the ruleset is generated from configuration management and needs sets, maps and structure the frontend cannot express. The failure mode to avoid is the third option nobody chooses deliberately: half the policy in the frontend's configuration and half in ad-hoc `nft` commands, where a routine reload silently removes protection and the surviving half is impossible to reason about.