Mastering iptables and nftables: Modern Linux Firewalling

Introduction

Linux firewalling has long been a cornerstone of system hardening and network security. For over two decades, iptables was the de facto standard for configuring packet filtering, NAT, and traffic inspection across Linux distributions. However, with the advent of nftables - intended as a successor to iptables - many system administrators and network engineers are re-evaluating their approach to firewall configuration and rule management.

This post provides a deep dive into both iptables and nftables, how packet traversal works through chains and tables, how to write performant and secure rules, and how to migrate existing infrastructures to nftables. Whether you’re securing a lightweight personal server or administering a high-throughput production firewall, understanding the strengths, trade-offs, and best practices of each system is essential in modern Linux environments.

The Evolution from iptables to nftables

iptables has served as the Linux firewall framework since the early 2000s, replacing the older ipchains and ipfwadm. It relies on the netfilter subsystem, providing four main tables (filter, nat, mangle, and raw) and userspace tools for rule management.

Over time, several issues with iptables emerged:

• Complex syntax and redundancy across protocols (IPv4 via iptables, IPv6 via ip6tables)
• Performance bottlenecks with large rule sets
• Lack of native atomic rule replacement
• No built-in high-level abstraction for coherent rule grouping or inheritance

In response, the nftables framework was introduced by the Netfilter project in 2014 and integrated into the mainline Linux kernel (since 3.13). It aims to provide:

• A unified firewall front-end for both IPv4 and IPv6
• A simplified, consistent rule syntax
• Performance enhancements via rule set optimizations and atomic transactions
• Native support for dynamic sets, maps, intervals, and other advanced constructs

nftables ultimately leverages a new in-kernel virtual machine (netfilter expression language) which interprets rules more efficiently than traditional linear evaluation in iptables.

Understanding Packet Flow Through Tables and Chains

To master either firewalling framework, one must understand the lifecycle of a packet and how it traverses tables and chains.

iptables Packet Flow

A packet traverses predefined netfilter hooks in a rigid pipeline tied to kernel packet-handling stages:

1. PREROUTING: Used for DNAT and early packet manipulation before routing decisions (NAT, raw).
2. INPUT: For packets destined to the local system (filter, mangle).
3. FORWARD: Used when routing between interfaces (filter, mangle).
4. OUTPUT: For packets generated locally (filter, mangle, nat).
5. POSTROUTING: Used for SNAT and egress modification (nat, mangle).

# Example: iptables rule to drop all traffic from a specific IP
iptables -A INPUT -s 203.0.113.50 -j DROP

nftables Packet Flow

nftables abstracts chain traversal into custom-configured hooks tied to table/chain types:

• Chains are explicitly created and bound to netfilter hooks (input, output, forward, etc.).
• Tables define the address family (ipv4, ipv6, inet for both, arp, bridge).

# Example: nftables rule to drop traffic from a specific IP
nft add rule inet filter input ip saddr 203.0.113.50 drop

# Using sets for better clarity and scalability:
define blacklist = { 203.0.113.50, 198.51.100.23 }

table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
    ip saddr @blacklist drop
  }
}

This allows building expressive rule sets that eliminate redundancy and improve performance across packets.

Writing Secure and Performant Firewall Rules

Strong firewall policies are both concise and deliberate, ensuring attack surfaces are minimized and resources conserved.

Key Strategies

• Default Deny Policy: Always start with a blanket DROP policy, then allow explicitly.
• Limit Exposure: Open only required ports/services (e.g., SSH, HTTPS).
• Short-Circuit Logic: Place frequent or critical rules early to minimize traversal.
• Track Connection State: Use connection tracking to only inspect new packets.

iptables Rule Example

# Clear defaults
iptables -F
iptables -X

# Policy: deny unless allowed
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Loopback
iptables -A INPUT -i lo -j ACCEPT

# Accept SSH only from specific IP
iptables -A INPUT -p tcp -s 198.51.100.10 --dport 22 -j ACCEPT

# Accept established/related traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

nftables Rule Example

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    iif "lo" accept
    ct state established,related accept
    ip saddr 198.51.100.10 tcp dport 22 accept
  }
}

The nftables version is not only more readable but scales better when expanded with sets/maps.

Migrating from iptables to nftables

While iptables remains widely used, most modern distros (like Debian 10+, Fedora, Arch) ship with nftables support enabled by default and offer translation layers (iptables-nft) for compatibility.

Step 1: Identify Your Backend

update-alternatives --display iptables

Ensure your system uses iptables-nft or explicitly install nftables.

Step 2: Export iptables Rule Set

iptables-save > rules.v4

Use iptables-translate for one-off rule conversions:

iptables-translate -A INPUT -s 10.0.0.1 -j DROP
# Output:
nft add rule ip filter INPUT ip saddr 10.0.0.1 drop

Step 3: Redesign With Sets/Concise Syntax

While you can translate rules, the best migration approach is rethinking structure using native benefits:

define trusted_ssh = { 192.168.1.0/24, 10.0.0.10 }
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    iif "lo" accept
    ct state established,related accept
    ip saddr @trusted_ssh tcp dport 22 accept
  }
}

Performance Comparison: iptables vs nftables

When benchmarked under identical conditions:

Most modern systems under DDoS or high-load conditions benefit significantly from nftables due to efficient rule matching via hash tables and maps.

Advanced Tips and Pro Strategies

Common Mistakes

• Leaving default policy as ACCEPT: Always set DROP or reject.
• Duplicated rules for v4/v6: Use inet in nftables.
• Neglecting established connections: Prevents return traffic from being allowed.
• Simultaneous use of both systems: Can conflict and produce undefined behavior.

Troubleshooting: Common Issues & Solutions

Best Practices Checklist

• Always use a default drop policy
• Prefer nftables for new deployments
• Define rules in version-controlled configuration files
• Use nft -f ruleset.nft with dry-run tests
• Keep rules simple, reusable, and auditable

Resources & Next Steps

• nftables wiki
• man nft
• iptables-nft compatibility
• Firewalld - Service-level abstraction over nft/iptables
• Projects for automation:
  • ufw (Uncomplicated Firewall)
  • ferm
  • nftfw

Conclusion

Mastering iptables and nftables equips Linux users with the power to secure their systems effectively. While iptables has deep historical roots, nftables brings a fresh, performance-oriented design that’s easier to manage at scale. The shift requires a mindset of abstraction, atomic changes, and rule consolidation using modern structures like sets and maps.

Key takeaways:

• nftables is the modern replacement for iptables, offering better performance and syntax
• Understanding packet flow and netfilter hooks is foundational
• Migrate old rules thoughtfully using sets and simplified logic
• Prefer unified inet tables for dual-stack configurations (IPv4/IPv6)
• Maintain firewall rule sets under version control and test before deployment

Keep learning!