firewalld: Managing the Linux Firewall

A host firewall is the machine's own bouncer: for every incoming connection, it decides accept or refuse before any application even hears about it. You hardened SSH's lock; the firewall decides who gets to touch the lock at all. firewalld is the manager on RHEL-family systems, and it has two headline properties: it applies changes dynamically (no restart, no dropped connections — critical on a production box), and it organizes everything around zones.

Here's the idea that makes firewalld click. A laptop on coffee-shop Wi-Fi and the same laptop on your home LAN shouldn't apply the same rules — same machine, different trust. So firewalld doesn't attach rules to the machine; it attaches them to zones, where a zone is a named trust level. Picture a receptionist with a different rulebook per entrance: connections arriving through the coffee-shop entrance get the strict public book; the management-LAN entrance gets a relaxed one. Every network interface (and any source IP you explicitly assign) is bound to exactly one zone, and that zone's rulebook is what applies.

The zones you'll actually use:

• `public` — the default: untrusted; only explicitly-allowed traffic gets in. Where most server work happens.
• `trusted` — accept everything. For interfaces where the network itself is the security boundary (a private cluster interconnect). Use sparingly.
• `drop` — silently discard all incoming, not even a refusal message. The right home for known-hostile sources.
• `block` — refuse with an ICMP "no." Politer than drop; the sender knows immediately rather than timing out.

On a single-interface server you'll live in public — but the model still matters, because every rule you write lands in a zone, and rules in the wrong zone silently do nothing.

Same discipline as every other subsystem: read before you write. Three questions, in order — is the firewall running, what's the default zone, and (the one that actually matters) which zone is active on my interfaces right now?

You've met this split three times now — ip vs nmcli, start vs enable — and firewalld has its own flavor, sharp enough to bite in both directions. It keeps two copies of its configuration:

• Runtime — what the kernel is enforcing this second. A whiteboard: changes hit instantly, and it's wiped clean on --reload or reboot (rewritten from the binder).
• Permanent — the policy binder on disk, read at boot and on reload. Writing to it changes nothing about what's enforced right now.

A plain firewall-cmd --add-service=X writes only the whiteboard. Adding --permanent writes only the binder. Neither alone gives you what you almost always want — active now and after reboot — which is why the canonical idiom is two commands:

What goes in the rulebook? Two kinds of allowance. A service is a named bundle — http means 80/tcp, https means 443/tcp, defined in shipped XML — so rules read as intent (--list-services says this box serves web, not port 80 is open, good luck). A raw port is for anything without a predefined name: your app on 8080, a custom agent. The rule of thumb: service when one exists, port when it doesn't.

--add-service=mysql opens the database to everyone the interface can hear — usually far more trust than intended. The real requirement is almost always scoped: "only the app server may reach 3306." firewalld gives you two scoping tools at two granularities: a rich rule (a precise sentence: this source, this port, this action) and a source-to-zone binding (coarse: this whole network gets that zone's entire rulebook).

The full lifecycle, hands on: baseline, change, then — the part that separates done from provably done — verify both stores. Graded labs check the permanent config (will it survive reboot?) AND the runtime (is it active?); so should you, every time.