If you’ve been managing Linux servers for a while, you’ve likely cross paths with iptables. For years, it was the undisputed king of Linux packet filtering. But times change, and so does the Linux kernel.

Enter nftables, the modern successor designed to replace iptables, ip6tables, arptables, and ebtables with a single, unified framework. It brings better performance, a much cleaner syntax, and a more efficient way to handle rules.

Let’s break down how nftables works and how to configure a robust, production-ready firewall.

Why Make the Switch?

Before diving into the syntax, it helps to understand why nftables is a massive upgrade over its predecessor:

• Unified Syntax: No more switching between iptables and ip6tables. A single rule can handle both IPv4 and IPv6.
• Less Kernel Overhead: Instead of compiling specific code for every single match case, nftables uses a lightweight virtual machine inside the kernel that executes bytecode. It’s faster and leaner.
• Atomic Updates: You can apply an entire configuration file at once. If there’s a syntax error, the whole thing fails, preventing you from accidentally locking yourself out with a half-applied rule set.
• Native Sets: You can group IP addresses, ports, or interfaces into sets natively, allowing a single rule to match multiple elements efficiently.

Core Concepts: Tables, Chains, and Rules

Unlike iptables, which comes with predefined tables (like filter, nat, and mangle), nftables starts as a blank slate. You define exactly what you need.

1. Tables

Tables are the highest-level containers. They hold your chains. You must specify an address family for each table, such as:

ip (IPv4)

ip6 (IPv6)

inet (Both IPv4 and IPv6 — highly recommended)

2. Chains

Chains live inside tables and actually see the packets. There are two types:

• Regular Chains: Used to organize your rules (similar to a custom subroutine).
• Base Chains: The entry points into the netfilter framework. They require a type, hook, and priority so the kernel knows exactly when to trigger them (e.g., when a packet enters the network card).

3. Rules

Rules are the individual instructions inside chains that inspect packets and take action (e.g., accept, drop, reject).

Step-by-Step: Building a Basic Firewall

Let’s configure a standard stateful firewall for a server. This setup will block all incoming traffic by default, except for SSH, HTTP, HTTPS, and ping, while allowing all outbound traffic.

Step 1: Clean the Slate

First, let’s flush any existing nftables configurations to make sure we’re starting fresh.

sudo nft flush ruleset

Step 2: Create the Table

sudo nft add table inet my_firewall

Step 3: Create the Base Chains

Now, we create the input, forward, and output chains. Notice how we define their hooks and set the default policies.

# Drop all incoming traffic by default

sudo nft add chain inet my_firewall input { type filter hook input priority 0 \; policy drop \; }

# Drop all forwarded traffic (good for non-routers)

sudo nft add chain inet my_firewall forward { type filter hook forward priority 0 \; policy drop \; }

# Allow all outbound traffic by default

sudo nft add chain inet my_firewall output { type filter hook output priority 0 \; policy accept \; }

Note: The backslashes (\;) are required in terminal commands to prevent your shell from misinterpreting the semicolons.

Step 4: Add the Rules

Now, let’s populate our input chain with rules to keep the server functional but secure.

1. Allow Loopback Traffic:
Essential for local services communicating with each other.

sudo nft add rule inet my_firewall input iifname "lo" accept

2. Allow Established and Related Connections:
This makes the firewall “stateful.” It ensures that if your server initiates a connection (like a system update), the returning traffic is allowed back in.

sudo nft add rule inet my_firewall input ct state established,related accept

3. Allow Essential Services (SSH, HTTP, HTTPS):
Instead of writing three separate rules, we can use an nftables set (enclosed in curly braces) to handle them in one go.

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

4. Allow Ping (ICMP & ICMPv6):
Crucial for network diagnostics.

sudo nft add rule inet my_firewall input icmp type echo-request accept
sudo nft add rule inet my_firewall input icmpv6 type echo-request accept

Reviewing and Saving Your Work

To see the ruleset you just built in its clean, human-readable format, run:

sudo nft list ruleset

Your output will look remarkably clean compared to old iptables listings:

table inet my_firewall {
	chain input {
		type filter hook input priority filter; policy drop;
		iifname "lo" accept
		ct state established,related accept
		tcp dport { 22, 80, 443 } accept
		icmp type echo-request accept
		icmpv6 type echo-request accept
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
	}

	chain output {
		type filter hook output priority filter; policy accept;
	}
}

Making it Permanent

Runtime changes will vanish if the server reboots. To make them permanent, save them to your system’s nftables configuration file (usually located at /etc/nftables.conf).

On Debian/Ubuntu systems:

sudo sh -c "nft list ruleset > /etc/nftables.conf"
sudo systemctl enable nftables
sudo systemctl start nftables

On RHEL/Rocky Linux systems:

sudo sh -c "nft list ruleset > /etc/sysconfig/nftables.conf"
sudo systemctl enable nftables

Pro-Tip: Atomic Reloads

If you ever need to update your firewall in the future, don’t run commands line-by-line. Instead, edit your /etc/nftables.conf file directly, and then reload it atomically:

sudo nft -f /etc/nftables.conf

If there is a typo on, for example, line 15, nftables will reject the entire file, and your active firewall will remain completely untouched—saving you from a stressful trip to the recovery console.