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.
Rule model: chains vs. zones
iptables organizes rules into linear chains evaluated top to bottom. 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 firewalld’s most practical advantages.
See it in action: an iptables rule chain
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP
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, 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. It also keeps 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. You’ll see this play out concretely in the reload demo further down this page.
Understanding 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 — try hovering the two zones below.
firewall-cmd --zone=public --add-service=ssh --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 each one.
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
The real-world stakes: reloading rules on a live server
Toggle the switch below to simulate adding a new rule to both firewalls while a connection is already open, and watch what happens to it.
# 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
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 |
| 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 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
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, 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.
Can iptables and firewalld run at the same time?
They can be installed together, but running both to manage the same rules at the same time is strongly discouraged. Both tools try to control the same underlying kernel packet-filtering tables, so using them simultaneously can cause 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 using systemctl.
Why did my SSH connection drop after an iptables reload?
iptables has no true live-reload mechanism. Applying a new ruleset usually means flushing the existing rules and rebuilding them, which briefly removes the rule that was keeping your SSH session alive. firewalld avoids this because it applies changes to the running configuration directly, without a full flush, so existing connections including SSH sessions stay intact.
Is firewalld built on iptables or nftables?
On modern Linux distributions, firewalld uses nftables as its backend. Older versions of firewalld used iptables directly. Either way, firewalld itself is a management layer sitting above the kernel’s packet-filtering system, not a packet filter in its own right.
What is the difference between an iptables chain and a firewalld zone?
A chain in iptables is a linear, ordered list of rules that a packet is checked against sequentially. A zone in firewalld is a named trust level, such as public or home, assigned to a network interface, and it determines which services and ports are allowed for that interface as a whole. Zones group related rules by trust level; chains are simply an evaluation order.
Which one does RHEL, CentOS, or Fedora use by default?
firewalld has been the default firewall management tool since RHEL 7 and Fedora 18. Debian and Ubuntu don’t enable either by default, though they commonly use ufw, which is itself a simplified frontend for iptables.
Do I need to learn iptables if I only use firewalld?
Not strictly, since firewalld’s zone and service commands cover most day-to-day needs. That said, understanding iptables concepts such as chains, tables, and rule ordering makes it easier to reason about what firewalld is doing under the hood, and becomes necessary if you ever need to debug at the nftables or iptables level directly, or work on a system where firewalld isn’t installed.
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.