nftables vs iptables: Linux Firewall Setup

Published on: October 07, 2025

.

38 min read

.

For German Version

Firewalls are the first line of security between your Linux system and the outside world. Firewalls are basically packet filters. They look at network traffic that is coming in and going out, compare it to rules that have already been set, and then determine whether to let it through, block it, or drop it. This filtering is important for both servers and desktops because it makes sure that only valid, expected traffic gets to applications and that malicious or unauthorized packets are blocked.

Not only is a firewall on Linux a utility, but it's also part of the kernel networking stack. Linux has very efficient traffic control that can work on anything from a personal laptop to a high-performance data center router. This is because packet filtering is built right into the kernel. A correctly set up firewall is not an option for system administrators; it is necessary to keep services private, secure, and available.

In the past, Linux employed iptables, which is a user-space tool that works with the kernel's Netfilter framework. For almost twenty years, iptables was the norm. It powered everything from personal firewalls to enterprise gateways. But as time went on, its syntax became hard to use, it was hard to keep track of rules that were the same, and it had trouble growing in big situations.

The Linux kernel added nftables to fix these problems. Nftables is the current replacement for IPv4, IPv6, ARP, and other protocols. It puts them all under one set of rules. It makes it easier to write rules, cuts down on duplication, and adds strong ideas like sets and maps. This lets administrators manage big collections of rules in a smart and efficient way. In addition to making things easier to read, nftables speeds things up a lot by changing how rules are checked and applied.

At the same time, a lot of distributions also push firewalld, which is a front-end manager that makes iptables or nftables easier to use. Administrators can use zones (trust levels for networks) and services (predefined port/protocol combinations) to set policies instead of developing low-level rules. This is very helpful for those who aren't very good with computers or for automated deployment systems because it makes configuration easier while still using the Netfilter engine.

The change from iptables to nftables wasn't just for show; it was to fix long-standing problems with the architecture. With iptables, rules were implemented one after the other, which made things less efficient. Administrators also often copied rules from IPv4 to IPv6 tables.

It was easy to make mistakes when keeping track of big, complicated rulesets.

nftables fixes these problems by:

• Using the same syntax for all protocols.

• Allowing atomic updates, which replace the whole ruleset in one action (stopping partial updates that could interrupt traffic).

• Making it easier to scale by allowing thousands of rules to be handled without a big drop in performance.

• Giving counters and debugging tools to make things easier to see.

Big Changes Above iptables

Some of the most important benefits of nftables are:

• Efficiency: Optimized evaluation makes it faster to match packets.
• Scalability: Sets and maps let you use one rule to manage more than one address or port.
• Easier Syntax: Having one ruleset for both IPv4 and IPv6 cuts down on repetition and makes things easier.
• Unified Tooling: The nft command takes the place of several other tools, such as iptables, ip6tables, arptables, and ebtables.

firewalld: Making Things Easier

Not all administrators want or need to write raw firewall rules. This is when firewalld comes in handy. As a policy manager, it:

• Puts rules into groups like "public," "internal," or "dmz."
• Sets up services like SSH, HTTP, or DNS to automatically open the right ports.
• Changes are applied dynamically without closing current connections.

Firewalld is easier to use than iptables or nftables for managing Linux firewalls, but it still uses them underneath. For advanced users, nftables is still the most configurable option, but firewalld makes it easier for more people to administer firewalls.

What are Linux Firewalls?

A Linux firewall is a security tool that controls what network traffic can enter, depart, or pass through your system. It works as a traffic filter at its most basic level. Every packet of data that tries to traverse your network interfaces is checked against a set of rules that have already been configured. If it matches an allow rule, it goes through; if it matches a deny rule, it is blocked or dumped without a sound.

This may sound vague, but in reality, it is one of the best protections you can use. Firewalls protect you against both obvious attacks and services that you didn't even know were operating that could be exposed by accident.

• Control: Firewalls in Linux let you decide what traffic can reach services on your machine, such SSH and HTTP.

• Isolation: Keep trusted networks (like your office LAN) apart from untrusted ones (like the internet).

• Enforcement: Make sure that security policies are always followed to meet the needs of the organization or the law.

• Visibility: Keep track of and log all attempted connections to find any suspicious or illegal behavior.

How Linux Firewalls Work

The Netfilter framework, which is part of the Linux kernel, is what (Linux firewalls)[/docs/network-security-tutorials/best-linux-firewall-solutions-in-2022] use to work. When packets come in or go out of your computer, Netfilter stops them and checks them against your firewall rules. Tools like iptables (old) or nftables (new) take care of these rules.

Chains are smaller groupings of checkpoints that packets pass through. Tables are bigger groups of chains.

• Tables tell the computer what kind of filtering to do (filtering, NAT, packet modification).

• Chains tell the packet where to go (input, output, forward).

• Rules are the exact orders (allow, drop, refuse, log).

You may see this in action by running the following command:

sudo nft list ruleset  

This will show all the rules that are currently loaded, such as filtering, NAT, and custom chains.

On older systems still using iptables, the equivalent is:

sudo iptables -L -v -n  

Here you’ll see the filter table with its chains and counters showing how many packets matched each rule. After running these commands, you can interpret the output to understand your firewall posture. For example, if the default policy of the INPUT chain is ACCEPT and there are no rules, it means your system is wide open to incoming connections.

Firewalls on Different Types of Systems

• On Servers: They limit exposure of sensitive services. For example, a web server might only allow ports 80/443 while blocking everything else.

• On Desktops/Laptops: They protect personal devices when connecting to untrusted Wi-Fi networks by silently dropping unsolicited connections.

• On Routers/Gateways: They enforce boundaries between internal (trusted) and external (untrusted) networks.

To illustrate, let’s allow only web traffic (HTTP/HTTPS) and drop everything else with nftables:

sudo nft add rule inet filter input tcp dport {80,443} accept  
sudo nft add rule inet filter input drop  

With just two lines, the firewall ensures only web traffic is accepted. Any other incoming traffic is denied, even if a service is accidentally running.

Tools for Managing Linux Firewalls

There are three main tools to manage Linux firewalls you’ll encounter:

1. iptables – The legacy firewall management tool, widely used but verbose.
2. nftables – The modern replacement, with cleaner syntax and better scalability.
3. firewalld – A higher-level abstraction that manages iptables or nftables under the hood, organizing rules into zones and services.

For example, using firewalld you could allow SSH like this:

sudo firewall-cmd --zone=public --add-service=ssh --permanent  
sudo firewall-cmd --reload  

This is much simpler than writing raw nftables rules, especially for beginners or in automated environments. Linux firewalls are packet filters at the heart of system security. They decide what comes in, what goes out, and what gets logged for later analysis. Whether managed with iptables, nftables, or firewalld, they play a critical role in protecting Linux systems across servers, desktops, and gateways.

The key takeaway: without a firewall, your Linux system is defenseless at the network layer. With one, you can enforce strict policies, minimize risks, and keep both personal and enterprise environments safe.

Why are Linux Firewalls Important?

Linux firewalls are a core component of system security. They enforce security policies by regulating inbound and outbound traffic, ensuring only authorized communication is allowed. By controlling how packets move through the system, firewalls minimize exposure to attacks, prevent unauthorized access, and contribute to compliance and layered defense strategies.

The Role of Firewalls in System Security

At the heart of Linux security, firewalls serve as gatekeepers. Every packet entering or leaving the system is evaluated against firewall rules. Without them, any open service—even one you forgot was running—could become a backdoor for attackers.

For example, consider a web server. While you need to allow HTTP and HTTPS traffic, you might want to block or restrict access to SSH. A firewall ensures these boundaries are respected, reducing the risk of unauthorized logins or data exfiltration.

# Allow only HTTP/HTTPS
sudo nft add rule inet filter input tcp dport {80,443} accept  
# Drop everything else
sudo nft add rule inet filter input drop  

With just two rules, you establish a baseline of “only what is needed”, which is a cornerstone of system security.

Regulating Inbound and Outbound Traffic

Linux firewalls operate bidirectionally:

• Inbound filtering protects services by restricting who can connect and from where.

• Outbound filtering prevents compromised systems from calling home or spreading malware.

For instance, you can block all outgoing SMTP traffic except from your mail server:

sudo iptables -A OUTPUT -p tcp --dport 25 -d 203.0.113.5 -j ACCEPT  
sudo iptables -A OUTPUT -p tcp --dport 25 -j DROP  

This ensures that only the designated mail server communicates on port 25, while other applications are denied.

Minimizing Exposure to Attacks

Most attacks begin with scanning. Bots and malicious actors continuously probe IP ranges, looking for open ports or misconfigured services. A properly configured firewall reduces the visible “surface area” of your system, so attackers have fewer opportunities. For example, brute-force SSH attempts are one of the most common attacks on internet-facing servers. A firewall can mitigate these risks by allowing SSH only from trusted subnets:

sudo nft add rule inet filter input ip saddr 192.0.2.0/24 tcp dport 22 accept  
sudo nft add rule inet filter input tcp dport 22 drop  

Now only machines in your office network can attempt SSH connections, blocking the rest of the internet.

Ensuring Compliance and Layered Defense

In enterprise environments, firewalls are also tied to compliance frameworks such as PCI-DSS (payments), HIPAA (healthcare), and GDPR (data protection). These standards mandate access control at the network layer, making firewalls not just good practice but a legal and regulatory requirement. Beyond compliance, firewalls are part of a layered defense strategy:

