Netfilter, iptables & nftables

Table of Contents#

1. Why This Part Exists
2. Netfilter — the Kernel Framework Underneath Everything in This Chapter
3. The Five Netfilter Hooks
4. iptables — Tables, Chains, and Rules
5. The filter Table — Packet Filtering Basics
6. A Minimal iptables Ruleset, Built Up Step by Step
7. The nat Table — SNAT, DNAT, and MASQUERADE
8. Connection Tracking (conntrack) — the State Behind Stateful Filtering
9. Why iptables Rule Order Matters — the First-Match-Wins Model
10. nftables — What Actually Changed
11. nftables Syntax — Tables, Chains, and Rules Revisited
12. Sets and Maps — nftables' Native Answer to ipset
13. A Minimal nftables Ruleset, Built Up Step by Step
14. Migrating From iptables to nftables — iptables-translate and the Compatibility Layer
15. Why Every Major Distro Has Already Switched
16. Policy-Based Routing — Beyond the Single Default Route
17. Routing Tables and ip rule
18. A Worked Example: Multi-Homed Routing With ip rule
19. Looking Ahead — eBPF and XDP as an Emerging Alternative
20. How This Connects to Kubernetes — kube-proxy's iptables and IPVS Modes
21. How This Connects to CNI Plugins
22. Rate Limiting at the Firewall Layer
23. Logging and Auditing Firewall Activity
24. Debugging a Firewall Rule — a Practical Workflow
25. Higher-Level Firewall Managers — firewalld and ufw
26. Egress Filtering and a Zero-Trust Posture
27. A Full Realistic Example: A Production Web Server Firewall
28. IPv6 Filtering — What Genuinely Differs
29. mangle and raw Tables — a Brief, Honest Mention
30. Key Terms Glossary — This Chapter's Vocabulary in One Place
31. Testing Firewall Changes Safely — the Remote-Lockout Problem
32. A Comparison Table: iptables vs. nftables vs. XDP/eBPF
33. Managing Firewall Rules as Code
34. Monitoring Firewall and Connection-Tracking Health
35. Container-Specific Netfilter Considerations
36. How This Relates to Cloud Security Groups and NACLs
37. A Firewall Change Checklist
38. Common Mistakes
39. Worked Practice Problems
40. Summary and What's Next

Why This Part Exists#

This chapter is worth approaching with a specific mindset: nearly every mechanism covered here is something you have almost certainly already relied on indirectly — a home router's port forwarding, a cloud security group, a Kubernetes NetworkPolicy — without necessarily having seen the actual kernel machinery underneath. The goal of this chapter is closing that gap precisely, not introducing an unfamiliar new topic from scratch.

Reading order matters here more than in most chapters of this course: the sections build strictly on each other, from the underlying hook framework, through filtering and NAT, into the modern nftables replacement, and finally into routing — later sections assume the terminology and mental model established earlier ones, so working through this chapter start to finish rather than jumping to a specific section is the recommended approach on a first read.

Part 2 of this series covered TCP/IP conceptually — packets, ports, the three-way handshake — treating the kernel's own packet-handling machinery as a black box that "just works." This Part opens that box specifically: every firewall rule, every NAT translation, every Service a Kubernetes cluster routes traffic through ultimately compiles down to the exact mechanism covered in this chapter. A platform engineer who understands netfilter/iptables/nftables directly is equipped to actually debug a real "why can't this pod reach that service" incident at the packet level, rather than treating the network layer as unexplainable magic.

This chapter also directly grounds material this course's Kubernetes Deep Dive series has referenced without fully explaining — kube-proxy's iptables mode, NetworkPolicy enforcement, and the packet path a CNI plugin actually manipulates. Understanding netfilter here means those references stop being "trust the abstraction" and become "trace the actual packet."

Netfilter — the Kernel Framework Underneath Everything in This Chapter#

Netfilter is the actual in-kernel framework that every tool in this chapter — iptables, nftables, and even a CNI plugin's own packet manipulation — is a frontend for. Worth stating this precisely up front: netfilter itself is not a command a user runs; it's a set of hook points built into the Linux networking stack that other tools attach rules to.

This "one underlying framework, multiple frontends" relationship is worth internalizing before anything else in this chapter, since it resolves a common point of confusion: iptables and nftables are not two competing kernel subsystems — they are two different userspace tools that both, ultimately, program the same netfilter hooks. As of 2026, every major distribution (Ubuntu 22.04+, Debian 11+, RHEL 9+, Fedora 35+) ships nftables as the default packet-filtering framework, with an iptables-compatible command translation layer provided for backward compatibility — worth knowing this chapter covers both specifically because a huge amount of production infrastructure, scripts, and institutional knowledge still assumes the older iptables command syntax, even on systems where nftables is the actual underlying engine.

The Five Netfilter Hooks#

Netfilter exposes five distinct points in the kernel's packet-processing path where a rule can intercept, inspect, and act on a packet — worth naming precisely, since every table and chain covered later in this chapter attaches to one or more of these hooks.

The PREROUTING-before-routing-decision and POSTROUTING-after-routing-decision placement is the single most important detail in this diagram, since it directly explains why DNAT rules (covered later in this chapter) belong specifically in PREROUTING and SNAT/MASQUERADE rules belong specifically in POSTROUTING: a DNAT rule needs to rewrite a packet's destination before the kernel decides how to route it (since changing the destination can change the routing decision itself), while an SNAT rule needs to rewrite a packet's source after routing has already determined which interface it's leaving through (since the correct source IP to rewrite to often depends on which interface is actually being used).

iptables — Tables, Chains, and Rules#

iptables organizes rules into a three-level hierarchy: tables (grouped by purpose — filtering, NAT, mangling), each containing chains (which correspond to the netfilter hooks from the previous section), each containing an ordered list of rules.

The filter table (packet accept/drop decisions) and the nat table (address translation) are the two tables this chapter focuses on, since they cover the large majority of real production firewall and NAT use cases — the mangle table (packet header modification for QoS/marking) and raw table (connection-tracking exemptions) exist but are genuinely more specialized and less commonly hand-authored directly.

The filter Table — Packet Filtering Basics#

Every rule in the filter table ends in a target — the action taken when a packet matches that rule's conditions.

