Top 10 essential nftables rules for a production game server

Deploying robust nftables rules game server configurations has become essential in 2026 as volumetric attacks and sophisticated exploits continue to evolve. This guide presents ten proven nftables rule patterns tailored for game server environments, combining stateful connection tracking with precise rate-limiting to protect your infrastructure while maintaining legitimate player access.

Modern game server protection demands kernel-level efficiency paired with intelligent packet filtering. While XDP handles the initial stateless line of defense, nftables provides the stateful layer necessary for TCP handshake validation, per-connection rate-limiting, and protocol enforcement that game traffic requires.

Understanding nftables Architecture for Game Servers

The nftables framework replaced the legacy iptables infrastructure, offering improved performance through better kernel integration and a unified syntax for IPv4 and IPv6. For game servers, the critical advantage lies in stateful connection tracking (conntrack) combined with the meter primitive for dynamic rate-limiting.

Unlike stateless XDP programs that inspect every packet in isolation, nftables maintains connection state tables. This allows validation of TCP three-way handshakes, detection of incomplete connections, and enforcement of proper protocol sequences—capabilities essential for filtering SYN floods, ACK floods, and other stateful attacks that bypass simple packet filters.

A properly isolated nftables configuration uses the inet family in a dedicated table. For instance, PAKKT deploys an inet pakkt table that coexists with Docker's nat table, fail2ban rules, and iptables-persistent configurations without conflict. This architectural separation ensures game server protection layers don't interfere with container networking or existing firewall policies.

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority filter \; policy accept \; }
nft add chain inet pakkt forward { type filter hook forward priority filter \; policy accept \; }

The priority filter directive places these chains at the standard filtering stage, after connection tracking but before NAT processing. This timing is crucial for game servers: conntrack state is available for validation, but legitimate traffic isn't yet blocked by overly aggressive early-stage rules.

Top 10 nftables Rules Every Game Server Needs

1. Connection State Validation

The foundation of any nftables rules game server ruleset is proper connection state handling. This rule accepts established connections and related packets (like ICMP error messages for active UDP sessions) while allowing new inbound connections to proceed to subsequent rules for evaluation.

nft add rule inet pakkt input ct state established,related accept
nft add rule inet pakkt input ct state invalid drop

The invalid state catch includes malformed packets, out-of-window TCP segments, and packets that don't match any known connection. Dropping these immediately saves CPU cycles on deeper inspection and blocks numerous reconnaissance techniques.

2. SYN Flood Protection with Rate-Limiting

TCP SYN floods exhaust server connection tables by initiating thousands of half-open connections. This rule employs a meter to track new connection attempts per source IP, limiting each to 20 SYN packets per second with a burst allowance of 50.

nft add rule inet pakkt input tcp flags syn tcp dport 25565 \
  meter syn_limit { ip saddr limit rate 20/second burst 50 packets } accept
nft add rule inet pakkt input tcp flags syn tcp dport 25565 drop

The first rule creates a dynamic set keyed by source IP (ip saddr). Sources exceeding the limit fall through to the drop rule. The burst parameter accommodates legitimate client reconnection bursts after network interruptions—common in mobile gaming scenarios.

3. UDP Amplification Defense

Game servers using UDP protocols (Minecraft Bedrock, FiveM, Rust) face reflection attacks exploiting query protocols. This rule limits new UDP sessions per source, preventing attackers from establishing thousands of fake sessions for amplification.

nft add rule inet pakkt input udp dport 19132 ct state new \
  limit rate 50/second burst 100 packets accept

The ct state new qualifier means established UDP "connections" (tracked flows in conntrack) pass without limit check. Only the first packet of each new flow consumes limit quota, allowing legitimate players to sustain high packet rates once connected.

4. ICMP Rate-Limiting

ICMP echo requests serve legitimate diagnostic purposes but also enable ping floods and reconnaissance. This rule permits essential ICMP types while rate-limiting echo requests.

nft add rule inet pakkt input icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
nft add rule inet pakkt input icmp type echo-request limit rate 5/second accept
nft add rule inet pakkt input icmp type echo-request drop

The first rule unconditionally accepts ICMP types required for proper TCP/IP operation—blocking these breaks Path MTU Discovery and causes silent connection failures. Echo requests receive a modest 5 pps limit sufficient for monitoring tools but inadequate for flooding.

5. Port-Specific Connection Limits

Beyond rate-limiting packets, limiting simultaneous connections per IP prevents resource exhaustion. This rule restricts each source to 10 concurrent connections on the game server port.

