iptables vs firewalld
Two ways of controlling the same kernel packet filter — one rule-by-rule, one zone-by-zone. Read the breakdown below, then click through the animated scenes to see how each actually behaves.
What are iptables and firewalld?
If you manage Linux servers, sooner or later you’ll have to choose between two tools for controlling network traffic: iptables and firewalld. Both protect your system by filtering packets at the kernel level, but they take very different approaches to how you write, apply, and manage rules.
iptables is a low-level, command-line userspace utility that directly configures the Linux kernel’s Netfilter framework. It has been the standard Linux firewall tool since the late 1990s. With iptables, you write explicit rules organized into tables (filter, nat, mangle, raw) and chains (INPUT, OUTPUT, FORWARD). Each packet is checked against these rules in order, and the first matching rule determines what happens to it.
firewalld is a firewall management daemon that sits on top of the kernel’s packet-filtering system. Instead of writing raw rules, you work with higher-level concepts like zones (trust levels) and services (named, predefined rule sets, such as “ssh” or “http”). On modern distributions, firewalld typically uses nftables — the direct successor to iptables — as its backend.
In short: iptables gives you granular, manual control over every packet-filtering rule, while firewalld gives you a more manageable, dynamic abstraction layer built for real-world administration.
Core architectural differences
1. Rule model: chains vs. zones
iptables organizes rules into linear chains evaluated top to bottom. Rule order is critical — placing a broad “deny all” rule too early can silently block traffic you meant to allow further down. firewalld instead organizes rules into zones — named trust levels such as public, home, internal, dmz, work, trusted, block, and drop. You assign a network interface to a zone, and that zone determines which services and ports are allowed.
2. Dynamic vs. static configuration
With iptables, changing rules typically means flushing the existing ruleset and reloading it, or manually inserting and deleting individual rules — there’s no true live reload, and a full flush can briefly leave a server unprotected or drop active connections. firewalld applies changes made with firewall-cmd immediately, without disrupting existing connections, and keeps a clear separation between runtime configuration (active now) and permanent configuration (persists after reload).
3. Persistence across reboots
iptables rules live in kernel memory and are lost on reboot unless explicitly saved with iptables-save / iptables-restore or a distro-specific service. firewalld has persistence built in: rules applied with --permanent are written to XML config files, and firewall-cmd --reload applies them without restarting the service.
iptables kernel-level rules
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP
Static view of the same chain, for reference:
firewalld zone-based trust
firewall-cmd --zone=public --add-service=ssh --permanent
firewall-cmd --reload
Static view of both zones side by side, for reference:
What happens when you change a rule
## iptables — full ruleset flush + rebuild
iptables-save > /tmp/rules.v4
### edit rules, then reload everything
iptables-restore < /tmp/rules.v4
## firewalld — live runtime update, no flush
firewall-cmd --zone=public --add-port=8443/tcp --permanent
firewall-cmd --reload
Syntax comparison
Seeing the same task done in both tools makes the philosophical difference concrete. Here’s how you’d allow SSH traffic (port 22) using iptables and firewalld respectively.
Allowing SSH with iptables
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
service iptables save # persistence method varies by distro
Allowing SSH with firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
Notice that firewalld lets you reference a named, predefined service instead of memorizing port numbers and protocols. You can explore what’s available with:
firewall-cmd --get-services
firewall-cmd --zone=public --add-port=8080/tcp --permanent
Side-by-side comparison table
| Feature | iptables | firewalld |
|---|---|---|
| Abstraction level | Low-level (packets, chains) | High-level (zones, services) |
| Rule changes | Often require a full flush/reload | Live updates, no dropped connections |
| Persistence | Manual (iptables-save) | Built-in runtime vs. permanent split |
| Configuration format | Shell commands / scripts | XML config files + CLI / D-Bus API |
| Learning curve | Steeper, more manual | Gentler, more automated |
| Best for | Fine-grained, custom, scriptable setups | Dynamic environments, ease of management |
| Kernel backend (modern) | Directly manages iptables/nftables | Typically runs on nftables under the hood |
| Default on | Debian/Ubuntu (unmanaged), legacy systems | RHEL/CentOS/Fedora 7+, recent SUSE |
When to use iptables
- Fine-grained control — complex NAT configurations, packet mangling, or custom chains that firewalld’s abstractions don’t cleanly expose.
- Minimal or embedded systems — environments where running an extra background daemon isn’t desirable.
- Legacy automation — countless existing hardening scripts and configuration management playbooks are written in raw iptables syntax.
- Docker environments — Docker has traditionally manipulated iptables rules directly, which can create conflicts if firewalld is also managing the same chains.
When to use firewalld
- Frequently changing rules — servers where firewall rules need to change often without dropping active connections.
- Multi-zone environments — laptops and desktops that move between trusted and untrusted networks benefit enormously from zone-based trust switching.
- Ease of management — administrators who prefer service-name-based rules (
--add-service=http) over memorizing port and protocol combinations. - Modern RHEL-family systems — firewalld has been the default since RHEL 7 and Fedora 18, and integrates cleanly with systemctl and other standard system tooling.
Can you use iptables and firewalld together?
Technically, both tools can be installed on the same system — but running them simultaneously to manage the same rules is strongly discouraged. Both ultimately try to control the same underlying kernel packet-filtering tables, so using them at once can lead to silent conflicts, where one tool’s rules override or interfere with the other’s.
Most distributions let you disable one in favor of the other. On RHEL, CentOS, or Fedora:
# To let firewalld manage the firewall
systemctl disable iptables
systemctl enable --now firewalld
# To use raw iptables/nftables instead
systemctl disable firewalld
Distro defaults
| Distribution family | Default firewall tool |
|---|---|
| RHEL / CentOS / Fedora (7+) | firewalld |
| Debian / Ubuntu | Neither by default — commonly ufw or raw iptables/nftables |
| SUSE (recent versions) | firewalld |
Package availability and defaults can change between releases, so it’s worth double-checking your distribution’s current documentation before setting up a production system.
Frequently asked questions
Is firewalld better than iptables?
Neither is universally “better” — they solve the same problem at different levels of abstraction. firewalld is generally easier to manage day-to-day and supports live rule changes without dropping connections. iptables offers more granular, low-level control, preferable for complex custom configurations, embedded systems, or legacy automation.
Does firewalld replace iptables?
Not exactly. firewalld is a management layer that, on modern systems, typically uses nftables (iptables’ successor) as its backend. It doesn’t replace the kernel’s packet-filtering capability — it replaces the way you interact with it.
Should I disable firewalld and use iptables instead?
Only if you have a specific need for iptables’ low-level control — complex NAT rules, custom chains, or compatibility with legacy scripts. For general-purpose servers, especially ones with changing rules or multiple network zones, firewalld’s live-reload and zone model usually make it the more practical choice.
Final thoughts
The right choice between iptables and firewalld depends on how much manual control you need, how often your rules change, and what your distribution and existing tooling already expect. iptables hands you a scalpel: precise, powerful, and entirely in your hands. firewalld hands you a well-organized toolbox with that same scalpel built in, labeled, and ready to grab.
Whichever you choose, the underlying goal is the same: a firewall configuration you understand, can audit, and that doesn’t silently conflict with a second tool running in parallel.