The DROP-vs-REJECT distinction is worth understanding precisely, since it's a genuine, deliberate security tradeoff rather than a stylistic choice: DROP gives an attacker doing port scanning no information at all — the connection simply times out, indistinguishable from "nothing is listening" versus "something is listening but blocked," a real defense against reconnaissance. REJECT is more polite (a legitimate client gets an immediate, clear failure instead of waiting for a timeout) but does leak the information "something is here, and it's actively blocking you." Production firewalls facing the public internet commonly default to DROP; internal, trusted-network firewalls more commonly use REJECT for faster, clearer failure feedback to legitimate internal traffic.

A Minimal iptables Ruleset, Built Up Step by Step#

# 1. Default policy: DROP everything not explicitly allowed
iptables -P INPUT DROP

# 2. Allow already-established connections back in (see conntrack, next section)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. Allow loopback traffic (a process talking to itself via 127.0.0.1)
iptables -A INPUT -i lo -j ACCEPT

# 4. Allow inbound SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# 5. Allow inbound HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Reading this ruleset in order is the correct way to understand it, since iptables evaluates rules top to bottom and stops at the first match — a detail this chapter returns to explicitly in its own dedicated section below. Rule 1 sets a default-deny posture (the correct default for any production host); rule 2 is what actually makes a stateful firewall possible — without it, a server's own outbound responses to a client's inbound connection would themselves be blocked by the default-deny policy, since a response packet's direction is technically inbound even though it's part of a connection the server itself is legitimately part of.

The nat Table — SNAT, DNAT, and MASQUERADE#

The nat table rewrites packet source or destination addresses — the actual mechanism underneath every "port forwarding" or "outbound internet access for a private network" setup.

# DNAT: forward external traffic on port 8080 to an internal server
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.5:80

# MASQUERADE: let an entire private subnet share one public IP for outbound traffic
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

MASQUERADE deserves specific explanation as a variant of SNAT, not a wholly separate mechanism: plain SNAT requires specifying a fixed source IP to rewrite to (--to-source 203.0.113.5), which breaks if that IP ever changes (a dynamic IP from a cloud provider or ISP, for instance). MASQUERADE instead automatically uses whatever IP is currently assigned to the outbound interface — the correct choice for any interface with a dynamically-assigned address, and the exact mechanism a home router or a Kubernetes node uses to let an entire private network share one public-facing IP.

Connection Tracking (conntrack) — the State Behind Stateful Filtering#

The ESTABLISHED,RELATED state match used in this chapter's own minimal ruleset example depends entirely on conntrack, netfilter's connection-tracking subsystem — worth understanding as the actual mechanism that makes a "stateful firewall" meaningfully different from a naive "check every packet independently" one.

This is worth stating as the single mechanism that makes the minimal ruleset from earlier in this chapter actually usable in practice: without conntrack, a firewall would need an explicit rule allowing every possible response packet for every possible outbound connection a host might ever initiate — an intractable, constantly-changing rule set. Instead, one single ESTABLISHED,RELATED rule covers all of it, because conntrack maintains the actual connection-state table the kernel consults. conntrack -L (from the conntrack-tools package) lists the live connection-tracking table directly — genuinely useful for debugging a "why is this legitimate response being dropped" issue, since it shows exactly what the kernel currently considers an active, tracked connection.

Why iptables Rule Order Matters — the First-Match-Wins Model#

Worth a dedicated section on the single most common iptables mistake this chapter's own Common Mistakes table returns to: iptables evaluates rules within a chain strictly top to bottom, and stops at the first rule that matches — subsequent rules, even more specific ones, never get a chance to apply.

A specific DROP rule placed after a broad ACCEPT rule is silently, completely ineffective — not a partial mitigation, a complete no-op — because the broad ACCEPT rule already matched and stopped evaluation before the kernel ever reaches the DROP rule beneath it. This is worth internalizing as the reason iptables rulesets are conventionally written most-specific-first, general-default-last (exactly the pattern this chapter's own minimal ruleset example follows) — the opposite ordering silently defeats the entire point of the more specific rule.

nftables — What Actually Changed#

nftables is not simply "iptables with new syntax" — worth naming the genuine architectural improvements precisely, since they explain why every major distribution has converged on it as the default.

The native sets/maps improvement deserves the strongest emphasis of the four, since it's the one most directly relevant to a platform engineer's own daily firewall-authoring experience: matching "traffic from any of these 500 IP addresses" in iptables required installing and managing a separate ipset, referenced awkwardly from iptables rules; in nftables, sets (and maps, which pair a value with each set member — e.g. mapping a port directly to a target) are first-class, native syntax, with optional timeouts and no separate package needed at all.

nftables Syntax — Tables, Chains, and Rules Revisited#

nftables keeps the same conceptual hierarchy (tables contain chains, chains contain rules) but with meaningfully different syntax and one further concept: every table belongs to an explicit address family.

# Create a table for IPv4 (the 'inet' family covers BOTH IPv4 and IPv6 in one table)
nft add table inet filter

# Create a chain attached to the INPUT hook, with a default DROP policy
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Add a rule to that chain
nft add rule inet filter input tcp dport 22 accept

The inet address family deserves specific mention as a genuine, practical improvement over iptables' split model: where iptables required entirely separate iptables and ip6tables commands and rulesets to cover IPv4 and IPv6 respectively, nftables' inet family lets a single table and chain definition apply to both protocol families simultaneously — a real reduction in rule duplication and drift risk for any host that needs to filter both IPv4 and IPv6 traffic consistently, which is increasingly the default expectation rather than an edge case.

Sets and Maps — nftables' Native Answer to ipset#

# Define a set of "trusted admin IPs" allowed SSH access
nft add set inet filter trusted_ips { type ipv4_addr \; }
nft add element inet filter trusted_ips { 10.0.1.5, 10.0.1.6, 10.0.1.7 }
nft add rule inet filter input ip saddr @trusted_ips tcp dport 22 accept

# A MAP: port -> target, letting one rule route multiple ports to different verdicts
nft add map inet filter port_map { type inet_service : verdict \; }
nft add element inet filter port_map { 22 : accept, 80 : accept, 23 : drop }
nft add rule inet filter input tcp dport vmap @port_map

The map example is worth reading carefully, since it demonstrates a genuine capability iptables has no clean native equivalent for: one single rule (tcp dport vmap @port_map) replaces what would otherwise require three separate iptables rules, one per port, each with its own explicit target — as the number of ports/IPs/verdicts a ruleset needs to express grows, this compresses meaningfully both in rule count and in the resulting kernel-side lookup performance, since a map lookup is a single efficient operation rather than a linear scan through many individual rules.

A Minimal nftables Ruleset, Built Up Step by Step#

Worth seeing the exact same minimal ruleset from this chapter's earlier iptables section, re-expressed in nftables — a direct, side-by-side translation aid.

#!/usr/sbin/nft -f

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

        # Allow established/related connections (conntrack, covered earlier)
        ct state established,related accept

        # Allow loopback
        iif lo accept

        # Allow SSH and HTTPS
        tcp dport { 22, 443 } accept
    }
}

