Requisitos de red

1. Walled garden: lo que un dispositivo alcanza antes de iniciar sesión

En el controlador: Settings → WiFi → Guest Hotspot → Authorization Access → Pre-Authorization Allowances. El SSID bloquea todo hasta que el dispositivo está autorizado; esta lista es la excepción que permite cargar la página de acceso.

El MFA por notificación push necesita un detalle más. Un push de Microsoft Authenticator viaja fuera de esta lista, así que un dispositivo que solo tiene el Wi-Fi de la empresa no recibe la notificación. El código de 6 dígitos de la propia aplicación funciona sin internet y lo resuelve; está explicado en la guía del usuario. No intente permitir el push en el walled garden: sus direcciones no son estables.

2. Firewall: el portal tiene que llegar a su controlador

El portal funciona en nuestra infraestructura y habla con su controlador UniFi a través de su API, para autorizar cada dispositivo que inició sesión. Es la única conexión que va de nosotros hacia usted.

Versiones probadas. UniFi Network 10.0, 10.4 y 10.6 en un controlador instalado en un servidor, y 10.5 en UniFi OS Server. Las consolas de hardware UniFi OS (Dream Machine, Cloud Gateway, Cloud Key) usan la misma API que UniFi OS Server, pero todavía no se probaron en un equipo. Si la suya es una de ellas, hable con Winserv antes de suscribirse.

Un portal atiende un sitio del controlador. Si su controlador tiene varios sitios (sucursales, edificios), el portal funciona en el sitio elegido en el alta; en los demás, el inicio de sesión y los vouchers no dan acceso. ¿Más de un sitio? Hable con Winserv antes de suscribirse.

El controlador tiene que estar publicado en internet en ese puerto, con un certificado válido, y tener una cuenta dedicada al portal. Créela en Settings → Admins → Add New Site Admin con el rol Site Administrator, con permiso solo en el sitio que atiende el portal: un superadministrador o la cuenta propietaria del controlador no son necesarios ni deseables.

No use el rol "Hotspot" de la página de administradores. Crea un administrador vinculado a una cuenta de Ubiquiti y envía una invitación por correo; esa cuenta se autentica en la nube de Ubiquiti, no en el controlador, así que la API local rechaza su inicio de sesión. Verificado en el controlador 10.4.57, donde los roles por sitio disponibles son solo Site Administrator y View Only, y "View Only" no puede autorizar a un invitado.

Lo que hace la cuenta, y nada más: autoriza y desautoriza invitados en el sitio (cmd/stamgr); lee la lista de sitios en el alta, y de nuevo cada vez que se cambia el controlador o su cuenta en la consola, para encontrar el identificador interno de su sitio; lee en qué red está un dispositivo cuando alguien canjea un voucher (stat/sta), para que un voucher solo funcione en la red de invitados; y lee la configuración del hotspot (rest/setting/guest_access) cuando usted abre la comprobación de su portal (desde el enlace del alta o en la consola), para decirle qué falta. No se cambia ninguna configuración del controlador.

3. Controlador: tres opciones en la página del hotspot

En Settings → WiFi → Guest Hotspot → Landing Page Settings:

1. External Portal Server = 2.28.19.100. Este campo acepta solo una dirección IP: un nombre no funciona en él.
2. Domain = SU-PORTAL.wifi.winserv.com.br (la dirección exacta está en la página de comprobación de su portal). Es lo que hace que el AP envíe al usuario al nombre y no a la IP. Sin esto el certificado no coincide y el navegador rechaza la conexión.
3. Secure Portal activado. Envía el dispositivo directamente a HTTPS, sin un primer viaje en texto plano en una red abierta.

Los dos primeros parecen redundantes y no lo son: uno dice adónde va la conexión, el otro qué nombre ve el navegador. Intercambiarlos es el error más común de esta página.

4. Dos redes: empleados y visitantes (opcional)

Para separar la red de empleados de la de visitantes: dos redes Wi-Fi en UniFi, ambas con Hotspot (portal cautivo) y cada una en su propia red/VLAN. Las dos usan el mismo portal: UniFi permite un portal por sitio. En la consola del portal (/admin → Networks), escriba el nombre de cada una: la corporativa muestra solo el inicio de sesión de Microsoft; la de visitantes, solo el voucher.

Lo que mantiene a los visitantes fuera de la red interna es su firewall, no UniFi. Con un gateway que no es de Ubiquiti (un FortiGate, por ejemplo), la lista Post-Authorization Restrictions del Hotspot no bloquea el acceso después de iniciar sesión; lo medimos: con los tres rangos privados en la lista, un dispositivo con sesión iniciada abrió otro dispositivo de la red local. La lista parece una protección y no lo es: no confíe en ella. Por lo tanto:

1. En el firewall, en la VLAN de visitantes: bloquee las redes internas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y permita solo internet. En la VLAN corporativa, aplique la política de la empresa.
2. Compruebe los dos lados: desde un dispositivo en la red corporativa, con sesión iniciada, un sistema interno abre; desde un dispositivo en la red de visitantes, no.

¿Gateway UniFi (UDM, USG)? No medimos ese caso, y probablemente la lista se aplica, lo que corta en ambos sentidos: protege a los visitantes, pero en una red con Hotspot también puede impedir que los empleados lleguen a la impresora y a los sistemas internos. Haga la misma prueba de los dos lados antes de abrir la red.

¿Una sola red para todos? Funciona (la página muestra el inicio de sesión de Microsoft y el voucher juntos), pero empleados y visitantes comparten una VLAN y el firewall no puede distinguirlos: con los vouchers activados, un visitante alcanza lo que alcanza un empleado en la red interna. Si hay una impresora, un servidor o un sistema interno que proteger, use dos redes; o deje una sola red solo para empleados, con los vouchers desactivados en la consola.

Client Device Isolation (en la página de cada red Wi-Fi, en Security) impide que los dispositivos de la misma red inalámbrica se vean entre sí:

1. Red de visitantes: activado. Un visitante no debe llegar al teléfono de otro visitante.
2. Red corporativa: desactivado si los empleados usan una impresora, duplicación de pantalla (AirPlay, Chromecast) o uso compartido entre dispositivos por Wi-Fi; activado si no, que es más seguro.

No controla el acceso a la red interna cableada: eso es el firewall, arriba. La red corporativa puede quedar abierta, sin contraseña: quien entra pasó por Microsoft, y un visitante que intente un voucher en ella se desconecta en menos de un minuto.

Televisores, aire acondicionado y otros equipos sin pantalla de inicio de sesión no pueden pasar por un portal cautivo. Póngalos en una tercera red, con contraseña, en su propia VLAN y sin Hotspot. Cada AP emite hasta 4 redes por banda (8 con Wireless Meshing desactivado), así que empleados, visitantes y equipos caben con margen.

DNS, si su red usa su propio resolvedor

Los hosts de la tabla de arriba tienen que resolverse desde la red Wi-Fi de invitados, antes de la autenticación. Las redes con un DNS interno restringido suelen ser donde esto falla, y el síntoma parece "el portal está caído".