How to configure the firewall by port (game/connect/web) in MU Online

Configuring the firewall by port is one of the most important — and most poorly executed — tasks in administering a MU Online server. Many server owners simply turn off the entire firewall to "solve" a connection problem, and in doing so they throw SQL Server, the admin panel and internal services wide open to the whole internet. The result is predictable: hijacked accounts, a leaked database and a downed server. The correct approach is the opposite: deny everything by default and open only the ports that players and the site truly need. In this guide you will learn to separate ports into three groups — game, connect and web — and to create surgical rules in Windows Firewall that keep the server reachable while, at the same time, closed to what should not be exposed.

This tutorial assumes a Windows server (Windows Server 2016/2019/2022 or Windows 10/11 in a test environment) with a MuServer already installed. If you are still building the base of your project, start with the step-by-step guide on how to create a MU Online server and come back here once the processes are already starting up correctly.

Prerequisites

Before touching any rule, make sure you have:

• Administrator access to the server's Windows (an elevated PowerShell or Command Prompt).
• Alternative access to the server via the VPS provider's panel KVM/VNC console. This is non-negotiable: if you get a rule wrong and lose RDP, the console is the only way to recover access without calling support.
• The static IP of your admin computer (find it on sites like "what is my ip"). It will be used to restrict RDP.
• Your MuServer configuration files at hand, mainly the ConnectServer.ini and the GameServer definition file.
• A notepad to document each port before opening it.

Understanding the three port groups

The most common conceptual mistake is treating all ports the same. In practice, a MU server has ports with three very different purposes, and each group calls for a distinct policy.

Connect is the entry point. When the player opens the client, main.exe connects to the ConnectServer, receives the list of sub-servers and the IP/port of each one. This port needs to be open to the entire world, otherwise no one even sees the server selection screen.

Game are the sub-servers themselves. After choosing a server from the list, the client opens a new connection directly to the corresponding GameServer. Each sub-server usually has its own port. These also need to be public.

Web is the server's site/panel (account registration, ranking, donation shop). Exposure only exists here if the site is on the same machine as the game. It is the most sensitive group because it attracts application attacks (SQL injection, brute force on the admin login).

Beyond these three, there is a fourth group that should never be exposed: the internal ports (DataServer, JoinServer, EventServer) and SQL Server. They only talk within the machine itself.

Step 1: map your server's real ports

Do not trust numbers "from memory." Open the configuration files and note what is actually configured. The paths and names vary by provider/version of MuServer, but the logic is always the same.

In ConnectServer.ini (inside the ConnectServer folder, something like ConnectServer/Data/ConnectServer.ini) look for something like:

[ConnectServerInfo]
ConnectServerPortTCP = 44405
MaxUserCount = 1000

In the server list file that the Connect delivers to the client (often ServerList.dat or an equivalent .xml/.ini), check each GameServer's ports:

[Server1]
ServerName = ViciadosMU - Season 6
IP = 0.0.0.0
Port = 55901

[Server2]
ServerName = ViciadosMU - PvP
IP = 0.0.0.0
Port = 55902

Build a table like this with your values (the ones below are just examples and vary by provider/version):

Confirm which ports are actually listening with:

netstat -ano | findstr "LISTENING" | findstr "44405 55901 55902 1433 3389"

Step 2: set the default block policy

The correct security principle is default deny: block everything inbound and open only what is needed. Before applying it, create the RDP rule (Step 3, item 1) — but conceptually the policy comes first.

netsh advfirewall set allprofiles state on
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound

The first command ensures the firewall is on across all three profiles (Domain, Private, Public). The second sets the policy: block inbound, allow outbound.

Step 3: open the ports in the correct order

Follow this numbered order. It was designed so you never lock yourself out.

1. Open RDP only for your IP (replace 203.0.113.10 with your real IP):

netsh advfirewall firewall add rule name="ADMIN - RDP restrito" dir=in action=allow protocol=TCP localport=3389 remoteip=203.0.113.10

