nftables Best Practices

Unlike iptables, nftables supports modern abstractions and cleaner syntax, making firewall rules more scalable, readable, and maintainable. This guide outlines recommended practices when building rulesets.

Organisation & Structure

Use Tables and Chains Consistently

Keep separate tables for inet (IPv4+IPv6 combined), ip, and ip6 only when necessary.

Basic Table Structure

table inet filter {
    chain input {
        type filter hook input priority 0;
    }
}

Combine IPv4 + IPv6 rules: Prefer inet family tables instead of duplicating rules for ip and ip6.

Groups & Sets

Sets replace the legacy ipset from iptables, providing easier management of IP groups and service ports without rule duplication.

IP Address Sets

Use sets to manage groups of hosts or networks:

set blacklist {
    type ipv4_addr;
    elements = { 
        192.168.10.5, 
        192.168.20.0/24 
    }
}

chain input {
    type filter hook input priority 0;
    ip saddr @blacklist drop
}

Port and Service Sets

Simplify multi-service allow/deny rules:

set web_ports {
    type inet_service;
    elements = { 80, 443 }
}

chain input {
    tcp dport @web_ports accept
}

Sets use maps and intervals internally, making them significantly faster than multiple individual rules at scale.

Reusability & Abstraction

Name Chains by Purpose

Use descriptive names like input, forward, output, log_drop

Split Rules Logically

Separate base policy, user-defined services, and logging rules

Example: Logging Chain

chain log_drop {
    log prefix "NFT DROP: " flags all
    drop
}

Security-Oriented Defaults

Always implement a default deny policy. End chains with drop or reject unless traffic is explicitly allowed.

Security Best Practices

Default Deny

Always end chains with drop/reject unless explicitly allowed

Log Before Dropping

Log sensitive traffic to detect probing and intrusion attempts

Restrict Administrative Ports

Limit SSH, RDP, and VPN access to trusted IP sets

Implement Rate Limits

Use rate limiting on logging and SSH attempts

Rate Limiting Example

limit rate 5/minute accept

Performance & Maintainability

Prefer Sets

Sets are faster than many individual rules (nftables uses maps/intervals internally)

Version Control

Keep ruleset in /etc/sysconfig/nftables.conf under version control (Git)

Add Comments

Use comments generously in rules for future administrators

Single File Configuration

Maintain configuration in one file for easier management

Testing & Validation

Always keep a console session open when applying new firewall rules to prevent lockout.

Testing Workflow

# Test new rules
nft -f new_rules.conf

# Verify current ruleset
nft list ruleset

Stage complex changes on non-production systems first before deploying to production.

Complete Example: IT Host Access Control

This example demonstrates multi-line sets and proper rule organization for IT administrative access:

table inet filter {
    # IT hosts allowed to access sensitive services
    set it_hosts {
        type ipv4_addr;
        elements = {
            172.16.80.10,  # IT-010
            172.16.80.11,  # IT-011
            172.16.80.12   # IT-012
        }
    }

    # Common IT service ports
    set it_ports {
        type inet_service;
        elements = {
            22,      # SSH
            3389,    # RDP
            80,      # HTTP
            443      # HTTPS
        }
    }

    chain input {
        type filter hook input priority 0;

        # allow loopback
        iif lo accept

        # allow established/related connections
        ct state established,related accept

        # allow IT hosts on specific ports
        ip saddr @it_hosts tcp dport @it_ports accept

        # drop everything else with logging
        jump log_drop
    }

    chain log_drop {
        log prefix "NFT DROP: " flags all
        drop
    }
}

Key Features of This Configuration

IP Sets: Centralized management of IT hosts
Port Sets: Easy service definition
Stateful Inspection: Allows established connections
Logging: All dropped packets are logged with prefix
Comments: Inline documentation for each IP
Default Deny: Explicit drop at the end

Quick Reference

Feature	iptables	nftables
IP Sets	Separate `ipset` tool	Native sets
IPv4+IPv6	Duplicate rules	`inet` family
Syntax	Complex	Clean, readable
Performance	Good	Better with sets
Maintainability	Moderate	Excellent

For new deployments, always choose nftables over legacy iptables for better maintainability and performance.

Get Started

Guides

Best Practices

Organisation & Structure

Use Tables and Chains Consistently

Basic Table Structure

Groups & Sets

IP Address Sets

Port and Service Sets

Reusability & Abstraction

Name Chains by Purpose

Split Rules Logically

Example: Logging Chain

Security-Oriented Defaults

Security Best Practices

Rate Limiting Example

Performance & Maintainability

Prefer Sets

Version Control

Add Comments

Single File Configuration

Testing & Validation

Testing Workflow

Complete Example: IT Host Access Control

Quick Reference

Build docs developers (and LLMs) love

Get Started

Guides

Best Practices

​Organisation & Structure

Use Tables and Chains Consistently

​Basic Table Structure

​Groups & Sets

​IP Address Sets

​Port and Service Sets

​Reusability & Abstraction

Name Chains by Purpose

Split Rules Logically

​Example: Logging Chain

​Security-Oriented Defaults

​Security Best Practices

​Rate Limiting Example

​Performance & Maintainability

Prefer Sets

Version Control

Add Comments

Single File Configuration

​Testing & Validation

​Testing Workflow

​Complete Example: IT Host Access Control

​Quick Reference

Build docs developers (and LLMs) love

Organisation & Structure

Basic Table Structure

Groups & Sets

IP Address Sets

Port and Service Sets

Reusability & Abstraction

Example: Logging Chain

Security-Oriented Defaults

Security Best Practices

Rate Limiting Example

Performance & Maintainability

Testing & Validation

Testing Workflow

Complete Example: IT Host Access Control

Quick Reference