Worth noticing directly: this entire ruleset is one file, loaded atomically via nft -f ruleset.nft — a genuine operational improvement over iptables' traditional one-command-at-a-time application, since a mid-application failure with iptables could leave a host in a partially-applied, inconsistent firewall state, while nftables' atomic load either fully succeeds or fully fails with no partial state in between. The tcp dport { 22, 443 } syntax is nftables' inline anonymous set notation — functionally similar to the named trusted_ips set from the previous section, just declared inline for a one-off list that doesn't need to be referenced elsewhere.

Migrating From iptables to nftables — iptables-translate and the Compatibility Layer#

A team with a large, existing body of iptables rules and scripts doesn't need to hand-rewrite everything from scratch — iptables-translate (and its IPv6 equivalent ip6tables-translate) converts individual iptables rules into their nftables equivalent automatically.

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# outputs: nft add rule ip filter INPUT tcp dport 22 accept

This tool converts one rule at a time — worth stating precisely what it does and doesn't guarantee: it produces a syntactically correct nftables equivalent for that specific rule, but does not validate the resulting ruleset's overall behavior against the original's real-world traffic patterns. The concrete, repeatedly-emphasized migration discipline worth following (directly echoing this course's own general "verify before trusting an automated tool's output" caution): migrate a non-production/dev environment first, run the translated ruleset for a genuinely realistic observation window — not a rushed 30-minute test — since container-networking and other edge cases in a real ruleset surface during normal operation over days, not during a focused, artificial test window. Red Hat and other major distributions also ship their own translation tooling as part of their own migration guidance, worth checking for a distro-specific starting point before hand-translating a large existing ruleset rule by rule.

Why Every Major Distro Has Already Switched#

Worth stating the current, verified state plainly rather than treating this as an open debate: as of 2026, nftables is the default packet-filtering framework on every major Linux distribution — Ubuntu 22.04+, Debian 11+, RHEL 9+/AlmaLinux 9+, and Fedora 35+ all default to it, with iptables itself, where still present, most commonly implemented as a compatibility shim translating to nftables underneath rather than the original, separate kernel-level iptables mechanism.

Worth stating directly, matching this course's own research-before-writing discipline: a platform engineer still authoring raw iptables commands directly against a 2026-era distribution is, in the large majority of cases, actually driving the nftables backend through a compatibility translation layer, whether they realize it or not — a detail worth knowing specifically because debugging a firewall issue by inspecting nft list ruleset directly can reveal state that a purely iptables-focused debugging approach would miss entirely on a modern system.

Policy-Based Routing — Beyond the Single Default Route#

Everything covered so far in this chapter has been about whether a packet is allowed through — this section covers a genuinely separate concern: which path a packet takes, when a host has more than one possible route to choose from.

The concrete motivating scenario worth stating precisely, since it's what makes policy-based routing genuinely necessary rather than an academic curiosity: a multi-homed host (multiple network interfaces, potentially multiple ISPs or VPCs) has more than one theoretically valid path for a given packet, and a single, plain routing table has no mechanism to say "traffic that originated from interface A should always route back out through interface A's own gateway," which is exactly the kind of asymmetric-routing bug that silently breaks connectivity for a subset of traffic on a genuinely multi-homed host. Policy-based routing solves this by maintaining multiple, separate routing tables and a set of rules (evaluated in priority order, much like netfilter's own rule-ordering discipline covered earlier in this chapter) selecting which table applies to a given packet based on criteria beyond just destination — source address, source interface, or even packet marks set by an earlier mangle-table rule.

Routing Tables and ip rule#

# List existing routing tables (by default, only 'main' has real content)
ip route show table main

# Add a rule: traffic FROM 10.0.2.0/24 should use routing table 100
ip rule add from 10.0.2.0/24 table 100

# Populate table 100 with its own default route, via a different gateway
ip route add default via 10.0.2.1 table 100

Reading this sequence: ip rule decides WHICH routing table a packet consults, while ip route ... table N populates the actual routes WITHIN that specific table — two genuinely separate configuration steps that together implement policy-based routing. ip rule list (with no other arguments) shows the current rule priority order, evaluated top to bottom exactly like netfilter's own chains — the same first-match-wins discipline this chapter has now covered twice, in two genuinely different kernel subsystems, worth recognizing as a repeated Linux networking idiom rather than a coincidence.

A Worked Example: Multi-Homed Routing With ip rule#

Tying this chapter's routing section together into one complete, realistic scenario — a host with two network interfaces, eth0 (primary ISP) and eth1 (backup ISP), needing traffic that originates from each interface's own address to route back out through that same interface.

# Table 10 for eth0's own outbound traffic
echo "10 eth0-table" >> /etc/iproute2/rt_tables
ip route add default via 203.0.113.1 dev eth0 table eth0-table
ip rule add from 203.0.113.5 table eth0-table

# Table 20 for eth1's own outbound traffic
echo "20 eth1-table" >> /etc/iproute2/rt_tables
ip route add default via 198.51.100.1 dev eth1 table eth1-table
ip rule add from 198.51.100.9 table eth1-table

