Halloween at Nexthosting: 10% off game servers with the code – until November 1
Protect game servers with a hardened firewall based on nftables, a reverse proxy, provider-side DDoS protection and monitoring.
Go for defense in depth: a hardened host firewall with nftables, a reverse proxy or provider mitigation against volumetric attacks, and continuous monitoring of your network metrics. Together, these three layers form the minimum firewall for game servers that holds up today. UDP games such as Rust or FiveM need different rate limits than TCP-based servers such as Minecraft. The concrete rules and test steps follow in the next sections.
In short:
- An effective defense against volumetric attacks requires a combination of firewall, reverse proxy and provider mitigation in order to withstand even large attacks.
- nftables is essential for rule-based defenses on game servers, since it performs consistently with many entries and reacts quickly even to large threats.
- The configuration should include a safe recovery path up front so that you are never locked out by faulty rules, and it should always include a backup IP plan.
- At large volumes, local nftables rules alone are not enough; you need protection at the provider level through BGP FlowSpec or scrubbing centers.
- Managed hosting with DDoS protection already built in makes the most sense when your focus is on gameplay and community rather than firewall maintenance.
A layer 3/4 firewall filters by IP, port and protocol. It keeps the bulk of junk traffic out, but it cannot tell whether a UDP packet is a genuine game command or a manipulated attack packet with a valid header. This is exactly why a second layer is needed: layer 7 mechanisms inspect the content and detect game-specific patterns, such as malformed query requests or login floods.
For game servers, an architecture with a proxy frontend and a private backend has proven effective. The reverse proxy accepts all public traffic, while the actual game engine runs on an IP that nobody knows. Both sides are connected through a tunnel protocol such as WireGuard or GRE.
Pros and cons of the common options:
Before you write a single rule, you need a recovery path. Without out-of-band access through the server console, you risk locking yourself out with a faulty default rule. This is by far the most common mistake when setting up a firewall for the first time.
Here is how to proceed in a structured way:
Pro tip: Always keep a second, unpublished IP in reserve as a backup. During an ongoing attack, you can then move operations to the fallback IP while the attacker is still focused on the old address.
nftables has largely replaced iptables as the standard, and for good reason. It works with native sets and maps that keep constant speed even with thousands of IP entries, whereas iptables gets linearly slower with long rule chains. For a whitelist with hundreds of proxy addresses, this is not a nice-to-have but a necessity.
A simple, practical rule set for a game server behind a proxy looks like this:
| Rule | Purpose |
|---|---|
ct state established,related accept |
Let existing connections through without re-checking |
ip saddr @proxy_set tcp dport Port_for_Fivem accept |
Allow only listed proxy IPs to the game port |
udp dport Port_for_Fivem limit rate rate_per_second burst burst_packets accept |
Limit UDP packets per second |
tcp dport Port_for_SSH ct state new limit rate rate_limit accept |
Contain SYN floods on SSH |
policy drop |
Discard everything else by default |
The rate limiting syntax of nftables uses the keywords limit, rate, burst and over, which let you selectively drop packets above a threshold. For Minecraft servers, which run on TCP, a SYN limit via conntrack is also worthwhile because it catches classic connection floods. For UDP games such as Rust or FiveM, finer per-source limits are needed, otherwise you end up blocking regular players as well.
Fail2Ban complements the static rules by automatically and temporarily banning repeated failed attempts on admin panels or console ports. Important for containerized setups: nftables or ip6tables rules must go into the DOCKER-USER chain, otherwise Docker bypasses your firewall entirely and forwards packets directly.
policy drop change through the console first, never exclusively over SSH.Pro tip: Never roll out new rule sets directly on the live server. A quick test on a second VPS reveals errors before real players are affected.
Your nftables rules run in the kernel and are fast, but they only take effect once the packet has already reached your server. In a large volumetric attack, the line itself is the problem, not the CPU. As soon as the uplink is saturated, local drop rules no longer help, because the junk traffic clogs the bandwidth before it even gets to your server.
From this point on, you need mitigation at the provider level. A reverse proxy concept modeled on well-known game hosters filters the traffic before it even reaches your data center. An automated escalation chain makes sense:
Automated escalation pays off because too much time is often lost between detection and manual response, especially at night or on weekends. In addition, larger setups use GRE tunnels to scrubbing providers, multiple IP pools for load distribution and DNS rotation to quickly switch to an unaffected address during an ongoing attack. For a Rust server with a public community, this escalation chain is often relevant from the first month, not only with thousands of players.
A firewall without monitoring is only half the protection. Continuously monitor at least four metrics: packets per second, actual bandwidth usage, the number of open conntrack entries and error rates on player connections. A sudden jump in PPS without a corresponding increase in players is almost always an early warning sign.
Here is how to test a new configuration before it goes live:
After every incident, a short post-mortem is worthwhile: what triggered it, which rule took effect, what was missing. The BSI IT-Grundschutz recommendations on firewalls call for exactly this documented accountability for every rule, and that is not mere bureaucracy but the only way to understand what happened after an attack.
After years of working with game server setups, a pattern emerges: most operators overestimate their host firewall and underestimate the uplink. A perfectly configured nftables rule set does little good if the line is clogged beforehand. Many community admins invest hours in fine-tuning rules, while the real weak point is the lack of provider mitigation.
Some hosting providers offer DDoS protection and managed game servers so that operators do not have to deal with GRE tunnels or BGP FlowSpec themselves. Managed hosting makes the most sense when you would rather put your time into the player experience than into firewall maintenance at midnight. If you want to keep full control over your own rules, a VPS gives you enough room to combine both worlds.
— Erik
There are good reasons to write every firewall rule yourself, but not every operator has the time or the patience for it. Some providers offer servers with included DDoS protection at no extra cost, running in German data centers and managed through clear control panels, instead of maintaining every rule manually. Support often works directly within the team rather than in an anonymous queue.
For Minecraft, FiveM or Garry’s Mod, this means: you start the server, the basic protection is already running, and you take care of your community instead of conntrack tables. If you need full control over your own nftables rules instead, a VPS Standard is the right foundation. Take a look at the available game server plans and get started in a few minutes with a protected setup.
A distinction is usually made between packet-filtering firewalls, which decide by IP and port, stateful firewalls, which track the connection state, and application-layer firewalls, which inspect the content of a packet. For game servers, a combination of a stateful host filter and layer 7 protection is common practice, as OVHcloud also describes in its game firewall documentation.
A configuration that is too restrictive can block legitimate players, especially in UDP games with many short packets. In addition, a host firewall alone does not protect against volumetric attacks that saturate the uplink, which is where provider-level mitigation becomes necessary.
Yes, a host firewall is the foundation of any protection and can be configured directly on the server with nftables. However, it does not replace provider-level mitigation for larger attack volumes.
It typically blocks unknown IP addresses outside a proxy whitelist, excessive packet rates per second and repeated failed attempts on admin ports. A well-configured policy drop rule also discards, by default, all traffic that has not been explicitly allowed.
For small community servers, a solid host firewall is often enough. As soon as the server is publicly advertised or has a larger player base, additional protection is worthwhile, such as Nexthosting already includes with its game server plans.