Linux connection tracking assigns every packet a state such as NEW, ESTABLISHED, RELATED or INVALID. What does each of those mean, and why does a stateful firewall need the RELATED state at all?
answer
- a table of flows, not a firewall
- first packet versus a seen conversation
- one state covers spawned side channels
- ICMP errors would otherwise be dropped
- entries die on timers, not on FINs
basics
~20 sNEW is a packet starting a flow the kernel has not seen, ESTABLISHED belongs to a flow already seen in both directions, RELATED is a separate flow spawned by an existing one such as an ICMP error, and INVALID fits no tracked flow at all.
solid answer
~50 sConnection tracking keeps a table of flows, each identified by its address and port tuple in both directions, and every packet is classified against that table. `NEW` is the first packet of a flow with no entry yet. `ESTABLISHED` means the flow has an entry and traffic has been seen in both directions, so replies are recognised. `RELATED` is the interesting one: it marks a *different* flow that the kernel can associate with an existing one — an ICMP error referring to a tracked connection, or the data connection an FTP control session negotiates. Without it, a firewall that only allows established traffic would silently discard the path-MTU and unreachable messages that TCP depends on. `INVALID` covers packets that match nothing trackable — out-of-window TCP segments, traffic arriving after an entry expired — and is normally dropped. Together these states are what let you write one broad allow for existing traffic and then be restrictive about everything new.
go deeper
Be able to name the states and say what each describes: a first packet, a conversation already underway, a side channel of one, and something that matches nothing.
Explain how the table stores both directions of a flow, why UDP can be tracked at all, and give the concrete consequence of dropping the state that covers ICMP errors.
Demonstrate you have debugged this: a hung transfer caused by discarded fragmentation-needed messages, a stateful policy leaking because invalid packets were accepted, or an idle mapping expiring under a timeout you did not tune.
Own the policy: whether helper modules are permitted anywhere in the estate, what the standard timeout profile is for gateways under load, and where stateful inspection is worth its per-flow cost at all.
## What conntrack stores Connection tracking is a kernel subsystem that sits at the netfilter hooks and maintains a hash table of *flows*. Each entry holds two tuples: the original direction (source address/port, destination address/port, protocol) and the expected reply direction. The reply tuple is what makes stateful firewalling and NAT possible — it is how the kernel recognises a returning packet as belonging to a conversation it has already approved, and how it knows which translation to undo. An entry is created when the first packet of a flow is seen, but it is only *confirmed* once that packet survives to the end of its traversal. A packet dropped by a filter rule therefore does not leave a tracking entry behind. Importantly, conntrack is not a firewall — it is bookkeeping. It classifies; the rules decide. ## The states **NEW** — the packet does not match any existing entry, or matches only in one direction so far. It is the first packet of a conversation. Note the subtlety: NEW does not mean "a TCP SYN". A stray TCP segment that matches no entry can also be classified NEW under the default permissive tracking, which is why hardened rulesets often insist that new TCP flows must actually be SYN packets. **ESTABLISHED** — the flow has an entry and the kernel has seen traffic in both directions. This is what makes the everyday firewall shape possible: allow everything established, then be restrictive about NEW. **RELATED** — a *new* flow that the kernel can attribute to an existing one. The two canonical cases are ICMP errors (a destination-unreachable or fragmentation-needed message that quotes a tracked connection's headers) and protocols whose control channel negotiates a separate data channel, such as classic FTP, handled by a helper module. RELATED is why a stateful firewall does not break path-MTU discovery: those ICMP messages are technically not part of the TCP flow, so an ESTABLISHED-only policy would drop them, and the connection would hang on large packets instead of failing cleanly. **INVALID** — the packet cannot be associated with anything: an out-of-window TCP segment, traffic arriving after the entry timed out, an ICMP error quoting a connection that is not tracked, or a packet the kernel could not parse. Dropping INVALID is standard practice; accepting it can leak traffic past a stateful policy. **UNTRACKED** — a state you only see when traffic was deliberately exempted from tracking in the raw table. It has no entry by design, so no ESTABLISHED matching applies to it. ## Protocols without connections UDP and ICMP have no connection concept on the wire, so the kernel synthesises one. A UDP entry is created from the address/port tuple of the first datagram and marked established once a reply is seen in the opposite direction; it lives on a short idle timeout, on the order of tens of seconds, extended when a stream continues. ICMP echo requests are matched to their replies by identifier. This is why "stateful UDP firewalling" is possible at all, and also why an idle UDP mapping on a NAT gateway silently dies while a TCP one might survive for days. ## Timeouts are the state machine Every entry carries a timer, and its length depends on the protocol and the observed TCP state. The value that surprises people is the established-TCP timeout, which defaults to five days: a connection whose peers both vanished without a FIN or RST keeps occupying an entry for that long. Shorter timers cover the transitional TCP states. Timers, not packets, are what actually free the table. ## Helpers, and why they are treated cautiously RELATED for protocols like FTP requires a *helper* module that parses the control channel and pre-registers the expected data connection as an expectation. Because a helper inspects payload and can be induced to open pinholes by traffic that merely looks like a control channel, helpers are increasingly disabled by default and enabled only for specific, explicitly matched traffic. ## Why this matters beyond firewalling The same table drives NAT: the nat chains are only traversed by packets in the NEW state, and every later packet is translated straight from the entry. So a change to a translation rule affects new flows only, and the state model you use for filtering is literally the same machinery that decides which packets your NAT rules will ever see.
- What breaks if a firewall allows ESTABLISHED but drops RELATED?ICMP errors referring to tracked connections are discarded. The most visible casualty is path-MTU discovery: the fragmentation-needed message never arrives, so the sender keeps retransmitting oversized packets and the connection hangs on large transfers while small requests work fine. Protocols that negotiate a separate data channel, such as classic FTP, also stop working.
- How can connection tracking be stateful about UDP, which has no connections?It synthesises a flow from the address and port tuple of the first datagram and stores the expected reply tuple. Once a datagram is seen in the opposite direction the entry is treated as established. There is no teardown signal, so the entry lives on an idle timeout of tens of seconds, refreshed by continuing traffic. That timeout is why idle UDP mappings on a NAT gateway quietly stop working.
- Why are conntrack helper modules disabled by default on many systems?A helper parses application payload on a control channel and pre-registers an expectation, effectively opening a pinhole in the firewall. Traffic crafted to look like that control channel can therefore induce the kernel to permit a connection the policy never intended. Modern practice is to leave helpers off and enable one only for explicitly matched traffic where the protocol genuinely requires it.
- Does the netfilter nat table see packets in the ESTABLISHED state?No. The nat chains are traversed only by packets in the NEW state. Once a flow's translation is recorded in its tracking entry, every subsequent packet is translated directly by the NAT engine without re-entering any rule. That is why editing a translation rule changes behaviour for new flows only, and why counters or logging placed in the nat table count flows rather than packets.
saying these in an interview costs you the question
- Thinks NEW always means a TCP SYN packet
- Believes connection tracking itself blocks traffic
- Allows only ESTABLISHED and drops ICMP errors
- Assumes UDP cannot be tracked statefully
- Thinks entries are freed when a connection closes