Firewalls & Connection Tracking

Most important commands to remember

• nft list ruleset — read firewall rules and policies.
• conntrack -L — inspect state remembered for flows.

Commands and flags

Command or option	Meaning
sudo nft -a list ruleset	List the ruleset with numeric rule handles; sudo supplies administrator privileges.
sudo conntrack -L -p tcp	List tracked flows, restricted to TCP.

-a adds handles, not packet capture. -L lists rather than deletes state. The example never changes firewall policy.

The concepts that matter

1. A firewall evaluates traffic at a particular point

A packet filter matches properties such as addresses, ports, protocol, interface, or tracked state and applies a verdict. In Linux, input concerns traffic delivered locally, output locally generated traffic, and forward traffic passing through the machine.

Opening an input port does not automatically permit forwarded traffic through a router. First identify where the packet travels, then inspect the rules at that point.

2. State connects packets into a flow

Connection tracking associates packets with a conversation. new identifies traffic starting a tracked flow; established identifies packets belonging to a flow with traffic seen in both directions. related covers recognized associated traffic, such as some ICMP errors.

These are firewall tracking states, not application login states. UDP flows can be tracked too. A rule accepting established traffic can permit replies without an independent rule for every client port.

3. Order and default policies matter

Rules are evaluated in chains. Matching a terminal verdict ends processing in that chain, while nonterminal actions such as counters can allow evaluation to continue. A base chain’s policy handles packets reaching its end without another verdict.

In nftables, an accept in one base chain does not necessarily bypass later chains or hooks. A later drop can still block the packet. Reading one apparent allow rule is therefore not enough to understand the complete policy.

4. Allowing packets does not create a service

An allow decision does not start a listener, repair routing, authenticate a user, or make an application healthy. Likewise, a timeout does not identify which firewall, if any, blocked traffic.

Use rules, counters, connection state, and endpoint evidence together. Counter increases show matches at a specific rule, not successful application transactions. Other network devices or cloud controls may enforce policy outside the guest’s visible ruleset.

One small example

Optional: run these inspection commands on a Linux lab VM where you may view firewall state.

sudo nft -a list ruleset
sudo conntrack -L -p tcp

Read the table family (ip, ip6, or inet), base-chain hook, priority, policy, and rule order. Handles identify individual rules; they are not priority values. If a rule has counters, packets and bytes are cumulative since their initialization or reset.

Conntrack shows protocol, timeout in seconds, state, and original/reply endpoint tuples. A tracked entry means the kernel recorded a flow; it does not prove the application answered. Empty rules or flow lists can be valid. Missing permission or kernel support should be distinguished from an empty result.

These are local observations only. No rules are flushed, connections disrupted, or cleanup required.

Keep this idea: Identify the packet path, follow the complete policy, and treat tracked state as network evidence rather than application success.