Hotspot MikroTik: portal cautivo empresarial

Si operas la red de un hotel, un retail, un campus o una faena, tarde o temprano aparece el mismo requerimiento: dar acceso controlado a visitas, proveedores o clientes sin exponer tu red productiva ni entregar la clave del WiFi corporativo. El Hotspot MikroTik —el portal cautivo integrado en RouterOS— resuelve exactamente eso: intercepta al usuario no autenticado, lo lleva a una página de login, y solo abre el paso hacia internet cuando la sesión queda validada. En esta guía revisamos cómo funciona por dentro, qué piezas de RouterOS intervienen y cómo montarlo con criterio de ingeniería, no de tutorial casero.

Qué es y cómo funciona el portal cautivo de RouterOS

Un portal cautivo es un mecanismo que fuerza a todo cliente nuevo a autenticarse antes de tener conectividad. En RouterOS esto vive en el menú /ip/hotspot y, al activarlo, el sistema no solo levanta un servlet HTTP: también inserta automáticamente reglas en el firewall y en NAT para sostener la lógica de "antes y después del login".

El flujo real es este: un cliente se conecta, recibe IP por DHCP desde el address-pool del Hotspot e intenta navegar. Mientras no esté autenticado, sus peticiones HTTP caen en la cadena hs-unauth y son redirigidas al servlet de login (internamente por el puerto 64873 para el login y 64874 para el proxy del walled garden). Una vez que la sesión se valida, el cliente pasa a la cadena hs-auth y navega normalmente. RouterOS incluso puede avisar a los clientes DHCP que están detrás de un captive portal mediante RFC 7710, lo que mejora la experiencia en sistemas operativos modernos que detectan portales de forma nativa.

Un detalle que conviene entender: el Hotspot hace un cambio transparente de la IP del cliente cuando es necesario, así que un dispositivo con IP fija "equivocada" igual puede ser capturado y redirigido. Eso lo hace robusto para entornos donde no controlas la configuración de cada equipo que se conecta.

Anatomía de un Hotspot MikroTik: las piezas que debes conocer

Antes de configurar vale la pena tener claras las cuatro capas que componen un Hotspot MikroTik, porque cada una se ajusta por separado:

• Server (/ip/hotspot): asocia el portal a una interfaz o bridge, define el address-pool y apunta a un perfil. Aquí viven parámetros como idle-timeout, keepalive-timeout, login-timeout y addresses-per-mac.
• Server Profile (/ip/hotspot/profile): reúne la configuración común: métodos de login habilitados y la propiedad html-directory-override, que apunta al directorio con las páginas del servlet personalizadas.
• User Profile (/ip/hotspot/user/profile): define el "plan" del usuario. Aquí se controla rate-limit (ancho de banda) y shared-users (cuántas sesiones simultáneas permite una misma credencial).
• User (/ip/hotspot/user): las credenciales propiamente tales, o su equivalente delegado a RADIUS.

Separar estas capas es lo que permite, por ejemplo, tener un mismo servidor con perfiles distintos: "visitas" con 5 Mbps y una sola sesión, "proveedores" con más ancho de banda y credenciales nominativas, todo sobre la misma infraestructura.

Configuración base de un Hotspot MikroTik con comandos reales

La vía rápida es el asistente /ip/hotspot setup, que te pregunta interfaz, pool, certificado y usuario inicial paso a paso. Pero para un despliegue empresarial conviene entender qué deja armado y ajustarlo a mano. Un esqueleto realista se ve así:

/ Perfil de servidor: metodos de login y paginas personalizadas
/ip/hotspot/profile
set [find default=yes] \
    login-by=cookie,http-chap,https \
    html-directory-override=hotspot-corp

/ Perfiles de usuario: ancho de banda y sesiones simultaneas
/ip/hotspot/user/profile
add name=visitas   rate-limit=5M/5M   shared-users=1  idle-timeout=15m
add name=proveedor rate-limit=20M/20M shared-users=3  idle-timeout=30m

/ Usuarios locales (o delega en RADIUS)
/ip/hotspot/user
add name=sala-reuniones password=***** profile=visitas
add name=contratista-acme password=***** profile=proveedor

/ Servidor Hotspot sobre el bridge de invitados
/ip/hotspot
add name=hs-invitados interface=bridge-guest \
    address-pool=pool-invitados profile=default \
    idle-timeout=15m keepalive-timeout=2m addresses-per-mac=2

Sobre los métodos de login: http-pap envía la contraseña en texto plano y solo es aceptable sobre HTTPS; http-chap hashea con MD5 en el navegador (requiere md5.js cargado en la página de login); y cookie evita que el usuario tenga que re-autenticarse en cada reconexión. Para un portal serio, la combinación https + cookie entrega seguridad de transporte y una experiencia razonable. En entornos multiusuario compartidos, recuerda que la cookie puede borrarse en el logout con el parámetro erase-cookie.

Walled Garden: acceso sin login a lo que corresponde

