Iptables vs Firewalld
Linux firewall management is going through a generational transition. For over two decades, iptables has been the standard tool for controlling network traffic on Linux systems. But firewalld has emerged as the preferred solution on Red Hat-based distributions, bringing a different philosophy to packet filtering.
Iptables connects directly to the kernel's netfilter framework, giving you complete control over every aspect of packet filtering. It's powerful and flexible, but that power comes wrapped in complex syntax that takes time to master.
Firewalld sits at a higher level, organizing your firewall around zones and services rather than raw packet filtering rules. It manages iptables or nftables in the background while presenting a more structured interface for common security scenarios.
This guide examines both tools, showing you what makes each one useful and helping you understand which approach fits your infrastructure better.
What iptables brings to Linux
Iptables has been the standard Linux firewall tool since the early 2000s. It provides direct access to the kernel's netfilter packet filtering system, which means you can control exactly how your system handles network traffic.
The tool organizes rules into tables and chains. The most commonly used table is the filter table, which contains three chains: INPUT (for incoming packets), OUTPUT (for outgoing packets), and FORWARD (for packets being routed through the system). Each chain contains rules that match packets based on criteria you specify.
A basic iptables rule looks like this:
This appends a rule to the INPUT chain that accepts TCP packets destined for port 22 (SSH). The syntax is precise but dense - every flag matters, and the order of parameters can be significant.
Iptables handles both IPv4 and IPv6 traffic through separate commands: iptables for IPv4 and ip6tables for IPv6. This separation means you often need to write two versions of each rule to cover both protocols.
The tool excels at granular control. You can match packets based on source and destination addresses, ports, protocols, connection states, TCP flags, packet length, and dozens of other criteria. You can modify packet headers, redirect traffic, implement complex NAT configurations, and create sophisticated routing policies.
But this power comes with a learning curve. Iptables syntax is notoriously difficult to remember, especially for complex rules. The command structure is verbose and unforgiving - miss a flag or get the order wrong, and your rule either fails or does something unexpected.
With iptables' low-level approach established, you can see how firewalld takes a completely different path by adding structure and abstraction.
How firewalld organizes security
Firewalld appeared in the early 2010s as part of Red Hat's effort to modernize Linux firewall management. Instead of thinking about individual packet filtering rules, firewalld encourages you to think about network zones and services.
A zone represents a level of trust for network connections. The default zones include public (untrusted networks), home (trusted home network), work (corporate network), internal (private networks), dmz (public-facing services), and trusted (completely trusted networks).
Each network interface on your system gets assigned to a zone, and the zone determines what traffic is allowed. This maps better to how people actually think about network security - you trust your home network more than random public WiFi, so you apply different rules to each.
Services define what ports and protocols applications need. Instead of remembering that SSH uses port 22 and HTTP uses port 80, you reference services by name:
Firewalld includes service definitions for hundreds of common applications. Each service is defined in an XML file that specifies all the ports and protocols that application needs.
The tool separates runtime and permanent configurations. Changes you make without the --permanent flag take effect immediately but don't survive reboots. This lets you test changes safely before committing them.
Firewalld manages iptables rules automatically. Every zone, service, and rule you configure in firewalld gets translated into iptables rules that netfilter actually uses. On newer systems, firewalld can use nftables instead as its backend.
The zone-based model adds conceptual overhead initially but provides better organization for complex network configurations. Understanding both philosophies helps, but seeing them side by side makes the practical differences clearer.
Comparing approaches and capabilities
These tools operate at different abstraction levels, which affects everything about how you use them:
| Aspect | iptables | firewalld |
|---|---|---|
| Abstraction level | Low-level packet filtering | High-level zone management |
| Primary model | Chains and rules | Zones and services |
| IPv4/IPv6 handling | Separate commands | Unified interface |
| Configuration persistence | Manual save/restore | Automatic |
| Runtime changes | Immediate, permanent | Separate runtime/permanent |
| Service definitions | None | XML-based service files |
| Zone concept | Not supported | Core organizational principle |
| Default policies | Per-chain policies | Per-zone defaults |
| Rule inspection | List chains with rules | List zones with services |
| Backend flexibility | Direct netfilter interface | Can use iptables or nftables |
| NetworkManager integration | None | Automatic zone switching |
| Rich rules | Not a concept | Multi-criteria rules |
| Logging | Manual rule configuration | Integrated per-zone logging |
| Desktop integration | None | firewall-config GUI |
| Distribution adoption | Universal | RHEL, Fedora, CentOS, SUSE |
These architectural differences become concrete when you start creating actual firewall rules.
Writing rules with iptables
Iptables requires understanding its structure before you can create even simple rules. You work directly with chains, matches, and targets.
Setting default policies determines what happens to packets that don't match any rules:
These commands set the INPUT and FORWARD chains to drop unmatched packets while allowing all outgoing traffic.
Allowing SSH access:
Allowing established connections prevents you from needing rules for every response packet:
Restricting SSH to a specific network:
Viewing your configuration:
Deleting rules requires knowing their position:
For IPv6, you need separate commands that mirror your IPv4 rules. Maintaining parallel rulesets doubles your work and creates opportunities for inconsistencies.
Having seen iptables' manual approach, examining firewalld shows how zone-based organization changes the workflow.
Managing zones with firewalld
Firewalld's zone system requires a different mental model but provides better organization for complex networks.
Checking active zones and their interfaces:
Checking what's allowed in a zone:
Adding a service to a zone (runtime only):
Making it permanent:
Or make all runtime changes permanent at once:
Opening a specific port:
Restricting access with rich rules:
Creating a custom service requires an XML file:
After reloading, you can use it like any built-in service. The zone-based workflow takes more setup initially but scales better as your network grows more complex.
Advanced networking features
Where iptables and firewalld truly differ is in handling complex scenarios.
Port forwarding with iptables requires working with the nat table:
Firewalld handles the same operation with one command:
Masquerading (NAT for internet sharing) with iptables:
With firewalld:
Rate limiting in iptables uses the recent module:
Firewalld's rich rules provide complex matching in a more readable format:
Firewalld's abstractions make common operations simpler but give you less control over exactly how packets are processed. With capabilities covered, examining persistence shows different operational approaches.
Configuration persistence and management
Iptables rules exist only in memory until you explicitly save them. After making changes, you need distribution-specific commands to save them.
On Debian and Ubuntu:
Or manually:
The saved file format is iptables-restore's input format, which you can edit directly for bulk changes.
Firewalld handles persistence automatically. Every change you make with the --permanent flag gets written immediately:
Configuration lives in XML files in /etc/firewalld/zones/:
Backing up with iptables:
With firewalld:
Both formats version control cleanly with Git, though firewalld's XML is more human-readable while iptables-save format is more compact.
Integration and automation
Iptables operates independently of most system services. Logging goes through the kernel to syslog, which provides detailed packet information but isn't easy to parse.
Firewalld integrates more deeply with modern Linux. NetworkManager can automatically switch firewall zones when you connect to different networks. Logging connects through journald, making firewall events appear alongside other system events.
Both tools work with configuration management. Ansible example for iptables:
Ansible example for firewalld:
The firewalld module maps more naturally to firewalld's concepts, while iptables requires thinking about chains and rules even in Ansible.
Learning curves and expertise requirements
Iptables demands understanding of networking fundamentals - chains, tables, connection states, default policies, and rule evaluation order. Most people need several days before feeling comfortable, and weeks or months for complex scenarios.
The command syntax is dense:
Firewalld has a gentler curve. The zone concept takes getting used to, but basic operations make intuitive sense:
Most people can secure a basic system within an hour or two. However, rich rules can be as complicated as iptables commands, just with different syntax.
For building deep networking expertise, iptables forces you to learn fundamentals. Firewalld lets you accomplish security tasks without necessarily understanding packet-level details.
Final thoughts
This article looked at iptables and firewalld as two different ways to manage the same underlying firewall system.
Iptables stays important when you need full control and deep network knowledge, and its wide availability makes it a reliable base everywhere. Firewalld builds on top of that with zones and simpler concepts, which fits better when teams are mixed and networks are more complex.
In practice, many setups use both: firewalld for day-to-day management, iptables for special cases. The right choice depends on your distribution, your team’s skills, and how much low-level control you really need.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.