• Application security defends against software flaws.

• User access control limits what users can do.

• Firewalls ensure that even if an attacker bypasses one layer, they still face barriers at the network level.

Example: Logging dropped packets for compliance auditing

sudo nft add rule inet filter input log prefix "NFT-DROP: " counter drop  

This ensures that every dropped connection attempt is logged for review, providing evidence during audits.

Linux firewalls are not optional—they are critical guardians of system security. By regulating inbound and outbound traffic, they reduce exposure to attacks, enforce least-privilege principles, and provide essential visibility into network activity. In enterprise and regulated environments, they are also a key part of compliance and layered defense strategies. In short: Without a firewall, your Linux system is unnecessarily exposed; with one, you gain control, resilience, and trustworthiness.

What are iptables?

iptables is a tool that runs in user space on Linux systems that lets administrators set up and manage firewall rules. It is the command-line interface for the Netfilter framework in the Linux kernel. This lets you filter packets, regulate traffic, and do Network Address Translation (NAT).

Using iptables in User Space

The Linux kernel does the actual packet filtering, but administrators need a mechanism to tell the kernel what to do with each packet. That is what iptables does. It runs in user space and sends these instructions to Netfilter. You can think of iptables as the "language" you use to instruct the kernel what to do with network traffic.

For instance, to see your current firewall rules in the filter table, you would do this:

sudo iptables -L -v –n  

This displays all active rules, showing which ports and IPs are allowed or denied, along with counters indicating how many packets matched each rule.

Using Netfilter with iptables

Netfilter is the Linux kernel framework that looks at and changes packets as they move through the networking stack. It has "hooks" that let you filter, NAT, or change packets. Administrators can use iptables to connect to these hooks and set rules like:

• Allow packets on port 22 (SSH).

• Drop packets from a suspicious IP address.

• Translate (NAT) private IP addresses to a public IP.

Example- Allowing SSH traffic through iptables:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

Here, iptables instructs Netfilter to accept any TCP packet destined for port 22.

Organizing Firewall Rules in a Structured Way

iptables organizes firewall rules in a structured way: tables → chains → rules.

• Tables are categories of processing:

  • filter: Default table, responsible for basic packet filtering.
  • nat: Handles address translation (e.g., port forwarding, masquerading).
  • mangle: Alters packet headers for advanced routing/QoS.
  • raw: Provides connection tracking exemptions.

• Chains are checkpoints where packets are examined:

  • INPUT: Packets coming to the local system.
  • OUTPUT: Packets generated by the system.
  • FORWARD: Packets routed through the system.

• Rules are the specific instructions (allow, drop, reject, log).

For example, to set a default policy and then allow SSH:

sudo iptables -P INPUT DROP  
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT  
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

This configuration:

1. Drops all incoming traffic by default.

2. Allows responses to existing connections.

3. Allows new SSH connections on port 22.

Historical Role in Packet Filtering and NAT

iptables has been the main firewall tool for Linux for about 20 years, since it was first included to the Linux kernel in 2001. It took the place of the earlier ipchains tool and became known as the Linux firewall.

In the past, iptables was used for:

• Packet Filtering: Enforcing access control policies on incoming and outgoing traffic.
• NAT (Network Address Translation): Rewriting IP headers so that multiple devices could share one public IP.
• Masquerading: A special form of NAT, often used in home or office networks.
• Port Forwarding: Redirecting requests from one port/IP to another.

Example: Enabling NAT with iptables:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  

This rule allows multiple devices on a private LAN to share a single public IP through interface eth0.

In short, iptables is not the firewall itself; it is a user-space utility. It is the interface to Netfilter, which is the real packet filtering engine in the Linux kernel. It groups rules into tables and chains, which lets you construct complicated firewall rules. For almost 20 years, iptables has been the main tool for packet filtering and NAT on Linux. It has formed the backbone of both small and large firewalls.

Even though iptables is now considered outdated, system administrators still need to know how to use it in order to keep systems running and comprehend the advancements made by its successor, nftables.

How do iptables Work?

Iptables operates by sending packets of data through tables of rules. It checks each packet in order, and when the conditions of a rule are met (such the protocol, port, or source IP), the action that was set up as the "target" is taken. These actions can either accept the packet, drop it without saying anything, reject it with an error, or log it for later review.

Chains: INPUT, OUTPUT, and FORWARD

iptables uses chains to arrange traffic filtering. Chains show the different stages of a packet's journey:

• INPUT → For packets destined to the local machine (e.g., SSH access to a server).

• OUTPUT → For packets originating from the local machine (e.g., a curl request to download updates).

• FORWARD → For packets passing through the machine when it acts as a router.

Example: Listing the INPUT chain with verbose output:

sudo iptables -L INPUT -v -n  

This shows all the rules applied to incoming traffic and how many packets matched each rule.

Sequential Rule Evaluation

iptables checks rules one at a time, in order. The first rule that matches decides what happens to the packet. The chain's default policy is used if no rules match.

For instance, let's let SSH go first and then get rid of everything else:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  
sudo iptables -A INPUT -j DROP  

When a packet arrives on port 22 (SSH), the first rule matches, and the connection is allowed. All other packets fall to the second rule and are dropped.

Matching Conditions: Protocol, Port, IP

Rules are defined by conditions such as:

• Protocol (-p tcp, -p udp, -p icmp)

• Source/Destination IP (-s 192.0.2.0/24, -d 203.0.113.5)

• Ports (--dport 80, --sport 53)

• Connection state (-m conntrack --ctstate ESTABLISHED)

Example: Allow HTTP traffic only from a trusted subnet:

sudo iptables -A INPUT -p tcp -s 192.0.2.0/24 --dport 80 -j ACCEPT  

This means: If the packet is TCP, comes from the subnet 192.0.2.0/24, and is destined for port 80 → accept it.

Common Actions (Targets): ACCEPT, DROP, REJECT, LOG

Once a rule matches, iptables applies a target:

• ACCEPT → Let the packet through.

• DROP → Silently discard it (no response to the sender).

• REJECT → Deny the packet and send back an error (e.g., ICMP “port unreachable”).

• LOG → Record the packet details in system logs, then continue to the next rule.

Example: Logging and dropping all other traffic except SSH:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROP: "  
sudo iptables -A INPUT -j DROP  

• Rule 1 → Accept SSH connections.

• Rule 2 → Log anything else with the prefix “IPTABLES-DROP.”

• Rule 3 → Drop the packet.

iptables operates by sending packets through chains of rules that are checked one at a time. Conditions like protocol, IP, and port set rules, while actions like ACCEPT, DROP, REJECT, and LOG decide what happens to the packet. This model shows that iptables is a strong but often complicated firewall tool. To design a safe and working ruleset, the order and specificity of the rules are very important.

What is nftables?

Introduced in kernel version 3.13 (2014), nftables is the new firewall framework for Linux that is meant to replace iptables. It has a single interface for filtering packets, NAT, and classifying traffic over IPv4, IPv6, ARP, and bridging. All of this is done with a simpler syntax and better scalability.

nftables as the Modern Framework

For almost twenty years, iptables was the main part of Linux firewalls. But in big, changing contexts, it became evident that it was too complicated, duplicated, and slow. Linux developers came up with nftables to fix these problems. It is a simpler and more efficient approach to set up the Netfilter framework.

iptables needed several tools (iptables, ip6tables, arptables, ebtables), whereas nftables has a single command-line program that works with all of them:

sudo nft list ruleset  

This one command shows all active rules across protocols, eliminating the fragmentation of the older tools.

Integration from Linux Kernel 3.13 Onward

Starting with version 3.13 (January 2014), nftables was added to the Linux kernel. Most major distributions (Debian, Ubuntu, RHEL, Fedora, Arch) have since adopted it as the default firewall backend. They commonly use iptables-nft compatibility layers to make sure older scripts work throughout the transition.

To see if your system supports nftables:

uname –r

You can use nftables if your kernel version is 3.13 or newer. Most contemporary distributions come with it already installed.

Unified Handling of IPv4, IPv6, ARP, and Bridging

One of nftables’ biggest advantages is its ability to handle multiple protocol families in one ruleset.

• inet → IPv4 + IPv6

• ip → IPv4 only

• ip6 → IPv6 only

• arp → ARP traffic

• bridge → Bridged packets

For example, with iptables, you would need separate commands for IPv4 and IPv6 SSH rules. With nftables, one rule is enough:

nft add rule inet filter input tcp dport 22 accept

This single rule applies to both IPv4 and IPv6, greatly reducing duplication.

Simplified Syntax and Better Scalability

The syntax for nftables is meant to be clean, consistent, and easy to script. You may arrange IP addresses, ports, or ranges into sets and maps instead of typing complex commands over and again.

For example: Allow HTTP/HTTPS and SSH from a trusted subnet with only one rule:

table inet filter {
set allowed_ports {
type inet_service;
elements = { 22, 80, 443 }
}
chain input {
type filter hook input priority 0; policy drop;
ip saddr 192.0.2.0/24 tcp dport @allowed_ports accept
}
}

This concise syntax makes complex firewalls easier to read, maintain, and audit.

Scalability improvements include:

• Atomic rule replacement: Entire rulesets are swapped in one operation, avoiding inconsistent states.

• Efficient lookups: Sets and maps allow thousands of entries to be matched quickly.

