Firewalls, iptables, and Netfilter

A firewall is policy in the packet path. On Linux, that policy usually uses netfilter in the kernel, with nftables or iptables as user-facing tools. Operators need to understand hooks, chains, rule order, connection tracking, NAT, and the difference between local host traffic and forwarded traffic.

Command Examples

nft list ruleset
iptables-save
ip6tables-save
conntrack -S
conntrack -L | head
journalctl -k -g 'DROP|REJECT|nft|iptables|conntrack'

Example output and meaning:

Run these before changing policy. The active ruleset, counters, conntrack state, and kernel logs are the evidence.

Netfilter Packet Path

Netfilter hooks sit at key points in the Linux network stack.

The most common debugging mistake is checking INPUT for traffic that is actually being forwarded, or checking FORWARD for traffic destined to a local service.

nftables and iptables

iptables is the older command family. nftables is the newer framework and userspace tool. Many modern distributions run iptables compatibility commands over the nftables backend, so iptables-save may not mean the host is using the old kernel implementation.

Useful distinctions:

Do not mix frontends casually. If UFW, firewalld, Kubernetes, Docker, and manual rules all write policy, rule ownership becomes part of the incident.

Tables, Chains, and Rule Order

In iptables, tables group rule types:

Rules are evaluated in order. A broad accept rule before a narrow drop rule makes the drop rule irrelevant. A default DROP policy requires explicit allows for return traffic, DNS, ICMP, management access, and health checks.

Conntrack and Stateful Policy

Connection tracking records flow state so rules can allow return traffic without writing mirror-image rules for every service.

Common states:

Conntrack is also fundamental to NAT. A full conntrack table can make new connections fail while existing ones keep working.

sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count
conntrack -S
conntrack -L -p tcp | head

DROP, REJECT, Logging, and Counters

DROP silently discards packets. REJECT discards and sends an error when possible. For public internet noise, DROP is common. For internal troubleshooting, REJECT can make failures faster and clearer.

Logging every denied packet can create a production problem. Prefer rate-limited logging and rule counters:

nft list ruleset -a
iptables -L -n -v
iptables -t nat -L -n -v

Counters are only useful when you know which path the packet should take. Generate one test flow, then check whether the expected rule counter changed.

Host Firewall Example

This nftables host policy allows established traffic, loopback, SSH from a management subnet, HTTPS from anywhere, and ICMP for diagnostics. It logs denied input at a limited rate before rejecting.

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

    iif lo accept
    ct state established,related accept
    ct state invalid drop

    ip saddr 192.0.2.0/24 tcp dport 22 accept
    tcp dport 443 accept
    ip protocol icmp accept
    ip6 nexthdr ipv6-icmp accept

    limit rate 5/second log prefix "nft-drop-input: "
    reject
  }
}

Test firewall changes from an existing session and with out-of-band access available. A syntactically valid rule can still lock out SSH if the source range, interface, or default policy is wrong.

NAT and Firewalls Together

DNAT and SNAT change what later checks see. A packet may arrive for a public address, be DNATed to a private backend, then hit a filter rule using the translated destination. Return packets may be SNATed or masqueraded after routing.

Operational implications:

• capture before and after NAT boundaries when possible,
• know whether policy matches original or translated addresses,
• account for hairpin NAT when clients reach a public IP from inside,
• keep return traffic through the same stateful device unless the design supports asymmetry,
• remember IPv6 often needs firewalling without NAT.

Troubleshooting Flow

1. Identify whether traffic is local input, local output, or forwarded.
2. Confirm the route and interface before reading firewall rules.
3. Dump active nftables and iptables views.
4. Check conntrack state and table pressure.
5. Generate one test flow and inspect rule counters.
6. Capture packets at ingress, post-NAT, and egress boundaries when possible.
7. Check whether a frontend such as UFW, firewalld, Docker, or Kubernetes owns the rule.

Study Cards

References

• netfilter/iptables documentation
• nftables project documentation
• nftables connection tracking
• nftables netfilter hooks
• iptables(8)
• nft(8)