1. Open the ConnectServer (connect group) for everyone:

netsh advfirewall firewall add rule name="MU - ConnectServer 44405" dir=in action=allow protocol=TCP localport=44405

1. Open the GameServers (game group). One rule per port keeps the log more readable:

netsh advfirewall firewall add rule name="MU - GameServer 1 (55901)" dir=in action=allow protocol=TCP localport=55901
netsh advfirewall firewall add rule name="MU - GameServer 2 (55902)" dir=in action=allow protocol=TCP localport=55902

If you have many sub-servers in sequence, a range solves it:

netsh advfirewall firewall add rule name="MU - GameServers 55901-55910" dir=in action=allow protocol=TCP localport=55901-55910

1. Open the web group — only if the site is on the same machine:

netsh advfirewall firewall add rule name="WEB - HTTP 80" dir=in action=allow protocol=TCP localport=80
netsh advfirewall firewall add rule name="WEB - HTTPS 443" dir=in action=allow protocol=TCP localport=443

1. Explicitly block the internal ports and SQL from the internet. Since the policy is already block, this is redundant in theory, but an explicit block rule protects against future accidental openings and serves as documentation:

netsh advfirewall firewall add rule name="BLOCK - SQL 1433 externo" dir=in action=block protocol=TCP localport=1433
netsh advfirewall firewall add rule name="BLOCK - DataServer 55960 externo" dir=in action=block protocol=TCP localport=55960
netsh advfirewall firewall add rule name="BLOCK - JoinServer 55970 externo" dir=in action=block protocol=TCP localport=55970

Step 4: harden SQL Server at the service level

Blocking 1433 in the firewall is good, but defense in depth calls for binding SQL itself to the loopback. Open the SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → TCP/IP → IP Addresses tab. Keep enabled only the IPAll/IP1 that corresponds to 127.0.0.1 and disable the addresses pointing to the public IP. This way, even if someone opens 1433 by mistake, SQL will not be listening on the public interface.

Step 5: do the same thing through the graphical interface (optional)

If you prefer clicking to typing, run wf.msc and follow:

1. Inbound Rules → New Rule.
2. Type Port → TCP → enter the port (e.g. 44405).
3. Allow the connection.
4. Check all three profiles (Domain, Private, Public).
5. Give it a standardized name, like MU - ConnectServer 44405.

To restrict by IP (as with RDP), after creating the rule: right-click → Properties → Scope tab → under Remote IP address choose "These IP addresses" and add yours.

Step 6: test from the outside in

Testing from within the server itself is misleading, because local traffic does not pass through the same internet rules. Test from outside:

• Ask a friend (or use your phone on 4G, off the Wi-Fi) to open the client and check whether the server list loads (validates Connect) and whether they enter the world (validates Game).
• From another machine, confirm that 1433 is closed. A simple way in PowerShell:

Test-NetConnection -ComputerName YOUR_PUBLIC_IP -Port 1433

The expected result is TcpTestSucceeded : False. If it returns True, SQL is exposed — stop everything and fix it before moving on.

Common errors and fixes

Launch checklist

• All real ports mapped from the .ini files (not from memory)
• RDP rule restricted to my IP created before the general block
• Default policy set to blockinbound,allowoutbound
• ConnectServer opened to the internet
• Each GameServer with its own inbound rule
• Web ports (80/443) opened only if the site is on the same machine
• SQL (1433) and internal ports explicitly blocked
• SQL Server listening only on 127.0.0.1
• Test done from outside (phone/friend) validating Connect and Game
• Test-NetConnection confirming 1433 closed
• Backup of rules exported with netsh advfirewall export
• Provider's KVM/VNC access tested and working

With this per-group mapping, your server exposes exactly what players need and nothing beyond that. It is the security foundation on which you will later stack anti-flood, anti-DDoS and web panel hardening — but it all starts with knowing, precisely, which ports are open and why.

Frequently asked questions