Cómo configurar el firewall por puerto (game/connect/web) en MU Online

Configurar el firewall por puerto es una de las tareas más importantes — y peor ejecutadas — en la administración de un servidor de MU Online. Muchos dueños de servidor simplemente apagan el firewall entero para "resolver" un problema de conexión, y con eso dejan abiertos de par en par el SQL Server, el panel administrativo y los servicios internos a toda internet. El resultado es previsible: cuentas invadidas, base de datos filtrada y servidor caído. El enfoque correcto es el opuesto: negar todo por defecto y liberar solo los puertos que los jugadores y el sitio realmente necesitan. En esta guía vas a aprender a separar los puertos en tres grupos — game, connect y web — y a crear reglas quirúrgicas en el Windows Firewall que mantienen el servidor accesible y, al mismo tiempo, cerrado para lo que no debe exponerse.

Este tutorial asume un servidor Windows (Windows Server 2016/2019/2022 o Windows 10/11 en entorno de pruebas) con un MuServer ya instalado. Si todavía estás montando la base de tu proyecto, empieza por el paso a paso de cómo crear un servidor de MU Online y vuelve aquí cuando los procesos ya estén levantando correctamente.

Requisitos previos

Antes de tocar cualquier regla, asegúrate de tener:

• Acceso administrador al Windows del servidor (PowerShell o Símbolo del sistema elevado).
• Acceso alternativo al servidor vía consola KVM/VNC del panel del proveedor de VPS. Esto es innegociable: si te equivocas en una regla y pierdes el RDP, la consola es la única forma de recuperar el acceso sin llamar al soporte.
• La IP fija de tu computadora de administración (averíguala en sitios como "mi ip"). Se usará para restringir el RDP.
• Los archivos de configuración de tu MuServer a mano, principalmente el ConnectServer.ini y el archivo de definición de los GameServers.
• Un bloc de notas para documentar cada puerto antes de liberarlo.

Entendiendo los tres grupos de puertos

El error conceptual más común es tratar todos los puertos por igual. En la práctica, un servidor de MU tiene puertos con tres finalidades muy diferentes, y cada grupo pide una política distinta.

Connect es el punto de entrada. Cuando el jugador abre el cliente, el main.exe conecta al ConnectServer, recibe la lista de sub-servidores y el IP/puerto de cada uno. Ese puerto necesita estar abierto para el mundo entero, si no, nadie llega siquiera a ver la pantalla de selección de servidor.

Game son los sub-servidores propiamente dichos. Después de elegir el servidor en la lista, el cliente abre una nueva conexión directa al GameServer correspondiente. Cada sub-servidor suele tener su propio puerto. También necesitan estar públicos.

Web es el sitio/panel del servidor (registro de cuenta, ranking, tienda de donación). Solo hay exposición aquí si el sitio está en la misma máquina del juego. Es el grupo más sensible porque atrae ataques de aplicación (SQL injection, fuerza bruta en el login del admin).

Además de esos tres, existe un cuarto grupo que nunca debe exponerse: los puertos internos (DataServer, JoinServer, EventServer) y el SQL Server. Ellos conversan solo dentro de la propia máquina.

Etapa 1: mapear los puertos reales de tu servidor

No confíes en números "de memoria". Abre los archivos de configuración y anota lo que está realmente configurado. Las rutas y nombres varían por proveedor/versión de MuServer, pero la lógica es siempre la misma.

En el ConnectServer.ini (dentro de la carpeta del ConnectServer, algo como ConnectServer/Data/ConnectServer.ini) busca algo como:

[ConnectServerInfo]
ConnectServerPortTCP = 44405
MaxUserCount = 1000

En el archivo de lista de servidores que el Connect entrega al cliente (frecuentemente ServerList.dat o un .xml/.ini equivalente), comprueba los puertos de cada GameServer:

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

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

Arma una tabla como esta con tus valores (los de abajo son solo un ejemplo, varían por proveedor/versión):

Confirma qué puertos están de hecho a la escucha con:

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

Etapa 2: definir la política predeterminada de bloqueo