• Counters and monitoring: Built-in tools provide detailed visibility into rule hits and traffic statistics.

The Linux kernel has had nftables since version 3.13. It is a contemporary, unified firewall system. It makes managing firewalls easier by bringing together IPv4, IPv6, ARP, and bridging into one tool. This program has cleaner syntax and is much more scalable than iptables. Today, nftables is the best way to make firewalls on Linux systems that are efficient, easy to manage, and ready for the future.

Why is nftables Considered the iptables Replacement?

For almost 20 years, iptables was the most common way to set up a Linux firewall. But as systems got more complicated and networks got bigger, its flaws became obvious. To fix these issues, nftables was added to the Linux kernel 3.13 as a new way to do things. Because it makes management easier, speeds things up, and makes features work the same way across protocols, nftables is now the default firewall framework.

The Limitations of iptables

iptables served well for many years but suffers from several architectural issues:

• Rule duplication: Separate binaries (iptables for IPv4, ip6tables for IPv6, arptables, and ebtables) meant administrators often had to duplicate the same logic across multiple tools.

• Inefficiency: Rules are evaluated sequentially, so large rule sets significantly impact performance.

• Complexity: The syntax is verbose, and even small misconfigurations can create major security holes.

• Maintainability: Large iptables configurations are hard to audit, debug, and adapt to fast-changing environments like cloud or containers.

Example — allowing SSH for both IPv4 and IPv6 with iptables:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT  

Here you must write separate rules for IPv4 and IPv6, doubling the maintenance effort which exhibits inefficiency and complexity.

Unified Rule Set with nftables

nftables was designed to overcome these limitations by introducing a unified ruleset. Instead of separate tools for each protocol, nftables handles IPv4, IPv6, ARP, and bridging under one umbrella.

Example — allowing SSH for both IPv4 and IPv6 with nftables:

nft add rule inet filter input tcp dport 22 accept

One simple rule replaces two or more iptables commands, immediately reducing duplication and configuration errors.

Performance and Maintainability Benefits

nftables brings multiple technical improvements:

• Performance: Rules are evaluated more efficiently, and sets/maps allow bulk matching (e.g., thousands of IPs in one rule).

• Atomic updates: You can replace the entire ruleset in one operation, avoiding half-applied configurations.

• Cleaner syntax: Rules are shorter, more readable, and easier to maintain.

• Debugging and visibility: Built-in counters and logging make it easier to monitor rule usage.

Example — allowing multiple ports in one rule with nftables:

nft add rule inet filter input tcp dport {22,80,443} accept

In iptables, you would need three separate rules for the same effect.

Adoption in Modern Linux Systems

Most modern distributions have made nftables the default firewall backend:

• Debian switched to nftables by default from Buster (10).

• Ubuntu defaults to nftables in newer releases, while still supporting iptables for compatibility.

• RHEL 8 and Fedora also use nftables as the underlying framework, even when managed via firewalld.

This adoption means that nftables is no longer an optional upgrade; it is now the standard for Linux firewalls. As iptables is now officially in legacy maintenance mode, administrators are urged to move.

Because it fixes the problems of iptables, nftables is thought to be the best solution. nftables is a modern, scalable, and maintainable firewall foundation for today's systems. It combines IPv4, IPv6, ARP, and bridging rules, has a simpler syntax, improves speed using sets and atomic updates, and is the default across most Linux versions.

Does firewalld Use iptables or nftables?

Yes, firewalld does use iptables or nftables, but not both at the same time. It is a layer for managing firewalls that sits on top of the Linux kernel's Netfilter framework. It does not filter packets on its own. Instead, it turns easy-to-understand rules into the backend firewall engine that is available on the host.

firewalld as a Firewall Management Layer

firewalld was created to make firewall configuration easier. Instead of writing complex iptables or nftables commands, administrators can manage firewall policies with zones (levels of trust) and services (predefined port/protocol groups).

For example, opening SSH in the public zone is as simple as:

sudo firewall-cmd --zone=public --add-service=ssh --permanent  
sudo firewall-cmd --reload  

Behind the scenes, firewalld translates this request into iptables or nftables rules depending on which backend the system is used.

Iptables is used on relatively older Systems while nftables is used on newer ones.

• Older Linux distributions (e.g., CentOS 7, RHEL 7, Ubuntu 18.04) used iptables as the backend for firewalld.

• Modern distributions (e.g., Fedora 32+, RHEL 8+, Ubuntu 20.04 and later) switched to nftables as the backend, since iptables is now legacy.

This transition allows firewalld to continue working seamlessly, while benefiting from nftables’ unified rule set and improved scalability.

Example — opening HTTP in Fedora (uses nftables underneath):

sudo firewall-cmd --zone=public --add-service=http  

The user only sees firewalld commands, but nftables rules are being applied in the background.

How to Check which Backend firewalld Uses

You can verify which backend your system is running.

First, check if firewalld is active:

sudo firewall-cmd --state  

If it returns running, firewalld is managing your firewall.

To see the backend, inspect system logs:

sudo journalctl -u firewalld | grep "Using backend"  

Typical outputs include:

• Using iptables backend → firewalld is managing iptables.

• Using nftables backend → firewalld is managing nftables.

One of firewalld's best features is that it immediately works with the system's default firewall engine. Administrators don't have to worry about whether the underlying framework is iptables or nftables; the commands are always the same.

This makes firewalld very useful in businesses where there are many different versions and distributions of Linux. It makes sure that the administration layer is always the same, even when the backends are different.

Firewalld doesn't filter packets on its own; it manages the Linux firewall through a backend. It used iptables on older systems and nftables on newer ones. You may check the backend by looking at system logs or using firewall-cmd. Firewalld automatically adjusts to whichever engine is running, making it easier to maintain firewalls and making them more consistent across all Linux distributions.

How does firewalld Work on Linux Systems?

firewalld is a daemon that automatically controls the Linux kernel's Netfilter firewall. This makes it easier and more flexible to set up network rules. With static tools like iptables or nftables, every change usually requires reloading the whole ruleset. But with firewalld, admins may alter policies on the fly without stopping active connections.

firewalld as a Dynamic Netfilter Manager

Firewalld is a background service (daemon) that turns easy-to-understand firewall ideas into Netfilter rules. It can handle both IPv4 and IPv6 traffic, and it uses either iptables or nftables as its backend, depending on the system.

You can see what it's doing right now with:

sudo firewall-cmd --state  

If it returns running, the daemon is active and controlling the firewall.

Zones and Services

firewalld introduces the concepts of zones and services to simplify firewall management:

• Zones: Predefined trust levels that describe how restrictive the firewall should be. Examples:

  • public → for untrusted networks like Wi-Fi hotspots.

  • home → for private, trusted environments.

  • dmz → for servers exposed to the internet.

• Services: Preconfigured groups of rules representing common protocols and ports (e.g., SSH, HTTP, DNS).

For example, to allow HTTPS traffic in the public zone:

sudo firewall-cmd --zone=public --add-service=https --permanent  
sudo firewall-cmd --reload  

This immediately configures the firewall to accept HTTPS connections without needing to know the exact port (443/TCP).

Dynamic Rule Application Without Restarts

One of the best things about firewalld is that it can make adjustments on the fly. You can add or remove a rule right away, and the active ruleset will be updated. There is no need to restart the service or lose connections.

For example, opening SSH on the fly for testing:

sudo firewall-cmd --add-service=ssh  

This applies instantly. If you are satisfied, you can make it permanent:

sudo firewall-cmd --add-service=ssh --permanent  

sudo firewall-cmd --reload  

Integration with NetworkManager and systemd

firewalld integrates tightly with other core Linux services:

• NetworkManager: firewalld can automatically switch firewall zones depending on the network connection. For example, when you connect your laptop to a home Wi-Fi, the interface may be assigned the home zone, but when you connect to public Wi-Fi, it switches to public automatically.

• systemd: firewalld runs as a systemd service, making it easy to manage, enable, or disable at boot.

sudo systemctl status firewalld  
sudo systemctl enable firewalld  
sudo systemctl disable firewalld  

This makes sure that the firewall stays on even after a reboot and works with other system services.

As a dynamic daemon on top of Netfilter, firewalld manages firewall rules in real time without stopping connections. It makes complicated settings easier to understand by grouping rules into services and zones. It works well with NetworkManager, so changes to zones follow network connections. Systemd makes sure that services start up and run smoothly.

In brief, firewalld makes Linux firewalls more flexible, adaptable, and easier to maintain, especially when network conditions change often.

How does iptables Filter Network Traffic?

When packets flow via the Linux kernel's Netfilter hooks, iptables checks them against a set of rules and then takes an action, like ACCEPT, DROP, or REJECT. Each packet's properties, such as its source IP, destination port, and protocol, are tested one by one against a set of rules in chains until a match is found or the chain's default policy chooses what to do.

Packet Inspection Process

The Netfilter framework stops every network packet that comes into or leaves a Linux system. Netfilter uses iptables to figure out what to do with these packets.

For instance, when a TCP packet comes in and is meant for port 22 (SSH), Netfilter checks it against the rules in the INPUT chain.

You may see all of the active packet-filtering rules by using:

sudo iptables -L -v -n  

This shows the chains, their policies, and how many packets have matched each rule so far.

Condition Matching: IP, Port, Protocol

iptables rules specify conditions that packets must meet to trigger an action. Common conditions include:

• Protocol: -p tcp, -p udp, -p icmp