Rara vez quieres un portal totalmente cerrado. El walled garden es el mecanismo para dejar accesibles ciertos destinos antes de autenticar: la propia página corporativa, un servidor de pago externo, un dominio de detección de captive portal, o el CDN que sirve el logo de tu página de login. RouterOS distingue dos submenús:

• /ip/hotspot/walled-garden: reglas basadas en HTTP/DNS (por dst-host), ideales para permitir dominios completos.
• /ip/hotspot/walled-garden/ip: reglas por dirección IP y protocolo, que se reflejan también en el filtro de paquetes, no solo en NAT.

/ip/hotspot/walled-garden
add dst-host=*.mikrotikchile.com action=allow
add dst-host=pagos.miproveedor.cl action=allow

/ip/hotspot/walled-garden/ip
add dst-address=200.0.0.0/24 action=accept protocol=tcp

Un uso clásico es el registro o pago en un servidor externo: permites por walled garden el acceso al servidor de autenticación, modificas la página de login para redirigir hacia él, y ese servidor actualiza la base RADIUS para habilitar la sesión. Así puedes integrar cobros con tarjeta o registro de datos sin que la lógica de negocio viva dentro del router.

Personalización del portal y las páginas del servlet

Las páginas que ve el usuario son archivos HTML almacenados en el router (accesibles por FTP) y se personalizan copiando el directorio hotspot por defecto y apuntando html-directory-override al nuevo directorio. Las principales son login.html, alogin.html (post-login), status.html, logout.html, error.html y la variante flogin.html que se muestra ante credenciales inválidas.

La personalización se apoya en variables con la sintaxis $(nombre), que el servlet reemplaza en caliente. Algunas útiles:

Variable	Qué entrega
$(username)	Usuario logueado
$(ip) / $(mac)	IP y MAC del cliente
$(link-login)	Enlace al login con la URL original solicitada
$(link-logout)	Enlace a la página de logout
$(link-orig)	URL que el usuario intentaba abrir
$(error)	Mensaje de error (solo en la página de login)

Dos advertencias de terreno: primero, MikroTik recomienda editar los HTML a mano, porque los editores visuales suelen corromper las variables. Segundo, si vas a incrustar variables dentro de enlaces (como el usuario en una URL), usa la versión escapada —por ejemplo $(user-esc) en vez de $(user)— para no romper el enlace con caracteres especiales. RouterOS también soporta múltiples juegos de páginas para multi-idioma, creando subdirectorios (p. ej. en/) con solo los archivos que cambian.

Hotspot vs. PPPoE: cuándo usar cada uno

Una confusión frecuente en proyectos de ISP y empresa es cuándo usar Hotspot y cuándo PPPoE. No compiten: resuelven problemas distintos. El Hotspot brilla para acceso temporal y sin cliente —el usuario solo necesita un navegador—, típico de WiFi de visitas, salas, eventos, retail y hotelería. PPPoE, en cambio, es el estándar para gestión de abonados permanentes, donde cada cliente tiene una sesión nominativa, direccionamiento consistente y contabilidad fina. En redes de acceso donde ya operas PPPoE con RADIUS, muchas veces el Hotspot cumple el rol acotado de la red de invitados corporativa, aislada por VLAN del tráfico productivo.

Ambos, además, comparten la capa RADIUS: puedes centralizar credenciales, perfiles y accounting de tus usuarios Hotspot en el mismo servidor que ya usas para PPPoE. Eso te da trazabilidad real de quién se conectó, desde qué MAC y por cuánto tiempo —dato clave para auditoría y para cumplir requisitos legales de registro de sesiones.

Errores comunes al desplegar un Hotspot en producción

• Montar el Hotspot sobre la interfaz equivocada y capturar tráfico que no debía pasar por el portal. Siempre acota el Hotspot a un bridge o VLAN de invitados dedicada.
• Olvidar el walled garden del propio dominio y de los sistemas de detección de captive portal, dejando páginas de login que no cargan sus recursos o que los dispositivos no detectan.
• Dejar shared-users en 1 cuando varias personas comparten una credencial de evento, generando bloqueos inexplicables.
• Usar http-pap sin HTTPS, exponiendo contraseñas en texto plano en el aire.
• No dimensionar rate-limit por perfil, dejando que la red de invitados compita por el ancho de banda con la operación crítica.

Un portal cautivo bien hecho no es pegar un login: es diseño de segmentación, políticas de ancho de banda, integración con RADIUS y una capa de firewall que aísle de verdad a los invitados de tu red productiva. En MikroTik Chile diseñamos e implementamos accesos controlados sobre RouterOS para hoteles, retail, campus e ISPs, con la documentación y el monitoreo para operarlos en el tiempo. Si necesitas montar o afinar un Hotspot empresarial, o revisar un despliegue que quedó a medias, conversemos: cuéntanos tu caso en soporte o revisa nuestra consultoría de redes MikroTik.