Conntrack NEW on an ACK Packet: What It Does Not Prove

The firewall log has one line you did not expect: an ACK packet, conntrack state NEW, a source address that is not yours, destination port open. The temptation is to read it as a fresh inbound connection nobody authorised. What the line actually says is narrower: when that packet reached this hook, the tracker had no matching state, and the packet carried an ACK. Those are two facts about two different things, and neither one is a handshake transcript. Here is the order I walk through before drawing a conclusion.

Start with the packet, not the verdict

Separate the observations before interpreting them. The TCP flags describe this packet, the tracker's state describes what it knew at that hook, and your capture describes only the window you recorded.

Conflating those three is how an ACK becomes "the provider let someone in".

What NEW actually means at the hook

The iptables conntrack match documents NEW as a packet that starts a connection, or one associated with a connection that has not yet seen traffic in both directions. ESTABLISHED means the tracker has seen packets both ways. Nothing in either definition says the packet was a SYN, and nothing says it arrived without a history.

A tracker that begins observing a flow midstream classifies the next packet against whatever it knows, which may be nothing. That is a statement about the tracker's memory rather than about the remote host's intent.

Loose tracking explains most ACK surprises

The kernel documents nf_conntrack_tcp_loose, which lets the tracker pick up TCP connections it did not see start. With the setting at its default, a midstream ACK can be adopted as an established flow. Turn it off and the same packet is more likely to be classified INVALID instead of NEW. Both outcomes describe the tracker's rules, not the application's history.

So check that setting before you build a theory on the label.

Rule out the boring causes in this order

Most NEW-on-ACK events I have chased ended in one of these, and all of them are cheap to check:

• The conntrack table was flushed, or the tracker restarted.
• The host rebooted, or the flow moved to another namespace or device.
• Asymmetric routing sent the SYN out of a path you are not capturing.
• NAT rewrote the tuple, so the entry no longer matches what you read.
• The capture started late and never saw the beginning.

Each of those removes the earlier packets from the tracker's view while leaving the later ones intact. A reboot or a table flush is the easiest to confirm from uptime and logs. Asymmetric routing shows up as a one-directional capture. NAT is the sneaky one, because the tuple the tracker stored is not the tuple printed in the log.

Write down which of these you excluded, and how, before you move on.

Read the tuple, the interface and the hook

A conntrack entry is keyed by addresses, ports and protocol, so any translation changes which entry matches. Record the interface and the hook too, because a packet seen on the wrong interface or after a different chain tells you the path is not what the diagram says. When the event involves a VPN, decide whether you are looking at the inner packet or the outer carrier. Then compare with what the gateway logged for the same five-tuple.

Two views of one flow that disagree are more informative than either view alone.

When it is worth escalating

Escalate when you can show a service that is reachable and should not be, with the flow, the policy that allowed it, and evidence from both ends. Do not report a provider defect on the strength of one state label or one partial capture, because that report will be closed with the explanation you just read. If the service really is exposed, the owner of that boundary is the right person to fix it, and a delegated port mapping or an unintended listener is a likelier cause than a bug.

Then fix the visibility gap that let one packet look like an entire session.