• Source/Destination IP: -s 192.0.2.0/24, -d 203.0.113.5

• Port Numbers: --dport 80, --sport 53

Example: Allow HTTP requests only from a trusted subnet:

sudo iptables -A INPUT -p tcp -s 192.0.2.0/24 --dport 80 -j ACCEPT  

This rule allows packets if they are TCP, come from the 192.0.2.0/24 subnet, and are destined for port 80.

Rule Evaluation Through Chains

Rules are grouped into chains. Packets travel through these chains depending on their direction:

• INPUT → For packets coming into the local system.

• OUTPUT → For packets leaving the system.

• FORWARD → For packets passing through the system as a router.

Rules inside a chain are evaluated sequentially. The first matching rule determines the packet’s fate.

Example:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

sudo iptables -A INPUT -j DROP  

• If a packet matches port 22 (SSH), it is accepted immediately.

• Otherwise, it falls to the second rule and is dropped.

Possible Outcomes: ACCEPT, DROP, REJECT

Once a rule matches, iptables applies a target action:

• ACCEPT → Allow the packet through.

• DROP → Silently discard the packet (no response sent).

• REJECT → Block the packet and notify the sender with an error (e.g., ICMP “port unreachable”).

Example: Logging and rejecting all other traffic except SSH:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  
sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-REJECT: "  
sudo iptables -A INPUT -j REJECT  

This configuration allows SSH, logs all other attempts with the prefix “IPTABLES-REJECT” and rejects them with an error.

It is possible for iptables to filter traffic by looking at packets, comparing them to rule conditions (IP, port, protocol), and taking actions in chains. The first matching rule or the chain's default policy decides what happens to each packet. The options are ACCEPT, DROP, or REJECT. This feature makes iptables a strong but order-sensitive firewall system where drafting rules carefully is very important.

What does nftables do Better Than iptables?

nftables is better than iptables because it has a single ruleset model, cuts down on duplication, speeds things up, and makes managing firewalls easier using syntax that is more flexible and easier to maintain. It was developed to fix the problems that have made iptables hard to use and slow in big, modern environments for a long time.

A Model with Only One Set of Rules

Iptables needs different tools and rules for IPv4 (iptables), IPv6 (ip6tables), ARP (arptables), and bridging (ebtables). Nftables, on the other hand, puts everything into one ruleset that the nft command manages.

Example: Using nftables to let SSH work in both IPv4 and IPv6:

nft add rule inet filter input tcp dport 22 accept

This one line works for both IPv4 and IPv6 traffic. With iptables, you would need at least two different commands to do the same thing.

Less Duplication and More Efficiency

When you use iptables, simple firewall settings quickly become the same. Sets and maps are supported by nftables, which fixes this problem. These let you match more than one value in a single rule, such as ports, IP addresses, or networks.

For example, you can allow more than one service in one rule:

table inet filter {
set allowed_ports {
type inet_service;
elements = { 22, 80, 443 }
}
chain input {
type filter hook input priority 0; policy drop;
tcp dport @allowed_ports accept
}
}

Instead of writing three separate rules for SSH, HTTP, and HTTPS, nftables does it in one, making the ruleset shorter and easier to maintain.

Performance Improvements in Rule Evaluation

Iptables checks each rule in succession until it finds one that matches. In large environments with thousands of rules, this slows down performance.

nftables has a better way to evaluate things:

• Uses sets and hash tables to speed up searches.

• Allows atomic changes, which means that the whole ruleset can be changed in one action. • Reduces downtime and prevents inconsistent states during reloads.

In real life, this means that nftables works far better than iptables for big, complicated firewalls.

Flexibility and Maintainability Benefits

Beyond performance, nftables is significantly easier to read, audit, and maintain:

• Simplified syntax: Rules are shorter and more consistent.

• Extensibility: Supports new protocols without redesign.

• Better debugging: Built-in counters show exactly how many packets match each rule.

• Atomic configuration: Rulesets can be written in structured files and loaded in one go.

Example — reload a configuration file:

sudo nft -f /etc/nftables.conf  

This makes sure that the new configuration is deployed in full, so that partial updates don't break connectivity.

It is superior than iptables since it uses a single set of rules for all protocols.

• Gets rid of duplicates with sets and maps.
• Makes things faster by using efficient evaluation and atomic updates.
• Gives firewalls more flexibility and makes them easier to handle at scale.

This combination makes nftables the best firewall framework for modern Linux systems and the inevitable next step after iptables.

How do you Check if firewalld Is Using iptables or nftables?

Depending on the version and distribution, firewalld can utilize either iptables or nftables as its backend. It's crucial to know which one your system is utilizing right now so you don't become confused. This is how you can check.

1. Verify firewalld is Running

Before checking the backend, confirm that firewalld is active:

sudo firewall-cmd --state  

Expected output:

• running → firewalld is active.

• not running → firewalld is not managing the firewall.

2. Check Backend via System Logs

firewalld reports which backend it is using when it starts. You can view this in the journal logs:

sudo journalctl -u firewalld | grep "Using backend"  

Possible outputs:

• Using iptables backend.

• Using nftables backend.

This is the most direct way to confirm.

3. Inspect with firewall-cmd

Although firewall-cmd does not directly print the backend, it can hint at the backend by the way rules are structured. For example, after adding a rule:

sudo firewall-cmd --zone=public --add-service=ssh  
sudo firewall-cmd --list-all  

• On iptables-based systems, the rules will be translated into iptables commands in the background.

• On nftables-based systems, the translation will go through the nftables ruleset.

To see the active low-level rules, run:

sudo iptables -L -n  
sudo nft list ruleset  

• If iptables -L shows rules but nft list ruleset is empty → firewalld is using iptables.

• If nft list ruleset shows rules → firewalld is using nftables.

4. Distro and Version Defaults

Different distributions default to different backends:

• CentOS 7 / RHEL 7 / Ubuntu 18.04 → firewalld uses iptables by default.

• Fedora 32+, RHEL 8+, Debian 10+, Ubuntu 20.04+ → firewalld defaults to nftables.

Checking your OS version can give you a good idea:

cat /etc/os-release

5. Recognizing the Difference in Outputs

• With iptables backend, you manage rules with:

  sudo iptables -L -v -n  

• With nftables backend, you view rules using:

  sudo nft list ruleset  

When you run nft list ruleset on an iptables backend system, the output will be empty. You will observe a structured ruleset with tables, chains, and counters on nftables systems.

To find out if firewalld is utilizing iptables or nftables:

1. Check that firewalld is operating (firewall-cmd --state).

2. Look at the logs (journalctl -u firewalld | grep "Using backend").

3. Use iptables -L and nft list ruleset to look at rulesets.

4. Think about what version of your distribution you have (earlier → iptables, modern → nftables).

5. Look at the outputs: nftables rulesets look structured and unified, while iptables rulesets look flat.

How do you Migrate iptables Rules to nftables?

Moving from iptables to nftables is very important since iptables is now considered old and nftables is the framework that is still being worked on and recommended. Migration makes sure that things will work together in the long run, makes it easier to maintain rules, and speeds up the firewall.

Here's how to move safely step by step.

1. Understand the Need for Migration

• iptables is legacy: It’s in maintenance mode and will not receive major new features.

• nftables is the default: Modern distributions (RHEL 8+, Debian 10+, Ubuntu 20.04+, Fedora 32+) use nftables by default.

• Unified ruleset: nftables handles IPv4, IPv6, ARP, and bridging with one ruleset, eliminating duplication.

2. Export Existing iptables Rules

Before migrating, back up your current iptables configuration to a file.

sudo iptables-save > /root/iptables.backup.v4  
sudo ip6tables-save > /root/iptables.backup.v6  

This ensures you have a copy of your IPv4 and IPv6 rules that can be restored if needed.

3. Use Translation Tools

Linux provides utilities to translate iptables rules into nftables syntax:

• iptables-translate: Converts a single iptables command into an nftables command.

• iptables-restore-translate: Converts a full iptables-save file into an nftables ruleset.

Example — translate a single rule:

sudo iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT  

Output:

nft add rule ip filter INPUT tcp dport 22 counter accept

Example — translate a full ruleset:

sudo iptables-save > /tmp/iptables.rules  
sudo iptables-restore-translate -f /tmp/iptables.rules > /tmp/nftables.rules  

Now /tmp/nftables.rules contains the equivalent nftables configuration.

4. Load the nftables Ruleset

Once translated, test the nftables rules by loading them into the kernel:

sudo nft -f /tmp/nftables.rules  

Verify that the rules were applied:

sudo nft list ruleset  

If everything looks correct, you can move the rules to the persistent configuration file:

sudo cp /tmp/nftables.rules /etc/nftables.conf  
sudo systemctl enable nftables  
sudo systemctl restart nftables  

5. Test After Migration

After migration, carefully test connectivity:

• Check SSH access (to ensure you’re not locked out).

• Ping the server to verify ICMP traffic.

• Test web services like HTTP/HTTPS.

• Check logs for dropped packets:

sudo journalctl -k -f  

To migrate iptables rules to nftables:

1. Know why you need to move iptables rules to nftables (iptables is old, nftables is new).

2. Use iptables-save and ip6tables-save to export the rules you have now.

3. Use iptables-translate or iptables-restore-translate to translate.

4. Use nft -f to load and save the translated ruleset.

5. Test everything extensively to make sure that services are still safe and available.

