Linux netfilter · Event nf_conntrack: table full, dropping packet
nf_conntrack: table full — the firewall stopped accepting connections
The kernel's connection tracking table filled up and it is now dropping new connections. The machine looks fine, the service looks fine, and nothing works — this message in the kernel log is often the only evidence of why.
Also written as ip_conntrack table fullconntrack table full linuxnf_conntrack_max exceeded
- How oftenRare
- Vendor calls itkern.err
- Logkern
What it means for you
For an analyst
Two very different causes wearing the same message. Either the table is genuinely too small for the traffic, in which case raising nf_conntrack_max and the hash bucket count together is the fix — raising max without the buckets degrades lookup into long chains and costs you CPU. Or something is filling it: a scan, a SYN flood, or, most commonly and least dramatically, a UDP-heavy workload whose entries sit at the default 30-second timeout while thousands more arrive. Check the composition with conntrack -L before resizing, because a table full of UDP entries in the same state is a timeout problem rather than a capacity one, and doubling the table just doubles how long it takes to fill.
The fields that decide it
Everything else in the log line is context.
- nf_conntrack_max
- The table size limit. The current value is in /proc/sys/net/netfilter/nf_conntrack_max and the current occupancy in nf_conntrack_count.
- nf_conntrack_buckets
- The hash bucket count. It should scale with max — commonly a quarter of it — because a large table with too few buckets turns lookups into long chain walks.
- Entry composition
- Not in the message. 'conntrack -L' shows what is actually in the table, and the answer determines the fix.
-
Mostly UDP entries in the same stateA timeout problem. Thousands of short UDP exchanges held for the full timeout. -
Mostly TIME_WAIT or SYN_SENTEither a scan, a flood, or an application opening far more connections than it closes. -
Mostly ESTABLISHED from few sourcesGenuine load. This is the case where resizing is the right answer. - Timeout settings
- The per-protocol timeouts under /proc/sys/net/netfilter/. The generic and UDP timeouts are the ones that most often need lowering on a busy machine.
- Which machine is reporting it
- Worth confirming. A busy router or NAT gateway tracks every flow passing through it, so it fills far sooner than an endpoint carrying the same nominal traffic.
Common questions
How do I fix 'nf_conntrack: table full, dropping packet'?
As an immediate measure, raise net.netfilter.nf_conntrack_max — and raise nf_conntrack_buckets with it, since a bigger table with the same number of hash buckets makes lookups slower. Before making it permanent, run 'conntrack -L' to see what is filling the table. If it is thousands of UDP entries sitting at their timeout, lowering the timeout is the real fix and resizing only delays the next failure.
Does this mean I am being attacked?
Sometimes, but capacity and configuration are more common. A SYN flood or a large scan will fill the table, and so will an application that opens connections faster than it closes them, or a NAT gateway sized for less traffic than it now carries. Look at the table contents before concluding anything: an attack usually shows as many entries from few or spoofed sources in an early connection state.
What happens when the conntrack table is full?
New connections are dropped while existing tracked ones keep working. That produces a distinctive and confusing symptom — current sessions are fine, new ones time out, and nothing in the application logs explains it. Because the failure is silent from userspace, this kernel message is often the only direct evidence.
Should I disable connection tracking instead?
Only where you genuinely do not need stateful filtering, such as a pure forwarding path that can use the raw table's NOTRACK target for high-volume flows. Turning it off wholesale removes the ability to write stateful rules and to do NAT, which is usually a far bigger loss than the table size problem it solves.
Read next
- Read alongside iptables: a packet was logged by a firewall rule Explicitly logged netfilter drops, which look similar in the kernel log and have a completely different cause.
- Related Kernel: martian source — a packet arrived from the wrong direction Another kernel networking message that reads as an attack and is usually configuration.
- Related Out of memory: the kernel killed a process to stay alive Another resource exhaustion event where the log line is the only warning before an outage.
- Read alongside [UFW ALLOW]: UFW logged a connection it let through UFW allow logging, useful for confirming whether connections are reaching the firewall at all when things stop working.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026