Firewall rules for game servers: UDP is not TCP

Most firewall guides are written for web servers, where everything is TCP on two ports and the rules are obvious. Game servers are mostly UDP, often on several ports, with a query port that has to be open to strangers and an RCON port that must not be, and the differences are exactly where people get it wrong.

Open the query port, or be invisible

A game server answers two different kinds of traffic. Players connect on the game port. Listing sites, the in-game browser and monitoring tools ask on the query port.

Block the query port and the server works perfectly for anybody who already knows the address, and appears offline to everyone else. This is the single most common firewall mistake in game hosting, and it produces no error anywhere — the packets are simply dropped and the poller records a timeout.

If your server runs and nothing lists it, test the query port from outside before anything else. It is the same first step as any other connection that fails silently.

Close RCON, always

RCON is remote console. Whoever reaches it and has the password runs commands as the server.

It should not be open to the internet. Bind it to localhost and reach it over SSH, or restrict it by source address. Source engine RCON in particular has a long history of brute-force attempts against exposed ports, and the password is frequently the same one the owner uses elsewhere.

This is the highest-value single rule on the whole box and it takes one line. It belongs at the top of the security basics and is skipped because the panel opened the port for you and you never looked.

UDP has no connection to track

With TCP, a firewall follows the handshake and knows a connection exists. UDP has no handshake. The kernel's connection tracker invents a pseudo-connection per source and destination pair and expires it on a timer.

That has a consequence people meet during their first attack: a flood of UDP from spoofed addresses creates a tracked entry per source, the conntrack table fills, and the kernel starts dropping everything — including the traffic that is legitimate. The server is not overloaded. Its firewall is.

nftables documents the modern approach, and the relevant tool is rate limiting on the game port rather than a longer accept list. If you are still on iptables, the same idea is hashlimit.

The default-deny shape

A working ruleset for a game box is short:

• Accept established and related.
• Accept loopback.
• Accept SSH, ideally from known addresses only.
• Accept the game port and the query port.
• Rate limit new UDP on the game port.
• Drop everything else.

Six rules. The one people omit is the last, because a default-accept policy with a few blocks feels safer and is the opposite. Every service you later install is exposed by default under that policy, including the ones you did not know had opened a port.

IPv6 is a second firewall

This is the one that catches people who did everything else right. iptables and ip6tables are separate rulesets, and a box with an IPv6 address that only has IPv4 rules is wide open on the other protocol.

The failure is quiet in both directions. Your default-deny policy is not applied, so services you thought were closed are reachable; and your accept rules are not applied either, so a player connecting over IPv6 may be blocked while everyone else gets in. Both symptoms are hard to attribute because the server behaves correctly for the person testing it.

nft list ruleset shows both families at once, which is one of the better reasons to have moved. On iptables, checking one and assuming the other is the mistake.

Rate limiting without locking out your own players

The rule people write first is a hard cap on new connections per source address. On a game server that is usually wrong, because a household behind one NAT address is several legitimate players, and a school or a shared flat is more.

Two adjustments make it usable. Limit on new entries rather than on packets, so an established session is never affected by the limit. And set the burst high enough to survive the ordinary case of four people joining after a restart announcement, which is exactly when the server looks most like an attack.

The honest position is that a small server's firewall cannot stop a real flood: the traffic arrives on the provider's link and fills it before your kernel sees any of it. What the ruleset can do is stop the box falling over from bookkeeping, which is a different problem from absorbing the attack and the only half you control.

Do not use a firewall as a rate limiter for crawlers

Listing sites, monitoring services and search crawlers will hit your web presence, not your game port, and blocking them with a firewall rule is the wrong layer. It produces timeouts rather than an answer, and a timeout is indistinguishable from an outage to whatever is on the other end.

If something legitimate is too noisy, slow it down where it can be told it is being slowed down. A dropped packet teaches nobody anything.

Test from outside, not from the box

ss -lun on the server tells you what is listening. It tells you nothing about what the internet can reach, because the firewall sits between them and so, frequently, does your host's own network policy.

Use a machine that is not the server. A port that is open in your rules and closed at the provider's edge is a real and common arrangement, particularly on cheaper hosting, and it is worth confirming before concluding anything about what you are actually paying for.

The rule that outlives all of this

Write the ruleset into a file that survives a reboot, and put that file in version control alongside everything else about the server. A firewall configured by hand on a Tuesday is a firewall nobody can reconstruct after the box is rebuilt, and rebuilding is the moment you find out, which is precisely when a backup you have never restored from also turns out to have been theoretical.