You can go from iptables to nftables without any problems while keeping your system safe and getting the benefits of a modern firewall framework by following these steps.

How do you Translate iptables Rules to nftables?

Moving to nftables isn't just a matter of switching tools; it's also a way to make your firewall easier to use, more up-to-date, and more secure for the future. Translation makes it possible to utilize current iptables rulesets in nftables with little trouble, so you don't have to start again.

1. Set the Goal of Rule Translation

The basic purpose of translation is to change iptables rules into nftables syntax so that they may be used with the nftables framework. This makes the move go more smoothly and keeps your current firewall rules.

2. Use iptables-translate for One-to-One Conversion

Linux has the iptables-translate tool that lets you change individual iptables commands into nftables equivalents.For example, suppose you have an iptables rule to allow SSH:

Original iptables rule: allow incoming SSH connections

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

Translate it using iptables-translate:

Translate iptables syntax into nftables syntax

sudo iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT  

Expected output:

nft add rule ip filter INPUT tcp dport 22 counter accept

This is the nftables rule that does the same thing. Notice how nftables automatically adds counters to help keep track of packet matching.

3. Change unsupported constructs by hand

Not all of the iptables features work perfectly. Some extensions or modules require manual adjustments in nftables.

For instance, an iptables rule that uses multiport:# Allow multiple ports in iptables

sudo iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT  

Translating this directly may not produce optimal nftables syntax. Instead, you can rewrite it manually using sets:

# nftables equivalent: using sets to group ports
nft add rule inet filter input tcp dport {22,80,443} accept

This approach is cleaner and easier to maintain.

4. Validate Translated Rules

Once translated, you should load the rules into nftables and verify they work as expected.

First, save your translated rules into a file:

Save the translated nftables rules into a file

sudo iptables-save | sudo iptables-restore-translate > /tmp/nftables.rules  

Then, load the rules into nftables:

Load translated rules into nftables

sudo nft -f /tmp/nftables.rules  

Finally, list the ruleset to confirm:

Verify that rules were successfully applied

sudo nft list ruleset  

To translate iptables rules to nftables:

1. Define the purpose: preserve your firewall logic but make it more current.

2. Use iptables-translate to change one rule at a time.

3. Use nftables sets and maps to change structures that aren't supported, such multiport.

4. Check that the ruleset is correct by exporting it, loading it, and listing it in nftables.

By following these steps, you can make sure that the migration goes well and that you get the most out of nftables' contemporary capabilities.

How do you Configure nftables on Ubuntu?

Setting up nftables on Ubuntu is easy, but you need to prepare ahead so you don't lock yourself out by mistake. Here is a step-by-step guide on how to install, set up, activate, and test nftables on an Ubuntu system.

1. Things you need to know

Before you start, make sure:

• You are using Ubuntu 20.04 LTS or a newer version (nftables is included by default).

• You can install programs and change system settings because you have sudo rights.

• If your server offers services like web hosting or SSH, it has a static IP.

• If a misconfiguration locks you out, you can still access the system through the console or out-of-band.

2. Set up nftables

Most versions of Ubuntu come with nftables, but if you don't have it, you can install it with:# Update package lists and install nftables

sudo apt update  
sudo apt install -y nftables  

After installation, confirm the version:

sudo nft --version  

3. Configuration File Location

On Ubuntu, the main nftables configuration file is located at:

/etc/nftables.conf

This file is automatically loaded at boot when the nftables service is enabled. You can edit it with your preferred text editor (e.g., nano, vim).

4. Create a Basic Ruleset

Open the config file:

sudo nano /etc/nftables.conf  

Insert the following minimal but functional ruleset:

#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Allow loopback
iif lo accept
# Allow established/related connections
ct state established,related accept
# Allow SSH
tcp dport 22 accept
# Allow HTTP/HTTPS
tcp dport {80,443} accept
# Drop everything else (default policy already drop)
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}

This configuration:

• Denies all incoming traffic by default.

• Allows SSH, HTTP, and HTTPS.

• Accepts loopback traffic and established connections.

• Drops all forwarded traffic (not a router).

5. Enable the nftables Service

Once your ruleset is ready, enable and start nftables so the rules load at boot:

sudo systemctl enable nftables  
sudo systemctl start nftables  
sudo systemctl status nftables  

6. Test Your Rules

After loading the rules, test connectivity:

# Check that SSH is open
nc -zv <your_server_ip> 22
# Test HTTP and HTTPS
nc -zv <your_server_ip> 80
nc -zv <your_server_ip> 443

You can also verify counters to see which rules are matching traffic:

sudo nft list ruleset  

Look for counter entries that increment when packets match a rule.

To configure nftables on Ubuntu:

1. Meet prerequisites (Ubuntu 20.04+, sudo access, static IP).

2. Install nftables with apt install nftables.

3. Edit /etc/nftables.conf to define your ruleset.

4. Enable and start the nftables service.

5. Test SSH, HTTP, and other services from a remote host.

By following these steps, you ensure nftables is installed, properly configured, persistent across reboots, and actively protecting your Ubuntu system.

How do you Use iptables-nft Compatibility Layer?

The iptables-nft compatibility layer allows administrators to continue using traditional iptables commands while the actual firewall rules are implemented on the nftables backend. This makes it easier to transition from iptables to nftables without immediately rewriting existing scripts or configurations.

Purpose of the Compatibility Layer

When nftables was introduced, many organizations already had years of automation, scripts, and documentation built around iptables. To avoid breaking compatibility, Linux provides iptables-nft binaries that translate iptables commands into nftables rules behind the scenes.

This means you can keep using familiar iptables commands, but the underlying firewall is managed by nftables.

Running iptables Commands on nftables Backend

You can verify which version of iptables is active (legacy or nftables) using:

sudo update-alternatives --display iptables  

If iptables-nft is selected, then all iptables commands are translated into nftables rules.

Example — adding an SSH allow rule with iptables:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

Even though this looks like an iptables command, on a system with iptables-nft enabled it actually produces an nftables rule. You can confirm with:

sudo nft list ruleset  

You will see the translated rule inside the nftables configuration.

The Compatibility Layer's Limitations

The iptables-nft layer is useful, however it has some problems:

• Not completely covered: Not all advanced iptables modules and extensions work well with nftables.

• Mixed environments: Using both iptables-legacy and nftables rules at the same time can lead to problems and misunderstanding.

• No modern features: If you solely use iptables syntax, you won't be able to use nftables' sophisticated features like sets, maps, and atomic updates.

• Complexity of debugging: The translation makes it difficult to understand errors because it hides the real nftables rules.

When to Use Direct nftables Instead

The compatibility layer is great for making migration easier, but direct nftables use is better when:

• Setting up new servers (there are no old scripts to support).

• You want less confusing syntax and fewer rules that are the same.

• You need to be able to scale with a lot of IPs or ports.

• You need atomic updates to stop partial reloads.

For example, a direct nftables rule for more than one service:

nft add rule inet filter input tcp dport {22,80,443} accept

This one rule takes the place of three iptables lines, which shows that nftables syntax is better.

The iptables-nft compatibility layer lets normal iptables commands work on a nftables backend, making the move easy and without problems. It can be useful for old scripts and slow transitions, but it can't fully take advantage of nftables' new features. The best way to utilize nftables for a long time is to switch to the native syntax.

How do you Set Up a Firewall with iptables?

Setting up a firewall with iptables involves defining clear rules for how incoming, outgoing, and forwarded traffic should be handled. The following step-by-step guide will help you configure a basic but secure iptables firewall on a Linux system.

1. Verify iptables Installation

Most distributions include iptables by default. To confirm it’s available:

sudo iptables --version  

If it’s missing, install it:

sudo apt install iptables # Ubuntu/Debian  
sudo yum install iptables # CentOS/RHEL  

2. Flush Existing Rules

Before building a new ruleset, clear any existing rules to avoid conflicts:

sudo iptables -F  
sudo iptables -X  
sudo iptables -t nat -F  
sudo iptables -t nat -X  

This resets all rules and chains in both the filter and nat tables.

3. Set Default Policies

Always start by defining the default behavior for traffic:

sudo iptables -P INPUT DROP  
sudo iptables -P FORWARD DROP  
sudo iptables -P OUTPUT ACCEPT  

• Incoming traffic is dropped by default.

• Forwarded traffic is blocked unless explicitly allowed.

• Outgoing traffic is allowed.

4. Allow Loopback Traffic

The loopback interface (lo) is needed for local applications to communicate with each other.

sudo iptables -A INPUT -i lo -j ACCEPT  

5. Allow Established and Related Connections

To avoid breaking legitimate connections, allow traffic that is part of an existing session:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT  

6. Allow Essential Services

Decide which services should be reachable. For example:

• SSH (port 22):

  sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

• HTTP/HTTPS (ports 80, 443):

  sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT  

7. Enable Logging for Dropped Packets

For auditing, log packets that are dropped:

sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROP: " --log-level 4  

This helps track suspicious activity in system logs.

8. Save and Make Rules Persistent

iptables rules reset after a reboot unless saved. Use one of the following methods:

• On Ubuntu/Debian (with iptables-persistent):

  sudo apt install iptables-persistent  
  sudo netfilter-persistent save  

• On CentOS/RHEL:

  sudo service iptables save  

9. Verify the Ruleset

List the current firewall rules with:

sudo iptables -L -v -n  

Check that:

• SSH and HTTP(S) are allowed.

