Most game server owners prepare for volumetric DDoS \u2014 a flood of gigabits that saturates the uplink. Modern attackers increasingly skip that. Instead they exhaust connection state. A few thousand short-lived TCP or UDP flows, opened and abandoned, can fill a server’s connection tracking table long before bandwidth becomes a problem. The result is a server that reports low CPU and plenty of free bandwidth while new players simply cannot connect, and existing connections time out with no obvious cause. This is connection-table exhaustion, and it is one of the most under-defended failure modes in game hosting.<\/p>\n\n\n\n
This article covers how to detect it, how to size your connection tracking for realistic player loads, and how to harden a Linux host so a moderate flood degrades gracefully instead of taking the whole box offline. It assumes a dedicated or bare-metal machine where you have kernel-level control.<\/p>\n\n\n\n
The Linux kernel’s netfilter subsystem \u2014 the thing behind iptables\/nftables \u2014 tracks every network flow it sees when stateful rules or NAT are in use. Each tracked connection consumes memory in the conntrack table. Two limits apply: the maximum number of entries ( Game traffic makes this worse than typical web traffic. UDP is stateless from the application’s perspective, but conntrack still tracks UDP “flows” with short timeouts, and game servers generate many short flows as players join, leave, and reconnect. A busy server legitimately holds thousands of entries at idle-plus-load. A flood can multiply that by ten in seconds.<\/p>\n\n\n\n Watch three signals together. Any one alone is ambiguous; together they identify table exhaustion.<\/p>\n\n\n\n If A common mistake is leaving the default table size, which on many distributions is sized for a workstation, not a game host. A rough formula: each active player can hold 5\u201320 tracked flows depending on how the game handles voice, matchmaking, and telemetry. Add headroom for legitimate reconnects and a flood buffer multiplier of 4\u20138x.<\/p>\n\n\n\n Persist these in Sizing the table is necessary but not sufficient. Add rate limits and SYN-flood protections so that a flood is absorbed rather than allowed to fill the table. A minimal iptables\/nftables posture:<\/p>\n\n\n\n On-box tuning handles connection exhaustion, but it cannot absorb volumetric floods \u2014 those must be scrubbed upstream before they reach your uplink. The best posture combines both: an always-on or on-demand scrubbing layer at the network edge, plus kernel hardening on the host so that what slips through degrades gracefully. Ask your provider whether filtering is always-on, how much it adds in latency when active, and whether it protects protocol-specific game ports. A host that treats DDoS protection as a configurable, documented service is far easier to defend with than one that just says “we have it.”<\/p>\n\n\n\n The combination you want is a well-managed network edge and a host you fully control underneath. If you are evaluating options, review dedicated and bare-metal hosting with DDoS mitigation<\/a> and confirm the mitigation model matches this layered approach before you commit. You can also pair this with the kernel and network tuning guidance<\/a> for the host itself.<\/p>\n\n\n\n Connection-table exhaustion is quiet, cheap to trigger, and easy to misdiagnose. With the right counters and a sized table, you turn a silent outage into a logged, survivable event.<\/p>\n","protected":false},"excerpt":{"rendered":" The attack that doesn’t look like an attack Most game server owners prepare for volumetric DDoS \u2014 a flood of gigabits that saturates the uplink. Modern attackers increasingly skip that….<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[14],"tags":[],"class_list":["post-1353","post","type-post","status-publish","format-standard","hentry","category-hardware-tuning"],"yoast_head":"\nnf_conntrack_max<\/code>) and the rate at which new entries can be created before the kernel gives up. When either is exceeded, the kernel drops new packets and logs nf_conntrack: table full, dropping packet<\/code>.<\/p>\n\n\n\nDetection: the numbers to watch<\/h2>\n\n\n\n
# Current entries vs maximum\nsysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max\n\n# Watch it during a suspected event\nwatch -n1 'sysctl -n net.netfilter.nf_conntrack_count'\n\n# Kernel drops and invalid packets\ndmesg | grep -i \"conntrack\\|nf_conntrack\"\nnstat -az | grep -i \"TcpExtListenDrops\\|TcpExtTCPAbortOnMemory\"<\/code><\/pre>\n\n\n\nnf_conntrack_count<\/code> creeps toward the maximum during “connection refused” complaints, and dmesg shows table-full messages, you have your answer. If instead the count is low but ListenDrops<\/code> is climbing, the issue is application-level accept queue overflow, a different problem with a different fix.<\/p>\n\n\n\nSizing the table for real player loads<\/h2>\n\n\n\n
# Example: raise the table and shorten idle timeouts\nnet.netfilter.nf_conntrack_max = 1048576\nnet.netfilter.nf_conntrack_tcp_timeout_established = 600\nnet.netfilter.nf_conntrack_udp_timeout = 30\nnet.netfilter.nf_conntrack_udp_timeout_stream = 60\n\n# Keep the hash table large enough to avoid collisions\nnet.netfilter.nf_conntrack_buckets = 262144<\/code><\/pre>\n\n\n\n\/etc\/sysctl.d\/<\/code> so they survive reboots and game server restarts. Shorter timeouts for finished connections are the cheapest defense: they free table entries faster under load without affecting active gameplay.<\/p>\n\n\n\nHardening the host against connection floods<\/h2>\n\n\n\n
net.ipv4.tcp_syncookies = 1<\/code>, plus a sensible tcp_max_syn_backlog<\/code>.<\/li>hashlimit<\/code> or nftables limit<\/code>, allowing bursts but capping sustained attempts.<\/li>conntrack --ctstate INVALID -j DROP<\/code> \u2014 so malformed packets never reach the game process.<\/li>Layered defense: on-box and upstream<\/h2>\n\n\n\n
A hardening checklist<\/h2>\n\n\n\n
nf_conntrack_count<\/code> at peak.<\/li>nf_conntrack_max<\/code> and buckets to match player count and headroom.<\/li>