nf_conntrack: table full, dropping packet Networking Origin: Network OSI layer 4 · Transport Last updated 5 Nov 2026

Networking: kernel: nf_conntrack: table full, dropping packet — new connections fail on a Linux firewall/NAT host

The connection-tracking table is full, so the kernel drops packets for any new connection.

Exact message you may see nf_conntrack: table full, dropping packetnf_conntrack table fullconntrack table full dropping packetip_conntrack: table full
Explore the map of this error Full error map →
Seen on: Linux Kubernetes Networking

Meaning

Busy NAT gateways, Kubernetes nodes and servers hitting nf_conntrack_max start dropping new flows (timeouts, intermittent resets). Raise net.netfilter.nf_conntrack_max (and the hash size), shorten established/TIME_WAIT timeouts, bypass tracking for heavy flows (NOTRACK), and reduce connection churn.

Common causes

  • nf_conntrack_max too low for the load
  • Connection churn or scanning/DDoS traffic
  • Long conntrack timeouts
  • Kubernetes node with many pods/services
  • UDP/DNS floods creating entries

⚡ Quick fix

  1. Compare nf_conntrack_count and nf_conntrack_max
  2. Raise the max and shorten the timeouts
  3. Use NOTRACK for high-volume flows

Detailed fix by platform

Linux

  1. bash
    sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
sudo sysctl -w net.netfilter.nf_conntrack_max=524288

How to diagnose

  1. count vs max — Near full?
  2. Source — Churn or attack?
  3. Timeouts — Too long?

🔧 Still not fixed?

Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:

Where this error sits

Origin: Network. Errors that are often confused with or caused by this one (click to open):

arp -a shows (incomplete) — Networking: `arp -n` shows (incomplete) / Destination Host Unreachable — no ARP reply from the next hop (Networking)arp -a shows (incompl…Cannot assign requested address (EADDRNOTAVAIL) — Networking: connect: Cannot assign requested address — ephemeral port range exhausted by TIME_WAIT connections (Networking)Cannot assign request…DHCPDISCOVER ... No DHCPOFFERS received — Networking: dhclient: DHCPDISCOVER on eth0 ... No DHCPOFFERS received. No working leases in persistent database - sleeping. (Networking)DHCPDISCOVER ... No D…DNS in pod — DNS not working inside a Kubernetes pod (could not resolve host / nslookup: can't resolve) (Kubernetes)DNS in podDNS lookups take 5 seconds (timeout then retry) — Networking: Every connection pauses about 5 seconds — resolv.conf nameserver timeout, then fallback to the next DNS server (Networking)DNS lookups take 5 se…NAT gateway SNAT port exhaustion (ErrorPortAllocation) — Networking: NAT gateway ErrorPortAllocation / SNAT port exhaustion — intermittent outbound connection timeouts (Networking)NAT gateway SNAT port…nfs: server not responding, still trying — Networking: kernel: nfs: server nas01 not responding, still trying / nfs: server nas01 OK (Networking)nfs: server not respo…Possible SYN flooding on port 80. Sending cookies. — Networking: TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters. (Networking)Possible SYN flooding…nf_conntr…

Explore the map of this error Full error map →

🧠 Still stuck? Analyze your error

Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.

💬 What worked for others

No tips yet — did something else fix this for you?

Share what worked for you

Tips are checked by an editor before they appear. Links are removed.