Without this configuration, a genuinely common and confusing failure mode occurs: a connection arriving on eth1 gets a response that the kernel's single, plain default route sends back out through eth0 instead — asymmetric routing that many upstream networks and firewalls will silently drop, since the reply doesn't match the path the original request took. This worked example's two ip rule entries are what force each interface's own traffic to route symmetrically back through itself, resolving that exact class of bug — a genuinely common, easy-to-misdiagnose issue on any host with more than one network path, worth recognizing by this symptom rather than debugging blindly.

Looking Ahead — eBPF and XDP as an Emerging Alternative#

Worth a forward-looking preview, directly setting up this series' own later eBPF chapter: netfilter, as comprehensive as this chapter's coverage has been, is not the only kernel-level packet-processing mechanism in modern Linux — eBPF and XDP (eXpress Data Path) offer a genuinely different, increasingly significant alternative, worth knowing exists even before this series covers it in full depth.

The concrete, practical reason this distinction matters, worth stating precisely rather than treating XDP as merely "netfilter but newer": XDP's hook point fires before the kernel has even allocated its normal packet-representation structure, giving an XDP program genuinely lower per-packet processing overhead than any netfilter-based rule ever could achieve — which is exactly why XDP is the mechanism of choice for extremely high-packet-rate use cases like DDoS mitigation at the very edge of a network, where every nanosecond of per-packet overhead compounds significantly at scale. This isn't a replacement for the netfilter material covered throughout this chapter — the large majority of real firewall, NAT, and routing needs are served perfectly well by netfilter/nftables, and XDP's own steeper programming complexity (writing eBPF programs rather than declarative rule syntax) is a real cost worth reserving for cases that genuinely need XDP's specific performance profile. This series' own dedicated eBPF chapter picks this exact thread back up in full depth — including Cilium's own eBPF-based Kubernetes networking, already referenced earlier in this chapter's own CNI-plugin section.

How This Connects to Kubernetes — kube-proxy's iptables and IPVS Modes#

Worth a direct, explicit callback to this course's own Kubernetes Deep Dive series: kube-proxy, the component responsible for implementing Kubernetes Service virtual IPs, has historically run in one of two modes, both of which are direct, concrete applications of this chapter's own material.

The iptables-mode detail is worth stating as directly, concretely connected to this chapter's own DNAT section, not merely analogous to it: kube-proxy's iptables mode programs real DNAT rules in the nat table, rewriting a Service's stable virtual IP to one of that Service's actual backing Pod IPs — the exact mechanism this chapter's own DNAT section demonstrated with a plain port-forwarding example, just generated and maintained automatically by kube-proxy rather than hand-authored. A platform engineer debugging "why isn't traffic to this Service reaching my Pod" on a cluster running kube-proxy in iptables mode can — and should — inspect the actual generated iptables rules directly (iptables -t nat -L KUBE-SERVICES -n) using exactly the diagnostic technique this chapter has built up, rather than treating kube-proxy's own behavior as an unexplainable black box.

How This Connects to CNI Plugins#