• Other traffic is dropped.

• Logging rules are active.

Summary of Example Firewall Rules

Here’s a compact version of a basic secure ruleset:

sudo iptables -F  
sudo iptables -P INPUT DROP  
sudo iptables -P FORWARD DROP  
sudo iptables -P OUTPUT ACCEPT  
sudo iptables -A INPUT -i lo -j ACCEPT  
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT  
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  
sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT  
sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROP: "  

This ensures:

• Only SSH, HTTP, and HTTPS are allowed.

• All other inbound traffic is denied and logged.

• Outbound traffic is free by default.

How do you Write an nftables Rule Set?

An nftables rule set is a set of rules that tells the Linux kernel's Netfilter framework how to filter, translate, or log packets. There are tables that have chains in them, and each chain has rules in it. A rule checks the conditions of a packet (IP, port, protocol) and then takes action (accept, drop, refuse, log).

1. Structure of an nftables Rule Set

The hierarchy is:

• Table → Groups related chains (e.g., inet filter).

• Chain → Defines a hook (e.g., input, forward, output) where packets are inspected.

• Rule → Matches conditions and applies actions.

This layered structure ensures clarity and modularity.

2. Writing a Basic Rule Set

To start a clean configuration, first flush any existing ruleset:

sudo nft flush ruleset  

Now create a minimal ruleset in /etc/nftables.conf:

#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Allow loopback
iif lo accept
# Allow established connections
ct state established,related accept
# Allow SSH
tcp dport 22 accept
# Allow HTTP/HTTPS
tcp dport {80,443} accept
# Log and drop everything else
limit rate 10/second log prefix "NFT-DROP: " group 0
drop
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}

This rule set:

• Drops all inbound traffic by default.

• Allows loopback and established connections.

• Opens SSH, HTTP, and HTTPS.

• Logs and drops all other incoming packets.

• Accepts all outbound traffic.

You can load it with:

sudo nft -f /etc/nftables.conf  

And verify with:

sudo nft list ruleset  

3. Using Sets for Efficiency

Instead of repeating rules for multiple ports or IP addresses, nftables allows grouping them into sets:

table inet filter {
set allowed_ports {
type inet_service;
elements = {22, 80, 443}
}
chain input {
type filter hook input priority 0; policy drop;
tcp dport @allowed_ports accept
}
}

Here, SSH, HTTP, and HTTPS are allowed using a single rule. This reduces duplication and improves scalability.

4. Persisting the Rule Set

To ensure your rules load on reboot:

sudo systemctl enable nftables  
sudo systemctl start nftables  

nftables will automatically load the contents of /etc/nftables.conf at boot.

tip

Always test new rules with an active SSH session and keep a console open. If you accidentally drop SSH traffic, you could lock yourself out.

To write a nftables ruleset, you need to make an organized configuration file that defines tables, chains, and rules. A simple secure configuration includes:

• Setting default policies (typically DROP for input).

• Letting established traffic and loopback traffic through.

• Opening up necessary services like SSH and HTTP/HTTPS.

• Logging and getting rid of anything else.

Administrators can make firewall rulesets that are more efficient, scalable, and easier to manage with nftables than with iptables. This is possible because nftables has sets, atomic updates, and a consistent syntax.

How do you Configure firewalld in Linux?

In Linux, the firewall-cmd tool is used to set up firewalld. This lets administrators control firewall zones, add services or ports, and set sophisticated rules on the fly without having to restart the firewall service. You can set up configurations to be temporary for testing or permanent so they stay the same after a reboot.

1. Setup with firewall-cmd

The firewall-cmd command is the main interface to firewalld. First, ensure the service is running:

sudo systemctl start firewalld  
sudo systemctl enable firewalld  
sudo firewall-cmd --state  

• start → launches firewalld.

• enable → ensures firewalld starts at boot.

• --state → confirms if firewalld is active (running).

2. Selecting and Configuring Zones

Zones are predefined trust levels that determine how restrictive firewall rules are. Examples: public, home, work, internal, dmz.

List all available zones:

sudo firewall-cmd --get-zones  

Check the default active zone:

sudo firewall-cmd --get-default-zone  

Assign a network interface to a specific zone (e.g., eth0 to public):

sudo firewall-cmd --zone=public --change-interface=eth0  

3. Adding Services, Ports, or Rich Rules

Here you can find how to add services, ports and rich rules:

Add a predefined service (e.g., SSH):

sudo firewall-cmd --zone=public --add-service=ssh  

Add a port manually (e.g., HTTP port 8080):

sudo firewall-cmd --zone=public --add-port=8080/tcp  

Add a rich rule (allow SSH only from a subnet):

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'  

These commands take effect immediately but are temporary unless made permanent.

4. Making Configuration Persistent

To keep your changes after a reboot, add the --permanent flag and reload firewalld.

Example — permanently allow HTTPS:

sudo firewall-cmd --zone=public --add-service=https --permanent  
sudo firewall-cmd --reload  

• --permanent saves the rule in firewalld’s configuration.

• --reload applies all permanent rules without restarting the service.

To set up firewalld in Linux,

1. Use systemctl to start and enable the service.

2. Set up zones to fit the level of trust you have in your network.

3. Use firewall-cmd to add services, ports, or rich rules on the fly.

4. To make adjustments permanent, use the --permanent option and then the --reload option.

This method makes sure that the firewall is versatile and adaptable, so it can work in both simple and complex network environments without any downtime.

What are the Advantages of Using iptables?

iptables is the old-school tool for scripting Netfilter straight from user space. Its strengths are that it is mature, widely used, and gives you low-level control.

• Ubiquity and Familiarity: It's available on almost every Linux distribution and rescue environment, and there are lots of examples and documentation.
• Fine-Grained Control: You may make rules directly and clearly for each protocol, port, and IP address, with matches and targets that are easy to understand.
• Predictable Behavior: It's easier to understand behavior because rules are evaluated in order and default policies are set in stone.
• Mature Extensions: These are tried-and-true matches like conntrack, multiport, recent, hashlimit, and NAT primitives.
• Compatibility with Old Systems: Works with old automation (bash scripts, config snippets) with little or no adjustments.
• Few Dependencies: It has a small footprint and can run in limited, chrooted, or initramfs environments.
• Easy to fix problems—packet counters on chains, simple -L -v -n listings, and logs that are easy to read.

What are the Advantages of Using nftables?

nftables is the new firewall framework (kernel 3.13+) and nft tool that replaces iptables with a single, scalable set of rules.

• Single Ruleset Model: There is just one configuration for IPv4/IPv6 (via family inet), ARP, and bridge. There are no duplicate v4/v6 rules.
• Less Duplication: Sets and maps allow you to express several IPs and ports in one rule, which makes policies clearer and shorter.
• Performance: fast lookups (sets/hash structures), less linear scans, and atomic whole-ruleset loading.
• Maintainability: By default, files are structured (/etc/nftables.conf), the syntax is easy to comprehend, objects have names, and there are rule counters.
• Transaction Safety: You can apply or roll back the whole ruleset in one step, with no "half-applied" windows.
• Future-Proofing: The semantics are extensible, and the kernel is actively being developed. There is a compatibility layer for old iptables calls.
• Dual-Stack Simplicity: In inet, one allow rule (like tcp dport 22) immediately covers both IPv4 and IPv6.

What are the Advantages of firewalld?

firewalld is a daemon that controls Netfilter in real time (using nftables or iptables) and makes zones and services easier for people to use.

• Abstraction and Usability: Instead of low-level matches and targets, manage intent, like "allow SSH in the public zone."
• Zones by Context: You can change the trust levels for any interface or source (for example, public, home, internal, or dmz) on the fly.
• Predefined Services: Grouping ports and protocols (such SSH, HTTP, and DNS) ahead of time makes modifications faster and less likely to go wrong.
• Runtime vs. Permanent: Test the rules right away, then keep using --permanent + --reload; no connection drops.
• Dynamic Daemon: Changes take effect right away without closing existing connections.
• System Integration: Network Manager (for automatic zone switching) and systemd (for service lifecycle) operate very well together.
• Rich Rules When needed—Advanced matching (per-IP, per-service) without losing the higher-level model.
• Team-Friendly—D-Bus provides a consistent CLI and API across all distros, making it easier for teams with different levels of experience and for automation.

Which Linux Firewall Is Best for Servers?

"Best" depends on the lifespan, the abilities of the team, the needs of the performance, and the defaults of the distribution. Choose the tool that works best for your business, and then stick with it.

• New Builds on Modern Distros (RHEL 8+, Debian 10+, and Ubuntu 20.04+)

  Suggestion: nftables (native). With unified v4/v6 rules and transactional loads, this is the kernel's modern path.

• Teams with different skills and frequent changes

  Recommendation: use firewalld with nftables. Safe updates to zones and services speed up; runtime vs. permanent lowers risk.

• Old or vendor-scripted hosts

  Recommendation: Begin with iptables-nft compatibility so that current scripts will operate. Then, plan a stepwise refactor to nftables.

• High throughput and large sets of rules

  Recommendation: For performance and scalability, we recommend nftables (native sets/maps, atomic updates).

• Strict Compliance and Auditability

  Recommendation: Use nftables (clear, versionable config) or firewalld (policy intent + logs). Don't mix backends.

• Routers and NAT Gateways

  Recommendation: use nftables for clean NAT and filter separation, as well as possible performance enhancements like flow-oriented design.