El principio de seguridad correcto es el default deny: bloquea todo lo que entra y libera solo lo necesario. Antes de aplicar, crea la regla de RDP (Etapa 3, paso 1) — pero conceptualmente la política va primero.

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

El primer comando garantiza que el firewall está encendido en los tres perfiles (Dominio, Privado, Público). El segundo define la política: bloquear entrada, permitir salida.

Etapa 3: liberar los puertos en el orden correcto

Sigue este orden numerado. Fue pensado para que nunca te dejes fuera del servidor.

1. Libera el RDP solo para tu IP (cambia 203.0.113.10 por tu IP real):

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

1. Libera el ConnectServer (grupo connect) para todos:

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

1. Libera los GameServers (grupo game). Una regla por puerto deja el log más legible:

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

Si tienes muchos sub-servidores en secuencia, un rango lo resuelve:

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

1. Libera el grupo web — solo si el sitio está en la misma máquina:

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. Bloquea explícitamente los puertos internos y el SQL hacia internet. Como la política ya es block, esto es redundante en teoría, pero una regla de bloqueo explícita protege contra futuras liberaciones accidentales y sirve de documentación:

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

Etapa 4: reforzar el SQL Server a nivel del servicio

Bloquear el 1433 en el firewall es bueno, pero la defensa en profundidad manda amarrar el propio SQL al loopback. Abre el SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → TCP/IP → pestaña IP Addresses. Deja habilitado solo el IPAll/IP1 correspondiente a 127.0.0.1 y deshabilita las direcciones que apuntan al IP público. Así, aunque alguien libere el 1433 por error, el SQL no estará escuchando en la interfaz pública.

Etapa 5: hacer lo mismo por la interfaz gráfica (opcional)

Si prefieres hacer clic en vez de teclear, ejecuta wf.msc y sigue:

1. Reglas de entrada → Nueva regla.
2. Tipo Puerto → TCP → indica el puerto (ej.: 44405).
3. Permitir la conexión.
4. Marca los tres perfiles (Dominio, Privado, Público).
5. Ponle un nombre estandarizado, como MU - ConnectServer 44405.

Para restringir por IP (caso del RDP), después de crear la regla: clic derecho → Propiedades → pestaña Ámbito → en Dirección IP remota elige "Estas direcciones IP" y añade la tuya.

Etapa 6: probar de afuera hacia adentro

Probar desde el propio servidor engaña, porque el tráfico local no pasa por las mismas reglas de internet. Prueba desde afuera:

• Pídele a un amigo (o usa el celular en 4G, fuera del Wi-Fi) que abra el cliente y verifique si la lista de servidores carga (valida el Connect) y si entra al mundo (valida el Game).
• Desde otra máquina, confirma que el 1433 está cerrado. Una forma simple en PowerShell:

Test-NetConnection -ComputerName TU_IP_PUBLICO -Port 1433

El resultado esperado es TcpTestSucceeded : False. Si da True, el SQL está expuesto — detén todo y corrige antes de seguir.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Todos los puertos reales mapeados a partir de los archivos .ini (no de memoria)
• Regla de RDP restringida a mi IP creada antes del bloqueo general
• Política predeterminada definida como blockinbound,allowoutbound
• ConnectServer liberado hacia internet
• Cada GameServer con su regla de entrada
• Puertos web (80/443) liberados solo si el sitio está en la misma máquina
• SQL (1433) y puertos internos explícitamente bloqueados
• SQL Server escuchando solo en 127.0.0.1
• Prueba hecha desde afuera (celular/amigo) validando Connect y Game
• Test-NetConnection confirmando el 1433 cerrado
• Backup de las reglas exportado con netsh advfirewall export
• Acceso KVM/VNC del proveedor probado y funcionando

Con este mapeo por grupo, tu servidor pasa a exponer exactamente lo que los jugadores necesitan y nada más. Es la base de seguridad sobre la cual vas a apilar después el anti-flood, el anti-DDoS y el hardening del panel web — pero todo empieza por saber, con precisión, qué puertos están abiertos y por qué.

Preguntas frecuentes