nft add rule inet pakkt input tcp dport 25565 \
  meter connlimit { ip saddr ct count over 10 } reject with tcp reset

The ct count function tallies active conntrack entries for each source IP. Exceeding the threshold triggers tcp reset, cleanly terminating the attempt rather than silently dropping packets. This helps legitimate clients distinguish between filtering and network failures.

6. Fragment Attack Mitigation

IP fragmentation attacks exploit reassembly logic to bypass filters or crash systems. Modern game servers rarely require fragmented packets; legitimate game traffic typically fits within standard MTUs.

nft add rule inet pakkt input ip frag-off & 0x1fff != 0 drop

This rule drops any fragment except the first (offset 0). The bitmask 0x1fff isolates the fragment offset field, ignoring the reserved and DF/MF flag bits. First fragments pass through for normal processing; subsequent fragments—rarely legitimate—are dropped.

7. Invalid TCP Flag Combinations

Certain TCP flag combinations never occur in legitimate traffic. Attackers use them for firewall probing (NULL scan, XMAS scan) or exploit attempts.

nft add rule inet pakkt input tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 drop
nft add rule inet pakkt input tcp flags & (fin|syn) == (fin|syn) drop
nft add rule inet pakkt input tcp flags & (syn|rst) == (syn|rst) drop

The first rule blocks NULL scans (no flags set). The second blocks SYN+FIN (invalid handshake). The third blocks SYN+RST (contradictory semantics). These patterns have no legitimate use and frequently indicate automated scanning tools.

8. Geo-Based Rate Differentiation

When your player base concentrates in specific regions, applying stricter limits to distant sources reduces attack surface. This example uses nftables sets populated by external scripts.

nft add set inet pakkt trusted_countries { type ipv4_addr \; flags interval \; }
nft add rule inet pakkt input ip saddr @trusted_countries accept
nft add rule inet pakkt input tcp dport 25565 ct state new limit rate 10/second accept

Traffic from the trusted_countries set bypasses the stricter 10 pps limit applied to other sources. The set supports CIDR ranges (flags interval), allowing efficient storage of regional IP blocks. PAKKT.io automates this pattern through dual-layer IP whitelist synchronization between XDP maps and nftables sets.

9. Application-Layer Packet Size Validation

Game protocols typically enforce packet size boundaries. Oversize packets often indicate exploit payloads; undersize packets suggest scanning or protocol abuse.

nft add rule inet pakkt input udp dport 19132 udp length < 10 drop
nft add rule inet pakkt input udp dport 19132 udp length > 1400 drop

This example enforces 10–1400 byte bounds for Minecraft Bedrock traffic. Minimum size blocks empty probes; maximum size prevents fragmentation-based attacks. Adjust thresholds based on your specific game protocol specifications.

10. Logging Suspicious Activity

Strategic logging captures attack patterns for analysis without overwhelming disk I/O. This rule logs dropped SYN packets exceeding rate limits, prefixing entries for easy filtering.

nft add rule inet pakkt input tcp flags syn tcp dport 25565 \
  limit rate 10/minute log prefix \"[nft-syn-drop] \" drop

The limit rate 10/minute applied to the log action—not the drop—prevents log flooding during large attacks. The prefix enables grep/awk filtering in syslog. Logs appear in /var/log/kern.log or journal, depending on your distribution's syslog configuration.

Integrating nftables with XDP for Layered Defense

While these nftables rules game server configurations provide robust stateful protection, they operate after packet reception and initial kernel processing. For volumetric attacks exceeding several hundred thousand packets per second, nftables CPU overhead becomes measurable.

XDP (eXpress Data Path) programs execute directly in the network driver, inspecting packets before sk_buff allocation. This placement enables sub-microsecond per-packet processing, dropping malicious traffic with minimal CPU impact. However, XDP is stateless—it cannot validate TCP handshakes or track connection counts.

The optimal architecture combines both: XDP filters by IP blacklist, port ranges, packet size, and simple rate-limits (packets per second per source), dropping the bulk of attack traffic at line rate. Packets passing XDP proceed to nftables for stateful validation, connection limiting, and protocol enforcement.

PAKKT Integrations (Pterodactyl, public API) implement this dual-layer model through a single XDP program per interface supporting up to 256 concurrent rules driven by BPF maps, complemented by an isolated inet pakkt nftables table. Configuration changes update both layers atomically, maintaining consistent protection policy across stateless and stateful stages.

# XDP blocks by IP and enforces global pps limits
ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp

# nftables adds stateful validation and per-connection limits
nft -f /etc/nftables/pakkt.conf