• Appliance, rescue, and minimal environments

  Suggestion: iptables can still be useful because they are everywhere and take up very little space—use them as a temporary solution.

Which Linux Firewall Is Best for Beginners?

Firewalld is the finest Linux firewall for beginners since it has a simple, zone-based interface on top of the sophisticated Netfilter framework. Nftables is the most modern backend, while iptables is still recognizable to many people. However, firewalld is the easiest way for new users to protect their systems without having to learn complicated syntax.

Features that are easy for beginners to use

A firewall that is easy for beginners to use should:

• Give basic commands that don't need a lot of networking understanding.
• Give users pre-set rules and services so they don't have to remember ports.
• Make adjustments on the fly without having to restart, which lowers the danger of lockouts.
• Work well with the system's network administration tools.

Firewalld fits all of these requirements, which makes it less scary for new administrators.

The Simple Interface of firewalld

Firewalld doesn't have users write raw iptables or nftables rules. Instead, it gives them convenient instructions through firewall-cmd. For instance, it's easy to turn on SSH access:

sudo firewall-cmd --zone=public --add-service=ssh  

No need to remember that SSH uses port 22/TCP—the service definition is built in.

Ease of Rule Management with Zones

Firewalld adds zones, which show how much you trust different networks.

For example:

• home zone: trusting, more open.
• public zone: not trusted, more strict.
• dmz zone: servers that are open to the public but have limited access.

It's easy to provide a zone a network interface:

sudo firewall-cmd --zone=home --change-interface=eth0  

This lets beginners manage firewall behavior by context (“I’m at home” vs “I’m on public Wi-Fi”) instead of crafting rules manually.

Why nftables May Be Harder Initially

Nftables is the current, scalable firewall backend, although its syntax is more sophisticated and requires knowledge of tables, chains, and sets. For instance, here is how to open SSH in nftables:

nft add rule inet filter input tcp dport 22 accept

This is short and to the point, but for beginners, words like "table," "chain," and "hook" can be hard to understand.

iptables, on the other hand, is older and has a lot of documentation, but its long and repeated syntax (separate IPv4 and IPv6 rules) makes it tougher for new users to keep up with.

Firewalld is the ideal choice for novices because it has a basic interface and commands that are easy to memorize.

• Uses zones and services to make writing rules less complicated.
• Makes adjustments on the fly without having to restart connections.
• Works on top of nftables, so even new users can use the contemporary backend.

You need to know more about networking to utilize nftables and iptables appropriately. Firewalld is the best choice for beginners since it is easy to use and gives them confidence. As they get better, they can move on to nftables.

What are Common Mistakes to Avoid When Configuring iptables or nftables?

Setting up firewalls in Linux is powerful but can lead to mistakes. If rules are not applied correctly, both iptables and nftables can cause outages or security holes. The following are the most common mistakes and how to avoid them.

Forgetting Default Policies:

• Definition: If you leave default policies as ACCEPT, all traffic that doesn't match is accepted, which puts the system at risk.
• Fix: Always set strong defaults (like DROP for INPUT and FORWARD and ACCEPT for OUTPUT) and then let the services you require work.

Locking Yourself Out of SSH

• Definition: If you use a DROP policy without first permitting SSH, you could lose access to a remote server.

• Fix: Before turning on a drop policy, add SSH rules. When testing, keep a second console session open.

Mismanagement of Rule Order

• Definition: In iptables, rules are checked one after the other. In nftables, priority still matters. If the order is improper, packets could match the wrong rule.

• Fix: Put specific rules above general ones and thoroughly check the logic of the chain.

Copying IPv4 and IPv6 Rules (iptables)

• Definition: Admins often protect IPv4 with iptables but forget about ip6tables, leaving IPv6 unprotected.

• Fix: Always use the same rules for both IPv4 and IPv6, or switch to nftables' inet family to cover both in one ruleset.

Using DROP too much without logging

• Definition: Dropping traffic without letting anyone know makes it impossible to see attacks or misconfigurations.

• Solution: Before drops, use logging rules (LOG in iptables, log in nftables), and if possible, set a rate limit.

Not Saving Rules for a Long Time

• Definition: Rules that are added interactively will go away after a reboot if they are not preserved.

• Fix: Use iptables-save and iptables-persistent with iptables.

  nftables: set up /etc/nftables.conf and turn on the nftables service.

Combining old and new backends

• Definition: Using iptables-legacy and nftables at the same time makes rulesets that don't work together.

• Solution: During migration, choose one backend or utilize the iptables-nft compatibility layer, not both.

Not paying attention to established or related connections

• Definition: Legitimate replies (like web responses) are prohibited if there is no rule that allows ESTABLISHED, RELATED traffic.

• Fix: Always put a rule for tracking connections at the beginning of your INPUT chain.

Rules that are too complicated

• Definition: Making regulations that are too long or too complex makes mistakes more likely and slows things down.

• Fix: Use sets/maps in nftables or iptables' multiport/ipset to combine rules in a way that works well.

Not Testing on External Hosts

• Definition: Testing only from localhost breaks INPUT rules, which can give you a false sense of security.

• Fix: Always test modifications to the firewall from a computer that is not on the network.

How do you Test if Your Linux Firewall Rules are Working Correctly?

It's just as crucial to test firewall rules as it is to write them. You can't be sure that your policies are striking the correct mix between security and accessibility without validation. Here is a useful list of things to check to make sure your firewall is working properly.

1. Make sure you need validation

Firewalls might accidentally block important services (like SSH) or leave harmful ports open.

• Validation makes ensuring that your firewall rules are in line with your security policy.

• Always test after making changes to rules, updating the operating system, or moving (for example, from iptables to nftables).

2. Test Basic Connectivity (ping, curl, netcat)

Start with simple network utilities to confirm which ports are open and which are blocked.

# Ping a host to test ICMP
ping -c 4 <server_ip>
# Use curl to test HTTP/HTTPS access
curl -I http://<server_ip>
curl -I https://<server_ip>
# Use netcat to probe open ports (example: SSH, HTTP)
nc -zv <server_ip> 22
nc -zv <server_ip> 80

• Expected: Allowed services respond, blocked services time out or refuse connections.

3. Use Logging and Monitoring

Leverage logging rules to see how packets are being handled.

• iptables example:

  sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-TEST: "  

• nftables example:

  sudo nft add rule inet filter input log prefix "NFT-TEST: " counter  

Check logs in real time:

sudo journalctl -k -f  

• Logs will show whether packets are being accepted or dropped according to your rules.

4. Simulate in Staging Before Production

• Before putting firewall rules into production, use them in a staging or test environment first.

• To see how rules function, use the same OS and network setup.

• Use both automatic test scripts and human inspections (SSH, HTTP, DNS).

How do Performance and Resource Usage Compare Between iptables and nftables?

When it comes to managing huge rule sets, nftables is better than iptables in terms of scalability, memory efficiency, and rule evaluation speed. Both frameworks use the Netfilter kernel subsystem, but nftables makes improvements that lower the number of CPU cycles needed for each packet, use less memory for big rule collections, and check rules more quickly.

Performance Metrics to Consider

When comparing iptables and nftables, the main metrics are:

• CPU usage → How many cycles are consumed per packet inspection.

• Memory usage → How much RAM is required to store active rulesets.

• Rule evaluation time → How quickly packets are matched against the rules.

• Scalability → How performance holds up when rule counts grow into the thousands.

Comparative Benchmarks

Benchmarks illustrate that in real-world systems:

• iptables: Rules are verified one at a time for each packet. When there are hundreds or thousands of rules, it takes longer to evaluate. The amount of memory used similarly goes up in a straight line with the number of rules.

• nftables: Uses hash tables, maps, and sets to look things up. A single rule can cover a lot of IPs or ports, which cuts down on repetition by a lot. Even with big datasets, rule assessment is almost always done in constant time.

For example, if you have 1,000 IP block rules with iptables, you need 1,000 different rules and the CPU use goes up when there is a lot of traffic.

1,000 IP block rules with nftables → shown in one set object, which takes up less memory and is faster to evaluate.

Example: nftables set with multiple blocked IPs

table inet filter {
set blacklist {
type ipv4_addr;
elements = { 203.0.113.5, 198.51.100.10, 192.0.2.50 }
}
chain input {
type filter hook input priority 0; policy accept;
ip saddr @blacklist drop
}
}

Here, nftables handles multiple IPs with one compact rule, while iptables would need three separate rules.

How nftables Cuts Down on Overhead

• The unified ruleset gets rid of redundancy between IPv4 and IPv6.
• Sets/maps combine several conditions into one rule.
• Atomic updates make sure that there are no problems during the reload.
• Built-in counters make monitoring easier without adding more rules.

When compared to similar iptables rules, all of these use less CPU cycles and less RAM per packet.

Scalability for Many Rules

• iptables: Performance drops when there are more than a few hundred rules. Checking rules in order adds a lot of latency.
• nftables: Its data structures make it easy to manage thousands of entries. Big blacklists (IPs, ports) are considerably easier to work with and faster.

How does firewalld Handle Zones and Services?

Firewalld groups firewall rules into "zones" (trust levels) and "services" (predefined rule groups). Zones control how stringent the firewall is, and services connect common apps (like SSH or HTTP) to the right ports and protocols. Administrators can change the interfaces assigned to zones without having to restart the firewall.

Available Predefined Zones on firewalld