Beyond kube-proxy specifically, several CNI plugins (Calico's iptables-based dataplane mode, in particular) implement Kubernetes NetworkPolicy enforcement as generated iptables/nftables rules directly — the exact filtering mechanism this chapter's own filter table section covered, now applied automatically per-Pod based on a NetworkPolicy object's declared intent.

This is worth stating as the same "declarative Kubernetes object, real underlying kernel mechanism" pattern this entire course returns to repeatedly — a NetworkPolicy is a declaration of intent; the actual enforcement, on an iptables/nftables-based CNI dataplane, is literally this chapter's own filter-table ACCEPT/DROP rules, generated and continuously reconciled by the CNI plugin's own controller. Newer CNI plugins (Cilium's eBPF-native dataplane, covered in this series' own later eBPF chapter) implement the same NetworkPolicy enforcement concept through an entirely different kernel mechanism — worth knowing both exist, and that "how is NetworkPolicy actually enforced" has a genuinely different, concrete answer depending on which CNI plugin a cluster runs.

Rate Limiting at the Firewall Layer#

Worth a dedicated section on a genuinely common production need this chapter hasn't yet covered directly: throttling how frequently a given rule matches — the firewall-layer equivalent of the application-layer rate limiting this course's CI/CD & GitOps series covers for BackendTrafficPolicy and API gateways.

# iptables: limit new SSH connection attempts to 4 per minute, per source IP
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH_ATTEMPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 5 --name SSH_ATTEMPT -j DROP

# nftables: the same intent, expressed natively with a rate-limit statement
nft add rule inet filter input tcp dport 22 ct state new limit rate 4/minute accept

The nftables version deserves specific emphasis as a genuine syntax and clarity improvement — limit rate 4/minute expresses the throttling intent directly as a native rule statement, where the iptables equivalent requires composing two separate rules around the recent module's own tracking-and-matching mechanism. Both approaches accomplish the same underlying goal — mitigating a brute-force SSH login attempt at the kernel firewall layer, before it ever reaches the SSH daemon itself — worth knowing as a defense-in-depth layer alongside, not instead of, application-level protections like fail2ban or SSH's own MaxAuthTries setting.

Logging and Auditing Firewall Activity#

Beyond the ad-hoc debug logging covered later in this chapter's own troubleshooting workflow, a production firewall commonly needs standing, ongoing audit logging for specific categories of traffic — worth distinguishing this from temporary debug logging as a genuinely different, longer-lived use case.

# Log and then drop traffic to a genuinely sensitive, rarely-used management port
iptables -A INPUT -p tcp --dport 9090 -j LOG --log-prefix "MGMT-PORT-ACCESS: " --log-level 4
iptables -A INPUT -p tcp --dport 9090 -j DROP

# nftables equivalent, combined into a single rule
nft add rule inet filter input tcp dport 9090 log prefix "MGMT-PORT-ACCESS: " drop

The --log-prefix (or log prefix in nftables) value is worth treating as a genuinely important piece of operational hygiene, not a cosmetic detail — a consistent, greppable prefix convention across every logging rule on a fleet of hosts is what makes centralized log aggregation (this course's own Observability series) actually useful for firewall-level auditing, letting a platform team search across an entire fleet for "who's been probing this specific sensitive port" rather than manually correlating raw, prefix-less kernel log lines host by host. Logged packets appear in the kernel ring buffer, retrievable via journalctl -k or dmesg, the same commands this chapter's own debugging workflow already uses for ad-hoc traces — the distinction is purely about whether a logging rule is a permanent, standing part of the ruleset or a temporary diagnostic addition.

Debugging a Firewall Rule — a Practical Workflow#

Worth closing this chapter's technical content with a concrete, repeatable debugging sequence for the single most common real-world question this material gets applied to: "why is this traffic being blocked (or allowed) when I expect the opposite?"

# 1. Confirm which framework is actually active
nft list ruleset | head -5   # if this returns rules, nftables IS the active engine

# 2. Trace which specific rule a test packet actually matches
nft add rule inet filter input tcp dport 8080 counter log prefix "DEBUG-8080: "
# (iptables equivalent: iptables -I INPUT -p tcp --dport 8080 -j LOG --log-prefix "DEBUG-8080: ")

# 3. Watch the kernel log for the traced packet
journalctl -k -f | grep DEBUG-8080

# 4. Check conntrack state for an established-connection mystery
conntrack -L | grep <suspect-ip>

Step 2's counter log addition deserves the strongest emphasis, since it's the single most useful, underused debugging technique for netfilter issues: rather than guessing which rule in a long ruleset is actually matching a given packet, adding a temporary logging rule (with a counter to also confirm exactly how many packets hit it) makes the kernel itself report ground truth — genuinely faster and more reliable than reasoning about rule order and matches purely by reading the ruleset text, especially on a host with a large, organically-grown ruleset where the actual evaluation order isn't obvious at a glance.

Higher-Level Firewall Managers — firewalld and ufw#

Worth an honest, practical section on a detail this chapter's own hands-on iptables/nftables examples might otherwise obscure: most production Linux hosts, particularly on RHEL-family and Ubuntu-family distributions respectively, are not managed via raw iptables/nft commands day to day at all — they're managed through a higher-level abstraction.

This is worth internalizing as directly analogous to the earlier "GKE Gateway is a facade over Google Cloud Load Balancing" pattern from this course's own Kubernetes series, just one layer down the stack: firewalld and ufw are convenient, higher-level facades over the exact same netfilter/nftables machinery this entire chapter has covered directly — firewalld's zone model (a network interface assigned to a public, internal, or trusted zone, each with its own default rule set) and ufw's simple ufw allow 22/tcp syntax both compile down to real nftables rules underneath, inspectable via nft list ruleset exactly as this chapter's own debugging section already demonstrated. The practical reason to understand the raw layer covered throughout this chapter, even when a production host is managed through firewalld or ufw day to day: when a firewalld- or ufw-managed host behaves unexpectedly, the actual, ground-truth diagnosis still happens at the nftables layer this chapter has covered directly — the higher-level tool's own abstraction can obscure exactly which underlying rule is actually causing an issue, making a "drop to the raw ruleset and trace it" skill genuinely necessary even on a host that's never had a raw iptables/nft command typed into it directly.

Egress Filtering and a Zero-Trust Posture#

Every example so far in this chapter has focused on INPUT filtering — worth a dedicated section on OUTPUT/egress filtering specifically, since it's a genuinely different, less commonly implemented discipline with its own real security value.

# Default-deny OUTPUT, then explicitly allow only what's genuinely needed
iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -d api.internal.example.com -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

This is worth connecting directly to this course's own DevSecOps series and its supply-chain-security material: egress filtering is a genuine, concrete defense-in-depth control against exactly the class of incident that series covers — a compromised dependency or build tool attempting to exfiltrate secrets or call out to an attacker-controlled server. A host with unrestricted outbound access gives a successful compromise a free, unmonitored exit path; a host with disciplined, allowlisted egress filtering forces that same compromise to either fail outright or generate an anomalous, loggable connection attempt against a rule that doesn't match anything legitimate — the same "assume compromise, limit blast radius" philosophy this course applies to IAM scoping and network segmentation generally, now applied specifically at the host firewall's OUTPUT chain. Worth stating honestly: this is real, ongoing operational overhead (every legitimate new outbound dependency needs an explicit rule addition), which is exactly why it's more commonly implemented for high-value, security-sensitive hosts than applied blanket across an entire fleet.

A Full Realistic Example: A Production Web Server Firewall#

Tying this entire chapter's material together into one complete, production-realistic nftables ruleset for a public-facing web server — HTTPS traffic, SSH restricted to a management network, rate-limited login attempts, and default-deny for everything else.

#!/usr/sbin/nft -f

table inet filter {
    set mgmt_network {
        type ipv4_addr
        flags interval
        elements = { 10.0.100.0/24 }
    }

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

        # Established/related connections (conntrack)
        ct state established,related accept

        # Loopback
        iif lo accept

        # ICMP (ping) — genuinely useful for operational health checks
        ip protocol icmp icmp type echo-request accept

        # HTTPS, open to the world
        tcp dport 443 accept

        # SSH, restricted to the management network AND rate-limited
        ip saddr @mgmt_network tcp dport 22 ct state new limit rate 4/minute accept

        # Everything else: logged, then implicitly dropped by the chain policy
        log prefix "INPUT-DROP: " counter
    }

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

Worth reading this ruleset as the concrete, worked synthesis of nearly every section in this chapter: the mgmt_network set (this chapter's own sets/maps section) scopes SSH access narrowly rather than opening it to the world; the rate limit (this chapter's own rate-limiting section) throttles brute-force attempts even from within that already-restricted network; the trailing log rule (this chapter's own logging section) gives standing visibility into everything the default-deny policy actually blocks, without needing a separate, explicit DROP rule since the chain's own default policy handles that. This single file, loaded atomically via nft -f, replaces what would be a much longer, more error-prone, non-atomically-applied sequence of individual iptables commands — the concrete, practical payoff of everything this chapter has built up about nftables' genuine improvements over the older model.

IPv6 Filtering — What Genuinely Differs#

Worth a dedicated section given how commonly it's overlooked entirely: a host with IPv6 enabled (increasingly the default, not an opt-in, on modern cloud providers and distributions) has a genuinely separate packet-filtering surface that a purely IPv4-focused ruleset does nothing to protect.

This is worth stating as a genuinely common, easy-to-miss real-world security gap, not a theoretical edge case: a team that writes a careful iptables ruleset and never touches ip6tables (or, in nftables, never uses the inet family covered earlier in this chapter) has effectively left an entire, un-firewalled parallel protocol stack exposed, if IPv6 is enabled on that host at all — which is increasingly the default on modern cloud instances. The nftables inet family is the direct, concrete fix this chapter already introduced — a single table/chain/ruleset definition using inet (rather than the IPv4-only ip family) automatically covers both protocols with the identical set of rules, closing this gap by construction rather than requiring a parallel, easily-forgotten ip6tables ruleset to be separately authored and kept in sync.

mangle and raw Tables — a Brief, Honest Mention#

This chapter has deliberately focused on the filter and nat tables as covering the large majority of real production use cases — worth a brief, honest mention of the two remaining built-in tables rather than omitting them entirely.

The mangle table's packet-marking capability is worth connecting directly back to this chapter's own policy-based routing section: a mangle-table rule can mark packets matching some application-specific criteria, and an ip rule can then select a routing table based on that mark — a genuinely more flexible selection criterion than routing purely by source address, useful when the actual routing decision needs to depend on something the packet's addressing alone doesn't expose (e.g. marking traffic from a specific application by its outgoing socket, rather than by a fixed source IP range). Both tables are worth knowing exist and roughly what they're for; neither is where a platform engineer should expect to spend the bulk of their firewall-authoring time, which is why this chapter's own depth has gone to filter and nat instead.

Key Terms Glossary — This Chapter's Vocabulary in One Place#

Testing Firewall Changes Safely — the Remote-Lockout Problem#

Worth a closing, genuinely important operational section: every technique in this chapter is capable of the single most common self-inflicted firewall incident — remotely locking yourself out of a host by applying a rule that blocks the very SSH connection you're using to apply it.

# A scheduled auto-revert — the single most practical safety net for remote firewall changes
(sleep 300 && nft flush ruleset && nft -f /etc/nftables-known-good.conf) &
# ... now apply the risky new ruleset ...
nft -f /etc/nftables-new.conf
# If the new ruleset breaks your SSH access, the backgrounded job reverts it in 5 minutes.
# If everything's fine, kill the backgrounded job before it fires: kill %1

This scheduled-auto-revert pattern deserves the strongest emphasis in this entire section, since it's the single cheapest, most broadly applicable safety net available for exactly this failure mode — worth treating as a standing habit for any firewall change applied over a remote connection, not just a "if I remember" precaution. The alternative safety nets (testing on a genuinely disposable non-production host first, or having an out-of-band console access path like a cloud provider's serial console or a physical server's IPMI/iDRAC interface available as a fallback) are both real and worth having in place, but the auto-revert pattern is the one that requires no advance infrastructure investment and works on essentially any host — the practical, always-available default this chapter recommends.

A Comparison Table: iptables vs. nftables vs. XDP/eBPF#

Worth closing this chapter's technical content with a single, scannable reference consolidating every packet-processing mechanism covered — the practical "which one should I actually reach for" summary.

Reading this table as this chapter's own closing decision guide: for the large majority of real firewall, NAT, and routing needs, nftables is the correct default choice on any current system — genuinely portable across IPv4/IPv6 via its inet family, atomic in its rule application, and the platform every major distribution has already standardized on. iptables remains worth understanding deeply (as this entire chapter has covered) both because of the sheer volume of existing production infrastructure still using its syntax and because, on most modern distros, it's quietly still nftables underneath a compatibility shim. XDP/eBPF is worth reaching for specifically when a workload's packet-rate and latency requirements genuinely exceed what netfilter-based filtering can deliver — not as a default replacement for the rest of this chapter's material.

Managing Firewall Rules as Code#

Worth a closing connection to this course's own Automation, CI/CD & GitOps series: hand-typed iptables/nft commands run interactively on a live host are worth treating as a debugging technique, not a production change-management practice — the same IaC discipline that series argues for generally applies directly to firewall configuration.

The nft -c -f <file> check-only flag deserves specific mention as a genuinely useful CI-pipeline validation step, directly parallel to terraform plan from this course's own IaC chapter — it validates a ruleset's syntax without actually applying it, catching a malformed rule before it ever reaches a real host. Managing firewall rules this way — version-controlled, reviewed, validated in CI, and applied through the same configuration-management or image-build pipeline as every other piece of host configuration — directly avoids both classes of failure this chapter has covered at length: the remote-lockout problem (a bad change deployed through a controlled pipeline with rollback built in, rather than a manually-typed command with no safety net) and firewall drift (a ruleset that only exists as one host's own accumulated, undocumented manual changes, with no record of what's actually supposed to be there or why).

Monitoring Firewall and Connection-Tracking Health#

Worth a closing observability connection: a firewall's own health is itself worth monitoring proactively, not just consulted reactively during an incident — directly extending this course's own Observability series into the netfilter layer specifically.

The conntrack table's finite size deserves the strongest emphasis in this closing section, since it's a genuinely common, non-obvious production capacity limit that has nothing to do with CPU, memory, or network bandwidth in the way those resources are normally monitored: sysctl net.netfilter.nf_conntrack_max sets a hard ceiling on the number of tracked connections a host can maintain simultaneously, and once that ceiling is reached, entirely new connection attempts are silently dropped — a failure mode that looks identical to a network problem or an application-level issue from the outside, but is actually a firewall-layer capacity exhaustion. conntrack -S reports real-time statistics including the current table size and any drop events specifically attributable to a full table — worth alerting on directly (this course's own Observability series' alerting discipline, applied here) rather than discovering this specific failure mode for the first time during an actual capacity incident. The per-rule counter statement already used throughout this chapter's own worked examples serves a second, ongoing purpose beyond one-off debugging: trended over time in a metrics pipeline, a rising hit count on a specific DROP rule is itself a genuine, actionable signal — a sudden spike against a rule blocking a specific port often indicates a scan or attack attempt worth investigating proactively, before it escalates into something that demands reactive incident response.

Container-Specific Netfilter Considerations#

Worth a closing, direct bridge to Part 5's own subject: containers add a genuinely distinct wrinkle to everything covered in this chapter, worth naming explicitly before this series moves on to namespaces and virtual networking in full depth.

This is worth flagging as a genuinely common source of confusion for anyone applying this chapter's own techniques on a host that also runs Docker or containerd: those runtimes program their own netfilter rules automatically — most notably a DOCKER-USER chain specifically provided as the correct, supported insertion point for custom filtering rules that need to apply to container traffic without being silently overridden by Docker's own auto-generated rules on a restart. A platform engineer who inserts a custom rule directly into the FORWARD chain, rather than into DOCKER-USER specifically, has a real risk of that rule being reordered or bypassed the next time Docker regenerates its own chain structure (which happens automatically on daemon restart) — worth knowing this specific chain name exists and why, rather than discovering the interaction the hard way after a rule mysteriously stops applying. Part 5, immediately following, picks up exactly this container-networking thread in full depth — network namespaces, veth pairs, and the virtual topology container runtimes construct before any of this chapter's own filtering rules ever get a chance to apply.

How This Relates to Cloud Security Groups and NACLs#

Worth a final, practical clarification for anyone whose production infrastructure runs primarily on a cloud provider: cloud security groups (AWS Security Groups, Azure NSGs) and this chapter's host-level netfilter material are complementary layers, not competing or redundant ones.

The practical, defense-in-depth reasoning worth stating directly: a security group correctly scoped to allow only port 443 from the internet is a real, effective control, but it protects only the boundary between the internet and the instance — it does nothing to limit what a compromised process on that instance can subsequently do outbound, or to filter traffic between instances within the same security group. This chapter's own host-level firewall material — particularly the egress-filtering section covered earlier — remains a genuinely valuable additional layer even on infrastructure already protected by cloud security groups, for exactly the reason defense-in-depth exists throughout this course generally: a single control, however well-configured, is one control that can fail or be misconfigured, while two independent, complementary layers meaningfully reduce that single point of failure risk.

A Firewall Change Checklist#

Worth closing this chapter's practical guidance with a single, walkable checklist consolidating the safety disciplines this chapter has built up across multiple sections — the concrete sequence a platform engineer should actually follow before applying a firewall change to a production host.

This checklist is deliberately the same shape as this course's own general production-change discipline, applied specifically to the netfilter layer — every individual step maps directly back to a section this chapter has already covered in depth, making this table a navigation aid back into the chapter's own content as much as a standalone checklist. Treating firewall changes with this level of process discipline, rather than as quick, informal edits, is worth internalizing as the actual professional standard this chapter has been building toward across every section — not an excessive amount of ceremony for what might otherwise feel like a routine, low-stakes change.

Common Mistakes#

Worked Practice Problems#

Problem 1: A server has a default-deny INPUT policy and explicit ACCEPT rules for SSH and HTTPS, but clients report that HTTPS connections hang and never receive a response, even though the server process is confirmed listening and healthy. What's the most likely missing rule, and why?

Answer: A missing ESTABLISHED,RELATED (or ct state established,related) rule. Under a default-deny INPUT policy, the server's own outbound response packets to an already-established inbound connection are themselves subject to the INPUT chain's filtering on their way back — without a rule explicitly allowing established/related traffic, those response packets get dropped, even though the initial SYN was correctly accepted by the HTTPS-specific rule. The fix is adding a ct state established,related accept (or the iptables equivalent) rule, conventionally placed near the top of the chain.

Problem 2: A team writes a DNAT rule in the POSTROUTING chain instead of PREROUTING, forwarding external port 8080 to an internal server, and it doesn't work as expected. Diagnose the issue.

Answer: DNAT rewrites a packet's destination address, and this rewrite needs to happen BEFORE the kernel makes its routing decision — since the routing decision itself depends on the (correct, final) destination address. Placing the DNAT rule in POSTROUTING means the routing decision has already been made against the original, un-rewritten destination by the time the rule applies, producing incorrect or non-functional behavior. DNAT belongs in PREROUTING specifically because it's the hook that fires before the routing decision.

Problem 3: A platform team migrating from iptables to nftables via iptables-translate runs the tool against their entire ruleset, gets syntactically valid nftables output with no errors, and immediately deploys it to production. What's the risk in this approach, per this chapter's own migration guidance?

Answer: iptables-translate converts individual rules correctly at the syntax level, but doesn't validate the resulting ruleset's overall real-world behavior — genuinely common issues (container-networking edge cases, subtle rule-interaction differences) surface during normal operation over a realistic time window, not during a syntax check or a rushed test. The correct approach is deploying the translated ruleset to a non-production environment first and observing it under real traffic for a genuinely realistic period (this chapter's own guidance says a week, not an hour) before trusting it in production.

Problem 4: A host with two network interfaces (eth0 and eth1, each with its own gateway) experiences intermittent connectivity issues specifically for traffic that arrives on eth1 — responses seem to silently disappear. What's the likely root cause, and what tool fixes it?

Answer: Asymmetric routing — with only a single, plain default route, response traffic to a connection that arrived on eth1 may be routed back out via eth0's own default gateway instead, since a single routing table has no concept of "route based on which interface this traffic originated from." Many upstream networks and firewalls silently drop such asymmetric traffic since the reply doesn't match the path of the original request. The fix is policy-based routing — using ip rule to route traffic sourced from each interface's own address back out through that same interface's own routing table.

Problem 5: A platform engineer inspects a firewall issue on a 2026-era Ubuntu server using only iptables -L, sees rules that appear correctly configured, but traffic is still being unexpectedly blocked. What should they check next, and why?

Answer: nft list ruleset directly. On a modern distro, iptables is very commonly a compatibility shim translating commands to the real nftables backend underneath — iptables -L shows what was configured through that compatibility layer, but doesn't necessarily reflect every rule genuinely active in the kernel's actual nftables ruleset (particularly if any nftables-native rules were added directly, bypassing the iptables compatibility layer entirely). Checking the real, underlying nftables ruleset directly gives ground truth that a purely iptables-focused debugging approach can miss.

Problem 6: A security-conscious team implements a default-deny OUTPUT policy on a fleet of application servers, per this chapter's own egress-filtering guidance. A week later, a legitimate application update starts failing because the application now needs to reach a new, previously-unused third-party API endpoint. Is this a sign the egress-filtering approach was a mistake?

Answer: No — this is the expected, real operational overhead of egress filtering this chapter explicitly flagged: every legitimate new outbound dependency requires an explicit rule addition. This is precisely the tradeoff that makes egress filtering a genuine, effective defense-in-depth control (an attacker's exfiltration attempt to an arbitrary destination fails the same way this legitimate new dependency initially did) rather than a mistake — the fix is adding an explicit allow rule for the new, legitimate destination, not abandoning the default-deny posture. This is also why egress filtering is more commonly applied to high-value, security-sensitive hosts specifically, rather than blanket across an entire fleet with frequently-changing dependencies.

Problem 7: A platform engineer applies a new nftables ruleset over an SSH session to a remote production host, without setting up a scheduled auto-revert first. The new ruleset has a mistake — the SSH-allow rule was accidentally omitted. What happens, and what should the engineer have done differently?

Answer: The SSH session drops immediately once the new default-deny ruleset takes effect (since the rule that would have allowed continued SSH access was never actually included), and — critically — no further commands can be sent to fix it remotely, since the very access path needed to correct the mistake is what the mistake itself blocked. The engineer should have scheduled a backgrounded auto-revert command (e.g. sleep 300 && nft flush ruleset && nft -f known-good.conf) before applying the risky change, so that if the SSH connection drops and stays down, the auto-revert restores known-good connectivity within minutes without requiring any further remote access — the single cheapest, most broadly available safety net for exactly this failure mode.

Problem 8: A host has IPv6 enabled by default (as is now common on modern cloud providers), and a team has written a careful, well-tested default-deny iptables (IPv4-only) ruleset. A service on that host is later found reachable from the internet over IPv6, completely bypassing every rule the team wrote. What was missed, and what's the fix?

Answer: The team's ruleset only covers IPv4 (iptables/ip filter table) — IPv6 traffic is a genuinely separate protocol stack that a purely IPv4-focused ruleset does nothing to protect, and if IPv6 is enabled on the host with no corresponding ip6tables (or nftables inet-family) rules, it's left exposed to whatever the kernel/distro's own default IPv6 policy happens to be. The fix is using nftables' inet address family (covering both IPv4 and IPv6 in one unified ruleset) rather than the IPv4-only ip family, closing this gap by construction instead of requiring a separately-authored, easily-forgotten ip6tables ruleset to be kept in sync by hand.

Problem 9: A platform engineer inserts a custom filtering rule directly into a Docker host's FORWARD chain to block traffic to a specific container. It works initially, but silently stops applying after the next Docker daemon restart. What's the most likely cause, and what's the correct fix?

Answer: Docker regenerates its own netfilter chain structure automatically on daemon restart, which can reorder or bypass a custom rule inserted directly into the shared FORWARD chain. The correct fix is inserting the custom rule into the DOCKER-USER chain specifically — the chain Docker provides as the supported, stable insertion point for custom filtering rules precisely because it's not touched by Docker's own automatic chain regeneration, unlike a rule placed directly in FORWARD.

Problem 10: A production host handling a very large number of concurrent short-lived connections starts silently dropping new connection attempts under peak load, with no CPU, memory, or bandwidth exhaustion visible in standard monitoring. What capacity limit, specific to this chapter's own material, should be checked first?

Answer: The conntrack table size — sysctl net.netfilter.nf_conntrack_max sets a hard ceiling on concurrently tracked connections, and once reached, new connections are silently dropped in a way that looks like a network or application issue from standard CPU/memory/bandwidth monitoring alone. conntrack -S reports real-time table size and any drop events specifically attributable to the table being full — the correct first check for this specific, non-obvious capacity-exhaustion failure mode.

Summary and What's Next#

Netfilter is the actual in-kernel hook framework underneath both iptables (the older, still widely-scripted frontend, now most commonly a compatibility shim on modern distros) and nftables (the current default on every major distribution as of 2026) — five hook points (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) that every rule in this chapter ultimately attaches to. The filter table's ACCEPT/DROP/REJECT targets, evaluated strictly top-to-bottom with first-match-wins semantics, are the mechanism underneath both a hand-authored firewall ruleset and every Kubernetes NetworkPolicy an iptables/nftables-based CNI plugin enforces. The nat table's DNAT (rewriting a packet's destination, applied in PREROUTING before the routing decision) and SNAT/MASQUERADE (rewriting a packet's source, applied in POSTROUTING after the routing decision) are the exact mechanism underneath both a hand-authored port-forward and kube-proxy's own iptables-mode Service implementation — a Kubernetes Service virtual IP is, concretely, a set of auto-generated DNAT rules. Conntrack's connection-tracking table is what makes a single ESTABLISHED,RELATED rule sufficient to allow all legitimate response traffic under an otherwise default-deny policy, without needing an explicit rule per possible response. nftables' genuine architectural improvements over iptables — native sets/maps (no separate ipset package needed), a unified inet address family covering IPv4 and IPv6 in one ruleset, and atomic ruleset loading — are why every major distribution has already switched, with iptables-translate and a disciplined, non-production-first migration approach as the practical path for teams with a large existing iptables investment. Policy-based routing (ip rule plus multiple routing tables) extends this same first-match-wins, kernel-level rule-evaluation discipline to routing decisions themselves, resolving the asymmetric-routing failure mode a genuinely multi-homed host otherwise hits. Beyond the core mechanics, real production discipline layers rate limiting and standing audit logging on top of the base filtering rules, extends default-deny thinking to egress traffic as a genuine defense-in-depth control, and treats the entire ruleset as version-controlled, CI-validated infrastructure rather than a set of manually-typed, undocumented commands — with a scheduled auto-revert as the cheapest available safety net against the single most common self-inflicted failure mode this chapter covers: a remote lockout from a host's own SSH access.

Part 5, immediately following, builds directly on this chapter's own foundation: network namespaces, veth pairs, and Linux bridges — the virtual networking primitives that CNI plugins and container runtimes construct pod networking from, using this chapter's own netfilter/iptables/nftables machinery as the packet-filtering and NAT layer operating on top of that virtual topology.

Every packet a container, a Kubernetes Pod, or a plain host process ever sends or receives ultimately passes through the exact hook framework this chapter opened with — Part 5's own virtual networking primitives are, concretely, one more layer of topology this same machinery operates on, not a separate, unrelated subsystem.