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. In this guide, we’ll break down exactly how iptables and firewalld work, where each one shines, and how to decide which is right for your setup.
What are iptables and firewalld?
Before comparing iptables and firewalld head-to-head, it helps to understand what each one actually is, since they operate at different levels of abstraction on top of the same underlying Linux kernel technology.
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 that are organized into tables (such as filter, nat, mangle, and raw) and chains (such as INPUT, OUTPUT, and FORWARD). Each incoming or outgoing packet is checked against these rules in order, and the first matching rule determines what happens to that packet.
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 Linux distributions, firewalld typically uses nftables — the direct successor to iptables — as its backend, though older versions relied on iptables itself.
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.
iptables and firewalld: core architectural differences
The biggest differences between iptables and firewalld come down to how each tool structures rules, applies changes, and persists configuration across reboots.
1. Rule model: chains vs. zones
iptables organizes rules into linear chains that are evaluated top to bottom. You think in terms of sequences: a packet enters the INPUT chain, gets compared against rule 1, then rule 2, then rule 3, and so on, until something matches. 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. This zone-based model has no direct equivalent in raw iptables and is one of the most practical advantages firewalld offers.
| Zone | Typical use case |
|---|---|
drop | All incoming traffic silently dropped, no reply sent |
block | All incoming traffic rejected with an ICMP message |
public | Untrusted, public networks — restrictive by default |
external | External networks with NAT masquerading, e.g. routers |
internal | Internal networks with trusted devices |
dmz | Publicly accessible servers with limited internal access |
work / home | Trusted environments, more services allowed |
trusted | All traffic accepted |
Illustration: how a packet moves through an iptables chain
The diagram below shows the sequential, top-to-bottom evaluation model at the heart of iptables. A packet is checked against each rule in order, and the moment one matches, evaluation stops.
2. Dynamic vs. static configuration
This is arguably the single biggest practical difference between iptables and firewalld. With iptables, changing rules typically means flushing the existing ruleset and reloading it from a script, or manually inserting and deleting individual rules. There is no true “live reload” — a full flush can briefly leave a server unprotected, or worse, drop active connections, unless the change is carefully scripted.
firewalld was built specifically to solve this problem. Changes made with firewall-cmd apply immediately without disrupting existing connections. It also maintains a clear separation between runtime configuration (active right now) and permanent configuration (persists after reload), so you can safely test a change live and only make it permanent once you’re confident it’s correct.
3. Persistence across reboots
iptables rules live in kernel memory and are lost on reboot unless you explicitly save them — typically using iptables-save and iptables-restore, or a distribution-specific service. firewalld, by contrast, has persistence built in from the start: rules applied with --permanent are written to XML configuration files, and firewall-cmd --reload applies them without needing to restart the whole service.
Try it: animated walkthrough of an iptables rule chain
Click the button below to send a simulated packet on port 443 through the chain above and watch exactly where it gets dropped.
INPUT chain
entry point
rule 1
allow ssh :22
rule 2
allow http :80
rule 3
drop allSend a packet on port 443
Not started — every packet walks the chain top to bottom.
iptables and firewalld 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 distroAllowing SSH with firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reloadNotice 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 --permanentUnderstanding firewalld zones
The zone concept is arguably firewalld’s biggest practical advantage over plain iptables. The same network interface behaves differently depending on which zone it’s assigned to — the illustration below shows an interface connected to the restrictive public zone versus the more permissive home zone.eth0 interfacepublic zonerestrictivehome zonetrustedpublic zone allowssshdhcpv6-clienthome zone allowsssh, http, httpssamba, mdns
Try it: animated firewalld zone switcher
Click between the two zones below to see how the allowed services list changes instantly for the same physical interface.
eth0 network interface
public zone
for untrusted networks — restrictive by default
home zone
for trusted networks — more services allowed
allowed in public zone
ssh dhcpv6-client
iptables and firewalld: 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) and legacy systems | RHEL/CentOS/Fedora 7+, recent SUSE |
Try it: what happens to an active connection during a reload
This is the most consequential real-world difference between iptables and firewalld. Click the button below to simulate adding a new rule to both firewalls while a connection is already open, and watch what happens to it.
iptables
client
server
connection idle, waiting to test
firewalld
client
server
connection idle, waiting to testAdd a new rule to both
When to use iptables
Despite firewalld’s convenience, iptables (or its modern successor, nftables) still has a strong place in a sysadmin’s toolkit:
- 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
firewalld tends to be the better choice in scenarios where flexibility, uptime, and ease of management matter more than granular manual control:
- Frequently changing rules — servers where firewall rules need to change often without dropping active connections, such as web servers behind evolving security policies.
- 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
systemctland 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 iptables and firewalld ultimately try to control the same underlying kernel packet-filtering tables, so using them at the same time 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 firewalldiptables and firewalld: distro defaults
| Distribution family | Default firewall tool |
|---|---|
| RHEL / CentOS / Fedora (7+) | firewalld |
| Debian / Ubuntu | Neither by default — commonly ufw (an iptables frontend) or raw iptables/nftables |
| SUSE (recent versions) | firewalld |
Package availability and defaults can change between releases, so if you’re setting up a specific production system, it’s worth double-checking that distribution’s current documentation.
Frequently asked questions about iptables and firewalld
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, making it a better fit for most modern servers and desktops. iptables offers more granular, low-level control, which makes it 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, such as 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 on iptables and firewalld
There’s no single “correct” answer when it comes to iptables and firewalld — the right choice 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.