nftables Getting Started: Replace iptables Today (2026)

nftables is a packet filtering framework that replaces the older iptables, ip6tables, arptables, and ebtables.

import socket

def get_public_ip():
    try:
        # Connect to a public DNS server to get a connection to the internet
        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        s.connect(("8.8.8.8", 80))
        ip_address = s.getsockname()[0]
        s.close()
        return ip_address
    except Exception as e:
        return f"Error: {e}"

print(f"Your public IP address is: {get_public_ip()}")

The core problem nftables solves is the fragmentation and complexity of the older Linux firewalling tools. Instead of separate tools for IPv4, IPv6, ARP, and bridges, nftables provides a single, unified syntax and a more efficient kernel-data path. It uses a domain-specific language (DSL) to define rules, which are then compiled into bytecode executed by the Netfilter subsystem in the Linux kernel. This means rules are evaluated much faster, and the overall management of firewall policies becomes more streamlined.

Here’s a look at how nftables handles a common scenario: allowing SSH traffic from a specific IP address.

Current State (Conceptual):

Imagine a server that needs to accept SSH connections (port 22) only from your home IP address, say 192.168.1.100.

nftables Configuration:

The nftables configuration is typically stored in /etc/nftables.conf. A minimal configuration to achieve this might look like:

table ip filter {
    chain input {
        type filter hook input priority 0; policy accept;

        # Allow established and related connections
        ct state established,related accept

        # Allow loopback traffic
        iifname "lo" accept

        # Allow SSH from a specific IP
        ip saddr 192.168.1.100 tcp dport 22 accept

        # Drop all other incoming traffic
        drop
    }
}

Explanation:

• table ip filter { ... }: This defines a table named filter for IPv4 packets. Tables are containers for chains.
• chain input { ... }: This defines a chain named input. Chains are lists of rules that packets traverse. type filter hook input priority 0; specifies that this chain is for filtering packets arriving at the server, to be processed at the input hook point with a priority of 0. policy accept; sets the default action for packets that don’t match any rule to accept.
• ct state established,related accept: This is a crucial rule. It uses the connection tracking module (ct) to allow packets that are part of an already established connection or are related to one (like FTP data connections). This prevents you from breaking existing connections when you implement a restrictive policy.
• iifname "lo" accept: This allows all traffic on the loopback interface (lo), which is essential for local services to communicate.
• ip saddr 192.168.1.100 tcp dport 22 accept: This is the core rule for SSH. It matches packets where the source IP address (ip saddr) is 192.168.1.100, the protocol is TCP (tcp), and the destination port (dport) is 22. If all these conditions are met, the packet is accepted.
• drop: This is the final rule in the chain. Since the policy is accept, this drop rule will only be hit if none of the preceding accept rules matched. This effectively drops all other incoming traffic not explicitly allowed.

Applying the Configuration:

After saving the configuration to /etc/nftables.conf, you would typically apply it with:

sudo nft -f /etc/nftables.conf

To make it persistent across reboots, you’d enable the nftables service:

sudo systemctl enable nftables
sudo systemctl start nftables

The most surprising true thing about nftables is that it doesn’t just offer a new syntax; it fundamentally changes how rules are processed in the kernel. Instead of traversing linked lists of rules in user space for each packet (as iptables did in some scenarios), nftables compiles its ruleset into a highly optimized bytecode that the kernel’s Netfilter module executes directly. This jump in efficiency means that even complex rulesets can be processed with significantly lower CPU overhead.

The next concept you’ll likely encounter is the rich language features for matching, such as using regular expressions for matching strings within packet payloads or defining complex sets of source/destination IP addresses for more granular control.