Metin2 DDoS Protection: Firewall, Proxy and Mitigation

One of the most common reasons a private server goes down is not a code bug but an external attack, which is why a solid Metin2 ddos protection setup is something you should plan before launch, not after the first outage. A DDoS (distributed denial of service) attack floods your line or CPU with fake traffic from many sources, so legitimate players can no longer connect. Because the Metin2 architecture is made of several TCP services (auth, game/channel cores, db), protection is never a single tool but a layered defense: scrubbing at the network level, a firewall on the host, a proxy that hides the real IP, and flood control at the application layer.

Know the threat: attack types aimed at Metin2

To build the right defense you need to know where the attack lands. Attacks against Metin2 servers fall into roughly three groups:

• Volumetric attacks: UDP floods and amplification (DNS/NTP reflection) fill your line at the Gbps scale. The only realistic answer is an upstream scrubbing layer in front of the server; a single VPS's iptables cannot filter 50 Gbps, because the line is saturated before the traffic even reaches the box.
• Protocol attacks: SYN floods and ACK floods target the connection table (conntrack) and the TCP handshake. A large part of these can be mitigated with a firewall on the host.
• Application-layer attacks: constantly opening and closing TCP connections on the game or auth port, and login/register spam. These can keep the game core busy even at low bandwidth, so they need separate control.

The golden rule: volumetric attacks are stopped upstream, off the server; protocol and application attacks are filtered down on the host.

Separate the architecture: never expose auth and db

The cheapest way to shrink your attack surface is to open only the ports you truly need to the internet. In Metin2, only the game (channel) ports and the auth port need to be reachable from outside for a player to connect. The db (database cache) service, MySQL and the GM/web panels must stay closed to the outside world; reach them only over the local network or an SSH tunnel.

In practice this means setting the default policy to "deny everything" and opening only what you need:

# Linux / iptables — basic whitelist approach
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Open SSH only from your own IP
iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

# Ports open to players (example: auth + two channels)
iptables -A INPUT -p tcp --dport 11002 -j ACCEPT   # auth
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT   # ch1
iptables -A INPUT -p tcp --dport 13001 -j ACCEPT   # ch2

Port numbers vary with your own CONFIG files; the point here is not the port itself but the principle of "don't open it unless you need it."

Mitigating protocol attacks with the firewall

A host firewall cannot stop a volumetric attack, but it seriously thins out protocol attacks like SYN floods and connection floods. On Linux, the main measures with iptables are:

# Drop invalid packets
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Rate limit against SYN flood
iptables -A INPUT -p tcp --syn -m limit --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Limit simultaneous connections per IP (game port)
iptables -A INPUT -p tcp --dport 13000 \
  -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT

On top of this, enabling SYN cookies at the kernel level improves resilience to handshake floods: sysctl -w net.ipv4.tcp_syncookies=1. On classic FreeBSD setups, pf does the same job with a more readable syntax:

# FreeBSD / pf — rate and connection limit + automatic blacklist
table <abusers> persist
block in quick from <abusers>

pass in proto tcp to port 13000 keep state \
  (max-src-conn 30, max-src-conn-rate 10/5, \
   overload <abusers> flush global)

Here max-src-conn-rate 10/5 moves any IP that opens more than 10 new connections in 5 seconds into the abusers table and drops its existing connections too. This is quite effective against simple flood bots that connect and disconnect in rapid succession.

Hide the real IP: proxy / tunnel architecture

Attackers usually hit your server's IP directly; if you stop them from learning that IP, the volumetric attack loses its target. The approach is to separate the public IP that players see from the real (origin) server where the game core runs:

• A protected front end (proxy): you set up a TCP proxy or a GRE tunnel at a provider that scrubs DDoS (for example hosts that offer anti-DDoS such as OVH). Players connect only to this protected IP, and the proxy forwards traffic to the real backend server.
• Lock down the origin: the firewall on the real server must accept traffic to the game ports only from the proxy IP. This rule is critical, because the moment the origin IP leaks, the attack can target it directly.

For a simple TCP forwarder, HAProxy is a common choice:

# haproxy.cfg — forward auth and one channel to the backend
frontend ft_game
    mode tcp
    bind *:13000
    default_backend bk_game

backend bk_game
    mode tcp
    server core1 10.10.0.5:13000 check

On the origin side, trust only the proxy:

# Origin firewall: only the proxy IP may reach the game port
iptables -A INPUT -p tcp --dport 13000 -s 198.51.100.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 13000 -j DROP

One important caveat: behind a TCP proxy, a player's real IP appears at the backend as the proxy IP. If your ban/log system is IP based, consider PROXY protocol support to carry the real IP through; otherwise every player will look as if they come from a single IP.

Application layer: limit login and connection rate

Firewall and proxy filter network traffic, but the game core itself must also be protected against requests that "look valid" yet are malicious. Practical measures:

• Connections per second: if dozens of auth connections arrive from the same IP within seconds, slow them down with the connlimit/recent module.
• Login/register rate limit: cap the number of attempts per IP on the web register form and on the auth side; this stops early an attacker spawning a sea of accounts.
• Monitoring: watch for abnormal connection/bandwidth spikes with tools like ss -s, netstat -an | grep SYN_RECV | wc -l and vnstat; spotting an attack early shortens your reaction time.

Finally, remember to make your rules persistent with iptables-save / pfctl and to keep an emergency plan ready (temporarily closing a channel port during an attack, rotating the proxy IP).

Frequently Asked Questions

Can I stop a large DDoS with iptables on a single VPS?

No. Volumetric attacks (at the Gbps level) fill your line before reaching the server, while iptables only processes a packet once it arrives at the box. For such attacks you need a provider doing upstream scrubbing in front of the server, or an anti-DDoS proxy. iptables/pf are valuable for thinning out protocol and connection attacks.

Will a proxy increase player ping?

Because you route traffic through an intermediate hop, a small added latency is normal. To minimize it, place the proxy geographically close to both your players and the origin server; on a well-built tunnel the difference is usually a few milliseconds.

What should I do if my real IP leaks?

If you kept the origin firewall open only to the proxy IP, a leak alone does not make an attack easy, but the safest move is still to change the origin server's IP (get a new IP from the host) and reject all traffic arriving over the old one.

Want to set your server up correctly against attacks from day one? Let's plan the firewall, the proxy architecture and the Metin2-side configuration together — get in touch with me.