This layered approach means a 10 Gbps SYN flood hitting your game server consumes minimal CPU: XDP drops packets from blacklisted sources and enforces global pps caps in the driver; remaining packets undergo nftables' per-IP SYN rate-limiting and connection tracking. Legitimate players experience negligible added latency while attack traffic is efficiently discarded.

Operational Best Practices for Production Deployment

Deploying these rules in production requires careful testing and monitoring to avoid blocking legitimate traffic. Start with log actions instead of drop, analyzing logs to tune thresholds before enforcement.

Use atomic ruleset replacement rather than incremental rule additions. Write your complete configuration to a file, then load it atomically:

nft -f /etc/nftables/pakkt.conf

This approach prevents inconsistent intermediate states during updates. If syntax errors exist, the old ruleset remains active. Enable nftables persistence through your distribution's service manager to survive reboots.

Monitor conntrack table utilization with conntrack -C and sysctl net.netfilter.nf_conntrack_count. If legitimate traffic approaches nf_conntrack_max, increase the limit or tighten per-IP connection limits to free entries. Connection table exhaustion causes silent packet drops—difficult to diagnose without monitoring.

For multi-server deployments, maintain version-controlled ruleset templates with environment-specific variables (port numbers, IP ranges). This enables consistent policy across your infrastructure while accommodating per-server customization. PAKKT Blog documents template management patterns for XDP and nftables rules shared across agent fleets.

Test failover scenarios: if your configuration management tool fails, do protection rules remain active? Service persistence and local file backups ensure your game servers retain protection even when central management is unreachable.

Performance Considerations and Tuning

nftables performance scales with ruleset size and complexity. Rules evaluated per packet determine CPU cost; minimize this through early accept/drop decisions and set-based matching rather than long linear chains.

The meter primitive maintains dynamic state, consuming memory proportional to unique key count (typically source IPs). A /24 subnet contributes 256 entries; a reflection attack from spoofed sources across the IPv4 space can exhaust memory. Combine meter-based rate-limiting with upstream XDP blacklisting of obviously spoofed sources (RFC 1918 private IPs on public interfaces, your own IP space).

Connection tracking imposes CPU overhead for state table updates and memory for conntrack entries. Each TCP connection consumes approximately 300 bytes; each tracked UDP flow about 200 bytes. A server handling 100,000 concurrent connections requires roughly 30 MB for conntrack tables alone. Monitor /proc/net/nf_conntrack and tune nf_conntrack_max based on observed legitimate connection counts plus headroom.

For game servers with extremely high packet rates (Minecraft networks with thousands of concurrent players), profile your ruleset with perf to identify bottlenecks:

perf record -g -a sleep 30
perf report

Look for time spent in nft_ kernel functions. If nftables processing appears costly, consider moving simple filters (port-based drops, IP blacklist checks) into the XDP layer where per-packet cost is an order of magnitude lower.

Conclusion

Implementing these ten nftables rules game server patterns establishes a robust stateful filtering layer that complements XDP's high-performance stateless protection. Connection state validation, intelligent rate-limiting, and protocol enforcement stop sophisticated attacks while preserving legitimate player access. Regular monitoring and threshold tuning ensure your protection adapts to evolving traffic patterns, maintaining both security and performance as your player base scales.

FAQ

Can nftables alone protect my game server from large DDoS attacks?

nftables provides essential stateful filtering but processes packets after kernel reception, making it CPU-intensive under multi-million pps volumetric attacks. Pair nftables with XDP for stateless early-stage filtering at line rate, dropping the bulk of attack traffic before it reaches stateful processing. For attacks exceeding your server's network interface capacity, upstream scrubbing from your hosting provider becomes necessary as kernel-level protections cannot filter traffic that saturates the physical link.

How do I determine the correct rate-limit thresholds for my specific game?

Monitor legitimate traffic during peak hours using nft list ruleset -a with counter rules on your game ports. Observe packets per second per connection and concurrent connection counts from known-good players. Set thresholds 2–3× higher than observed legitimate peaks to accommodate bursts during events or updates. Log violations before enforcing drops, analyzing whether blocked IPs correspond to real players or attack sources. Iteratively tune based on false positive reports from your community.

Do these nftables rules interfere with Docker containers or existing iptables configurations?

Using a dedicated inet pakkt table with explicit chain priorities prevents conflicts with Docker's nat table, fail2ban rules in the filter table, and iptables-persistent configurations. nftables and iptables coexist through the xtables compatibility layer, but avoid mixing rule management tools on the same table. Keep game server protection rules isolated in their own nftables table, allowing container networking and other firewall functions to operate independently in separate tables with different hook priorities.