firewalld ships with several predefined zones, each representing a different level of trust:

• drop → all incoming traffic dropped, only outgoing allowed.
• block → similar to drop, but rejected with an ICMP message.
• public → untrusted networks, allow only explicitly enabled services.
• external → used for NAT or masquerading.
• dmz → for publicly accessible servers with limited access.
• work → more trusted, allow some services.
• home → trusted home environment, more permissive.
• internal → fully trusted internal networks.
• trusted → all traffic accepted.

List zones on your system:

sudo firewall-cmd --get-zones  

How Services Map to Rules

Services in firewalld are predefined collections of ports and protocols, so you don’t need to remember specific port numbers.

For example:

• ssh → TCP port 22
• http → TCP port 80
• https → TCP port 443

Allow SSH in the public zone:

sudo firewall-cmd --zone=public --add-service=ssh  

This command automatically creates the underlying nftables/iptables rules for port 22/TCP.

List all available services:

sudo firewall-cmd --get-services  

Assigning Interfaces to Zones

Interfaces are bound to zones so the firewall knows which rules to apply depending on where the system connects.

Check the default zone:

sudo firewall-cmd --get-default-zone  

Assign a specific interface (e.g., eth0) to the home zone:

sudo firewall-cmd --zone=home --change-interface=eth0  

Verify interface assignments:

sudo firewall-cmd --get-active-zones  

Dynamic Reassignment

firewalld is dynamic, meaning you can reassign interfaces or services without restarting the firewall or losing connections.

Example — moving eth0 from the public zone to the internal zone on the fly:

sudo firewall-cmd --zone=internal --change-interface=eth0  

This change is immediate and does not interrupt existing sessions.

Is nftables Faster than iptables?

Yes, nftables is faster than iptables, especially when working with big or complicated rulesets. Both use the Netfilter framework in the Linux kernel, but nftables adds optimizations and data structures at the kernel level that make it faster and more scalable.

• Performance Benchmarks of iptables checks rules one at a time, which means that every packet is compared to every rule in order. When there are hundreds or thousands of rules, the CPU utilization goes up a lot.

  • nftables uses hash tables, sets, and maps to speed up lookups, which keeps performance almost the same no matter how many rules there are.

• How well do rules work in the real world?

  • To block 1,000 IP addresses with iptables, you need 1,000 rules.
  • With nftables, one rule applies to a single collection of blocklists.
  • This cuts down on both the amount of memory used and the time it takes to evaluate packets.

  Example: nftables set blocking multiple IPs

  table inet filter {
  set blacklist {
  type ipv4_addr;
  elements = { 203.0.113.5, 198.51.100.10, 192.0.2.50 }
  }
  chain input {
  type filter hook input priority 0; policy accept;
  ip saddr @blacklist drop
  }
  }

• Improving big sets

  • nftables combines a lot of criteria (ports, IPs, networks) into small sets.
  • iptables needs separate rules for each instance, which means that rules are repeated and take longer to evaluate.

• Changes at the Kernel Level

  • nftables was made to allow atomic rule updates, which stops inconsistent states when reloading.
  • Real-time visibility with reduced overhead is possible thanks to built-in counters and monitoring.
  • Its engine is tuned for modern tasks like cloud firewalls, containers, and filtering multiple protocols.

In short, nftables is faster and more efficient than iptables because it cuts down on duplication, uses rules more wisely, and can handle thousands of rules better, all thanks to advancements made at the kernel level.

Does firewalld Replace iptables Completely?

No, firewalld does not totally take the place of iptables (or nftables). It doesn't do that; instead, it works as a management layer on top of the Linux kernel's Netfilter architecture. Firewalld takes commands that are easy for people to understand and turns them into low-level rules that iptables (for older systems) or nftables (for newer systems) really follow.

• What firewalld does as a management layer:

  • firewalld is a daemon that makes managing firewalls easier.
  • Administrators use zones (trust levels) and services (common protocols) to talk to it.
  • It doesn't filter packets on its own; it sets up the backend engine (iptables or nftables).

• Relying on iptables or nftables

  • Firewalld uses iptables to manage rules on older Linux versions like CentOS 7 and Ubuntu 18.04.
  • Firewalld uses nftables as its backbone on newer distributions, including RHEL 8+, Fedora 32+, and Ubuntu 20.04+.
  • The user experience (firewall-cmd) doesn't change, no matter which backend is running.

  Check firewalld status

  sudo firewall-cmd --state  

  Check backend in logs

  sudo journalctl -u firewalld | grep "Using backend"  

• Transition from iptables to nftables

  • Linux kernel development has shifted from iptables to nftables since kernel 3.13.
  • Most distros have already adopted nftables as default, but firewalld keeps compatibility by hiding this transition from the user.

• Continued Relevance of Both

  • iptables is still relevant in legacy systems and older automation scripts.
  • nftables is the present and future, offering better performance and scalability.
  • firewalld bridges the gap, ensuring administrators don’t need to learn both low-level syntaxes immediately.

In short, firewalld doesn't replace iptables or nftables; it controls them. It uses iptables on older systems and nftables on newer ones. Both are still useful, but firewalld makes management easier by giving you a consistent, high-level interface.

Is firewalld Easier to Use than nftables?

Yes, firewalld is easier to use than nftables, because it abstracts low-level firewall rules into a simpler model based on zones and services. While nftables offers more flexibility and power, its syntax requires a deeper understanding of tables, chains, and hooks.

• Ease of Use Criteria

  • firewalld: Focuses on abstraction → administrators think in terms of “zones” (trust levels) and “services” (predefined protocols/ports).
  • nftables: Requires writing explicit rulesets → administrators must understand packet flow, families (ip, ip6, inet), and manual rule construction.

• firewalld’s Zone and Service Model

  Example — Allow SSH in the public zone:

  sudo firewall-cmd --zone=public --add-service=ssh  

  This single command enables SSH by referencing its predefined service (port 22/TCP). No need to recall exact ports or write complex conditions.

  Assign an interface to a zone:

  sudo firewall-cmd --zone=home --change-interface=eth0  

  Zones like home, public, or dmz represent trust levels, making configuration context-driven instead of rule-driven.

• Complexity of nftables Scripts

  The same SSH rule in nftables requires explicit syntax:

  nft add rule inet filter input tcp dport 22 accept

Making tables, chains, and policies by hand is part of a whole ruleset. This is strong, but you need to know more about networking and pay close attention to details.

• Use Cases for Each Approach o firewalld: Best for those who are new to computers or system administrators who need to make quick, safe modifications.

• Best for places with different levels of trust (zones).

• Useful when it's vital for all distros to be the same. nftables: Best for advanced admins that want to have a lot of control.

• Best for rulesets that are big and can grow (using sets/maps). This is a good choice if automation and version-controlled configuration are important.

The zone/service concept and simpler instructions make firewalld easier to use than nftables. nftables is more complicated, but it gives you more options and can handle bigger or more advanced deployments.

Do you Still Need iptables if You Have nftables?

No, you don't need iptables if you have nftables. Nftables is meant to replace iptables and has all the basic packet filtering, NAT, and logging functions. However, iptables may still be useful in places where old scripts, automation, or third-party software depend on it.

• nftables as the Replacement

  • Introduced in Linux kernel 3.13, nftables unifies IPv4, IPv6, ARP, and bridging under one ruleset.
  • It is now the default firewall framework in most modern Linux distributions.
  • iptables is in maintenance mode and will not receive major new features.

• Legacy Scripts and Compatibility

  • Many older automation scripts and tools were written for iptables syntax.
  • To avoid breaking them, Linux provides the iptables-nft compatibility layer, which translates iptables commands into nftables rules.
  • This allows administrators to keep using existing scripts while the system actually enforces nftables.

  Example: iptables command running on nftables backend

  sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

  Check translation in nftables

  sudo nft list ruleset  

• Coexistence via Compatibility Layers

  • On newer systems, executing iptables probably calls iptables-nft, which is the compatibility binary.
  • Don't mix iptables-legacy and native nftables directly because they have different rules that don't always work together.

• The Long-Term Goal is Migration

  • The goal is to move all firewalls to nftables in the long run.
  • Administrators should slowly switch out iptables rules for nftables rules. They can use translation tools like iptables-translate or iptables-restore-translate to do this.
  • This makes sure that the syntax is up to date, that it can grow, and that it will work in the future.

In short, you don't need iptables if you already have nftables. Older scripts may still use it, although newer Linux systems use nftables as the backend, frequently with compatibility layers. The best thing to do is to make a plan on how to move to nftables so that you don't have to utilize iptables syntax.

Firewalls are not optional extras in the Linux environment; they are essential security tools that keep systems safe from unauthorized access and attacks. Administrators have switched from the old iptables framework to the new nftables framework over time. Tools like firewalld have also come out to make management easier by using zones and services. Each option has its pros and cons: iptables has been around for a long time and works with a lot of different systems; nftables is fast and easy to scale; and firewalld is easy to use and makes routine firewall jobs easier.

Your environment and level of knowledge will help you choose the proper firewall tool. Firewalld is the easiest way for beginners and teams with people of different skill levels to get started. nftables is the best choice for advanced administrators and large-scale installations because it is contemporary and performs well. Iptables is still important for older systems, but the long-term plan should be to slowly switch to nftables. The most important thing in any scenario is to be consistent: set explicit security principles, test the rules to make sure they function, and keep your layered defense up to current as your network's demands change.