How to segment your GameServer network to protect your MU Online server

A typical private MU Online server unknowingly exposes far more than it should: it's common to see the GameServer, ConnectServer, database, and even the admin web panel all running on the same flat network, all reachable from the internet on the same ports. This turns any vulnerability in one component into an entry point for all the others. Segmenting the network — isolating each component in its own zone, with explicit firewall rules about who can talk to whom — is one of the most effective and least applied security measures among private server administrators. This tutorial shows how to plan and implement that segmentation, from topology design to specific firewall rules.

Why a flat network is a risk

On a flat network, if an attacker compromises the web server (usually the most exposed and most attacked component, since it runs a CMS or PHP panel), they gain direct network access to the database and the GameServer, because there's no barrier between them. A vulnerability in a login form on the site becomes, within a few steps, a full dump of the accounts and items database. Network segmentation breaks this chain: even if one component is compromised, the attacker can't "jump" laterally to the others without passing through an explicit firewall rule.

Typical MU server components and their ideal exposure

The general rule: only the ConnectServer and the site need to be directly reachable from the internet. Everything else should live behind a firewall that blocks by default and opens only what's necessary.

Designing the network segments

A reference topology with three segments:

[ Internet ]
     |
[ Public Segment ]  -- ConnectServer, Site/Web Panel
     |  (rule: only specific ports opened)
[ Application Segment ]  -- GameServer, DataServer
     |  (rule: only GameServer talks to the database)
[ Database Segment ]  -- MSSQL/MySQL

Each arrow represents an explicit firewall rule, not an open path. Traffic between segments should be a documented exception, never the default.

Implementing with VPC and Security Groups (cloud)

If the server runs on a cloud provider (AWS, Azure, GCP, or local providers with VPC), segmentation is done via private subnets and security groups. An example VPC structure:

VPC: 10.0.0.0/16
├── Public Subnet:      10.0.1.0/24  → ConnectServer, Site
├── Application Subnet: 10.0.2.0/24  → GameServer, DataServer
└── Database Subnet:    10.0.3.0/24  → MSSQL/MySQL

The ConnectServer in the public subnet has an internet-reachable IP (or sits behind a Load Balancer); the GameServer and database live in private subnets, with no direct route to the internet, reachable only via internal IP.

Firewall rules per segment

The table below summarizes the minimum required rules between segments:

Note that the site has its own path to the database, ideally with a database account with restricted permissions (only SELECT on ranking tables, never UPDATE/DELETE).

Configuring with iptables (dedicated Linux server)

If the components run on your own Linux servers (not managed cloud), iptables or nftables serve the same purpose. An example set of rules on the database server, accepting connections only from the GameServer's internal IP:

# Default policy: block everything
iptables -P INPUT DROP

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow only the GameServer on the MySQL port
iptables -A INPUT -p tcp -s 10.0.2.10 --dport 3306 -j ACCEPT

# Allow SSH only from a known management IP
iptables -A INPUT -p tcp -s 198.51.100.5 --dport 22 -j ACCEPT

# Log and drop the rest
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROPPED: "
iptables -A INPUT -j DROP

Save the rules with iptables-save and make sure they're restored on boot, or a reboot leaves the server unprotected.

Isolating the admin web panel

The admin panel (where GMs manage accounts, items, events) is a particularly sensitive target — it usually has direct write permissions to the database. Never expose it on the same public URL/port as the player-facing site. Recommendations:

• Put the panel on a separate subdomain or port, protected by VPN or an allowed-IP list.
• Use two-factor authentication for admin accounts.
• Restrict the database account used by the panel to only the strictly necessary tables.

Segmenting the management network too (SSH/RDP)

A common mistake is segmenting the game services well but leaving administrative access (SSH, RDP, hosting panels) open to the internet without restriction. Treat management access as another segment: allow SSH/RDP only from an admin VPN or a fixed list of trusted IPs, never 0.0.0.0/0.

Monitoring and auditing the rules

Segmentation without monitoring is a false sense of security. Set up firewall logs (blocks and allows) and review periodically:

Testing the segmentation

After implementing it, actively validate that segmentation works as expected by attempting connections that should fail:

1. From the public internet, try connecting directly to the database port — it should fail (timeout or connection refused).
2. From the public segment (ConnectServer), try connecting to the database port — it should fail, since only the GameServer has permission.
3. From the GameServer, confirm the connection to the database works normally.
4. Run a port scanner (nmap) from outside the network against the public IP — confirm only the expected ports (ConnectServer, site) show as open.

Common errors and fixes

Network segmentation checklist

• Segment topology designed (public, application, database).
• Only ConnectServer and site directly exposed to the internet.
• Explicit firewall rules by source/destination/port, block by default.
• Admin panel isolated with VPN or IP list and 2FA.
• Management access (SSH/RDP) restricted to VPN or trusted IPs.
• Firewall rule persistence configured (survives reboot).
• Active segmentation tests performed (connection attempts that should fail).
• Firewall monitoring and logs configured with periodic review.

With the GameServer network properly segmented, the logical next step is to apply the same rigor to the data layer — see the database network segregation tutorial to dig deeper into protecting the most sensitive component of the entire server.

Frequently asked questions