DDoS Protection for Game Servers: UDP Floods and Latency

DDoS protection for game servers works best as a layered setup. Detect attacks from flow data per destination IP, drop only traffic that a game host never needs, and send the rest through a scrubbing path that does not add much latency. Generic firewall rules and blanket rate limits usually stop the attack by also stopping your players.

This article is for hosting and data center engineers who run game nodes (Minecraft, Source-engine, FiveM, Rust and similar) and need protection that keeps ping stable.

Why game traffic is hard to protect

Game servers are a bad fit for generic DDoS filtering for a few reasons:

• UDP dominates. There is no handshake to validate, and source addresses can be spoofed.
• Small packets, high pps. A healthy server has a pps-heavy profile, so a bps threshold alone is misleading.
• Legitimate sources are unpredictable. Players come from residential ISPs and mobile networks worldwide. Allow-lists and geo-blocks cut off real users.
• Latency and jitter matter more than throughput. A 40 ms detour or a burst of drops is a visible problem even if the link never saturates.
• Attackers know the protocols. Some floods mimic valid handshakes or query packets, so simple signature filters do not catch them.

Common attacks against game hosts

For the reflection signatures in more depth, see our post on UDP amplification attacks. For the prefix-wide pattern, see the carpet bombing article. Both are common against game hosting ranges because attackers often do not know which IP holds the target server.

Why generic filters break games

Per-source UDP rate limits. Players behind carrier-grade NAT share one public IP. A limit that looks reasonable per IP will drop a whole group of players at once.

Stateful firewall in the path. Connection tracking on a UDP flood fills the state table. Once the table is full, legitimate sessions fail. For game ranges, prefer stateless filtering at the edge router.

Blocking all fragments blindly. Dropping non-first fragments is usually safe for game traffic. Dropping all UDP above a small packet size is not, because some games send larger state updates or voice data.

Geo-blocking. It helps against some botnets and hurts diaspora players, VPN users, and anyone on a mobile network that geolocates wrongly.

RTBH as the first reaction. A blackhole removes the victim IP from the internet. It protects the rest of your network, but the attacker gets what they wanted for that IP. Use it as a last resort, per /32, and prefer targeted FlowSpec or scrubbing first.

Step 1: detect per IP with pps-aware thresholds

Export flows from your edge routers (NetFlow v5/v9, IPFIX, or sFlow) to a collector. For game hosting, set thresholds per destination IP and per prefix:

1. Record a baseline of pps and bps per game node during peak hours.
2. Set a pps threshold above the peak baseline, and a separate bps threshold.
3. Add a prefix-level threshold for carpet bombing, because each single IP may stay under its own limit.
4. Alert on UDP-specific signals, such as a spike in packets from reflection source ports.

Sampling matters. At 1:1000 sampling you will see large floods fast but may miss small, targeted attacks. See our guides on NetFlow thresholds and baselines and on choosing between sFlow, NetFlow and IPFIX.

Step 2: drop what a game host never needs

Game servers rarely need inbound UDP from well-known reflection source ports. Your own DNS and NTP resolvers are the exception, so accept them first. Here is an nftables example for a Linux router in front of 192.0.2.0/24:

table inet gamefw {
  chain forward {
    type filter hook forward priority 0; policy accept;

    # your own resolvers/time servers first
    ip saddr 198.51.100.53 accept

    # reflection source ports aimed at the game range
    ip daddr 192.0.2.0/24 udp sport { 19, 123, 161, 1900, 11211 } drop

    # non-first fragments
    ip daddr 192.0.2.0/24 ip frag-off & 0x1fff != 0 drop
  }
}

The equivalent on MikroTik RouterOS, in the raw table so it bypasses connection tracking:

/ip firewall raw
add chain=prerouting action=drop protocol=udp \
    src-port=19,123,161,1900,11211 \
    dst-address=192.0.2.0/24 in-interface-list=WAN \
    comment="reflection to game range"

On Juniper, the same logic fits a firewall filter applied on the upstream-facing interface:

set firewall family inet filter GAME-EDGE term REFL from destination-address 192.0.2.0/24
set firewall family inet filter GAME-EDGE term REFL from protocol udp
set firewall family inet filter GAME-EDGE term REFL from source-port [ 19 123 161 1900 11211 ]
set firewall family inet filter GAME-EDGE term REFL then count reflection-drop
set firewall family inet filter GAME-EDGE term REFL then discard
set firewall family inet filter GAME-EDGE term REST then accept

If the same match needs to happen upstream, or across many routers, announce it as a BGP FlowSpec rule instead of touching each box. Read the FlowSpec safety guide first. Always set a rate-limit or a short expiry while you test a new rule.

Step 3: use scrubbing when the flood is bigger than your edge

Filters on your own routers do not help when the uplink itself is full. At that point you need the traffic cleaned before it reaches you. A tunnel-based service does this:

1. Your prefixes are announced from the scrubbing edge.
2. Attack traffic is filtered there.
3. Clean traffic comes back over a GRE tunnel, with a BGP session inside the tunnel.

NixGuard Edge works this way. It is for networks with their own ASN and at least one /24. You can run it always-on or on-demand, and the customer AS-SET can be used for prefix filtering. The mechanics are covered in our posts on GRE clean traffic delivery and the GRE + BGP config guide.

Always-on vs on-demand for games

• Always-on keeps your prefix behind the scrubbing edge all the time. There is no convergence delay when an attack starts, and no gap while you detect. The cost is that all inbound traffic takes the scrubbing path, so check how far that is from your players.
• On-demand keeps normal traffic on your direct transit path and diverts only during an attack. Latency is best the rest of the time. The tradeoff is the detection time and BGP propagation delay before protection begins, which players may notice as a short disruption.

Many game hosts pick on-demand for regions where their transit is close to players, and always-on for prefixes that get attacked constantly.

Step 4: protect latency inside the tunnel

GRE adds 24 bytes of overhead (20-byte outer IP header plus 4-byte GRE header). With a 1500-byte path MTU, the tunnel MTU is 1476. Game packets are usually small, but TCP sessions for web panels, downloads or APIs can stall if MTU is wrong. Set it explicitly. A Cisco IOS example:

interface Tunnel100
 ip address 203.0.113.2 255.255.255.252
 tunnel source 198.51.100.10
 tunnel destination 198.51.100.1
 ip mtu 1476
 ip tcp adjust-mss 1436
!
router bgp 64496
 neighbor 203.0.113.1 remote-as 64511
 neighbor 203.0.113.1 description scrubbing-edge
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor 203.0.113.1 activate

(Addresses and ASNs here are documentation placeholders.) Other things that protect latency:

• Check where the scrubbing edge is relative to your players and to your servers. Path stretch adds a fixed delay.
• Confirm how return traffic is routed, and verify with traceroute and in-game ping before and after.
• Do not run a stateful firewall or heavy NAT inside the tunnel path for game traffic.
• Monitor jitter and loss on the tunnel interface, not only bandwidth.

Common mistakes

• Setting only bps thresholds, so a small-packet flood goes unnoticed until the CPU on a game node is gone.
• Blocking UDP source port 53 or 123 without allowing your own resolvers and time servers.
• Using a per-source rate limit that drops players behind CGNAT.
• Blackholing a game IP automatically on any spike, with no review of what triggered it.
• Forgetting IPv6. Apply the same filters and detection to your 2001:db8::/32 style prefixes.
• Never testing the tunnel failover. Run a drill with on-demand diversion before you need it.

Where NixMon fits

NixMon analyzes NetFlow v5/v9, IPFIX and sFlow with sub-second analytics, and applies per-IP and per-prefix bps/pps thresholds. When a threshold trips, it can announce a BGP blackhole or FlowSpec rule, trigger the on-prem NixGuard firewall, or divert to NixGuard Edge for scrubbing over a GRE/BGP tunnel. Attack alerts reach you on the native iOS and Android apps, and a WHMCS integration and white-label mode help hosting providers. You can test it with a 15-day free trial, with no credit card required.