Portal cautivo con Omada: cómo configurarlo bien y que Android no te haga renegar

Un portal cautivo es esa página que aparece cuando te conectás al WiFi de un bar, un hotel o un aeropuerto: antes de navegar tenés que aceptar condiciones, poner un código o loguearte. Con Omada se arma en unos minutos. El problema es que "anda en mi notebook" no quiere decir que ande en todos lados: Android tiene su propia forma de detectar portales, y si el portal no está pensado para eso, el reclamo de "el WiFi no anda" llega el primer día.

En esta entrada van los pros y los contras de usar un portal, cómo funciona la detección en los celulares (que es lo que explica casi todos los problemas), la configuración paso a paso en Omada y una lista de pruebas para no enterarte de los errores por los clientes.

Las capturas son de un controlador OC200 real con Omada 6.3. Armé el portal y los vouchers para las fotos y los descarté sin aplicarlos. Los nombres del sitio y de los SSID están cambiados.

¿Conviene un portal cautivo?

Antes de configurar nada, vale la pena preguntarse si hace falta. Un portal resuelve algunas cosas muy bien y complica otras.

Si lo único que querés es que las visitas no entren a la red de la oficina, no hace falta un portal: alcanza con un SSID de invitados aislado y una clave que se cambie cada tanto. Para la red de los empleados, lo correcto es WPA2/WPA3-Enterprise o PPSK, no un portal.

El portal tiene sentido cuando necesitás controlar el acceso de cada visita (vouchers, tiempos, límites) o que acepten condiciones antes de navegar.

Cómo detecta un celular que hay un portal

Esto es lo que explica casi todos los problemas, así que vale la pena entenderlo antes de tocar el controlador.

Cuando un equipo se conecta a un WiFi, no espera a que el usuario abra el navegador: hace una consulta de prueba por HTTP a una dirección conocida y mira qué le contestan.

  Celular               AP Omada                   Controlador           Internet
     │  se conecta, DHCP y DNS: OK                      │                    │
     │                                                  │                    │
     │── GET http://connectivitycheck.gstatic.com/generate_204 ─────────────▶│
     │       ✋ el AP la intercepta (el cliente todavía no se autenticó)       │
     │◀── 302: andá a http://<controlador>:8088/portal/... ──│               │
     │                                                  │                    │
     │   Android: "Iniciá sesión en la red WiFi"        │                    │
     │── abre el mini navegador del sistema ──────────▶ │                    │
     │── voucher / clave / "Log In" ──────────────────▶ │                    │
     │                        ◀── autorizá esta MAC ────│                    │
     │                                                  │                    │
     │── GET .../generate_204 ──────────────────────────────────────────────▶│
     │◀── 204 No Content ───────────────────────────────────────────────────│
     │   ✔ "Conectado": el mini navegador se cierra solo                     │

Cada sistema usa su propia dirección de prueba y espera una respuesta exacta:

Si la respuesta es la esperada, el equipo da la red por buena. Si le llega otra cosa (una redirección al portal), muestra el aviso para iniciar sesión. Y si no le llega nada, marca la red como "sin Internet" y no muestra ningún aviso.

Android 11 y posteriores también entienden un aviso por DHCP (RFC 8910, opción 114) que dice "acá hay un portal", pero lo que hace todo el mundo, y lo que hace Omada, es interceptar esa consulta y redirigirla.

Por qué Android se lleva mal con los portales

Con ese mecanismo en mente, los problemas típicos de Android se entienden solos:

• El mini navegador se cierra solo. En Android el portal no se abre en Chrome, sino en una app del sistema ("Iniciar sesión en la red"). Apenas detecta que hay Internet, la cierra. Resultado: la página de bienvenida o la URL de promoción que configuraste en Omada no se llega a ver, o aparece medio segundo. TP-Link lo reconoce en su guía oficial: es el comportamiento normal de Android, varía según marca y versión, y recomiendan poner la información en la página del portal en vez de en la página de llegada.
• El usuario ignora el aviso y "anda igual". Si nadie toca la notificación, Android sigue usando los datos móviles porque el WiFi "no tiene Internet". El usuario ve el ícono del WiFi, navega con sus datos y después se queja de que se le terminó el plan.
• La lista blanca mal armada. Si en el acceso previo a la autenticación dejás pasar dominios de Google "por las dudas" (*.google.com, *.gstatic.com), la consulta de prueba de Android llega a Internet, recibe un 204 de verdad y el celular cree que no hay portal. Nunca aparece la página. Es el error más común y el más difícil de diagnosticar.
• El DNS privado. Android permite configurar un "DNS privado" (DNS sobre TLS) con un proveedor fijo. Con algunos portales eso hace que el aviso no aparezca, porque el DNS no responde hasta que el cliente se autentica. Lo mismo pasa con las apps de VPN o bloqueadores de publicidad que filtran el DNS. Si a alguien no le aparece el portal y a los demás sí, es lo primero que hay que preguntar.
• La MAC aleatoria. Desde Android 10, el celular usa una MAC inventada para cada red. Omada autoriza por MAC, así que si esa MAC cambia (por ejemplo, si el usuario "olvida" la red, o con la opción de MAC no persistente que traen algunas versiones), el portal vuelve a aparecer. Y si querés liberar un equipo por MAC, tenés que poner en ese equipo "Usar la MAC del dispositivo" para esa red.
• El mini navegador es limitado. No tiene pestañas, no descarga archivos y no siempre guarda cookies. Iniciar sesión con una cuenta de Google o de una red social dentro de esa ventana es lo que más falla: Google, por ejemplo, bloquea los inicios de sesión desde navegadores embebidos que no cumplen sus reglas.

iPhone tiene el mismo mecanismo con otra dirección, pero su mini navegador no se cierra solo después de autenticar, así que la página de llegada se ve. Por eso pasa tanto que "en el iPhone anda y en Android no".

Antes de empezar

• El controlador tiene que estar siempre prendido. TP-Link lo dice sin vueltas en su guía ¿El portal necesita que el controlador esté en línea?: sí, para todos los tipos de autenticación. Si se apaga, los clientes ya autenticados siguen navegando, pero los nuevos no pueden entrar. Un OC200/OC300 o un controlador en un servidor que no se apague (ver Controlador Omada en Docker o en un LXC de Proxmox). Una notebook con el software, no.
• Los clientes tienen que llegar al controlador. La página del portal la sirve el controlador, por defecto en los puertos 8088 (HTTP) y 8843 (HTTPS). Si tenés ACLs propias entre redes, no bloquees esos puertos desde la red de invitados.
• Para WiFi alcanza con APs Omada (EAP). Para un portal en una red cableada hace falta un gateway Omada, y el controlador avisa que en cable el portal no funciona si entre el cliente y el router hay un salto de capa 3.
• Tené una red de invitados separada, con su VLAN o con la opción Guest Network del SSID, para que las visitas no vean los equipos de la oficina. El portal controla quién navega, no lo aísla de la red.

Paso 1: crear el portal

Todo está en Network Config → Authentication → Portal:

La pantalla tiene dos pestañas: Portal, con la lista de portales, y Access Control, que vemos más adelante. Arriba a la derecha está Authorized Clients (para ver quién está autenticado y sacarlo) y Create New Portal:

El formulario tiene tres pestañas: Basic, Authentication y Design. A la derecha se ve en vivo cómo va quedando la página, en celular o en PC.

Pestaña Basic

En SSID & Network se elige dónde se aplica: los SSID (marcados como 【SSID】) y las redes cableadas (【Network】). Marcá solo el SSID de invitados:

HTTPS Redirection redirige al portal a quien intenta abrir un sitio HTTPS sin estar autenticado. Suena bien, pero el AP no puede hacerse pasar por https://www.google.com: el navegador muestra un error de certificado ("La conexión no es privada"), y en los sitios con HSTS ni siquiera deja continuar. La gente se asusta y no entra. La detección automática del sistema (que va por HTTP) ya se encarga de abrir el portal, así que conviene dejarla apagada.

Landing Page tiene tres opciones: Original URL (lo manda a la página que quería abrir), Promotional URL (a una dirección tuya) y Success Page (la página de éxito del portal, que con vouchers muestra el tiempo que le queda). Por lo que vimos de Android, la URL de promoción es la que más se pierde.

Portal URL muestra la dirección a la que se redirige a los clientes. Se configura aparte, en el paso 5.

Paso 2: elegir el tipo de autenticación

En la pestaña Authentication están todos los tipos:

Para la gran mayoría de los casos alcanza con No Authentication, Simple Password o Hotspot con vouchers. Son los que menos fallan porque todo pasa dentro de la página del portal, sin depender de sitios externos.

Authentication Timeout es cada cuánto el cliente tiene que volver a pasar por el portal. Las opciones son 1 Hour, 8 Hours, 24 Hours, 7 Days o Custom. Muy corto es la receta para los reclamos: con 1 hora, el celular que quedó en el bolsillo pierde la conexión a mitad de la tarde y el aviso queda escondido entre las notificaciones. Para un bar, 8 horas; para un hotel, 24 horas o los días de estadía.

Con No Authentication aparece también Daily Limit: si está activado, cuando vence el tiempo el cliente no puede volver a autenticarse hasta el día siguiente. Sirve para dar, por ejemplo, una hora de WiFi gratis por día.

Paso 3: vouchers (Hotspot)

Con Hotspot, se marcan los métodos que se van a aceptar: Voucher, Local User, SMS, RADIUS y Form Auth. La vista previa ya muestra el campo para el código:

Los vouchers se generan en Hotspot (menú de la izquierda, abre la administración del hotspot en otra vista) → Vouchers → Voucher Groups → Create Vouchers Group. Este paso hay que hacerlo antes de aplicar el portal, o no va a haber códigos para repartir.

Type tiene tres opciones:

• Limited Usage Counts: el código sirve para una cantidad de ingresos (1 a 999). Con 1, cada código es para un solo equipo.
• Limited Online Users: el código sirve para varios equipos a la vez, hasta el número que pongas. Útil para una familia en un hotel (celulares, tablet y notebook con el mismo código).
• Unlimited For Usage: sin límite de equipos. Solo para casos puntuales: un código que se comparte termina en un grupo de WhatsApp.

Más abajo está el tiempo, que es lo que más confunde:

• Voucher Validity: entre qué fechas se puede usar el código (por defecto, un año).
• Duration Type: con Voucher Duration, el tiempo corre para el código (8 horas desde el primer uso y después vence, se use o no). Con Client Duration, el tiempo corre para cada equipo que lo usa.
• Timing: By Time cuenta el tiempo de reloj desde el primer uso; By Usage cuenta solo el tiempo conectado ("8 horas de uso en total").
• Duration: cuánto dura (8 horas en el ejemplo).
• Rate Limit y Traffic Limit: límite de velocidad y de datos por cliente. El controlador avisa que el límite de velocidad solo aplica a clientes inalámbricos en SSID con portal; para cable se usa Bandwidth Control.

En el segundo paso (Vouchers Pattern) se elige el diseño para imprimirlos. Desde Voucher Groups se imprimen los que no se usaron y se exportan.

Para un bar o un consultorio, una combinación que anda bien es: código de 6 números, Limited Usage Counts = 1, Voucher Duration, By Time, 8 horas.

Paso 4: la página del portal (Design)

En la pestaña Design se cambian el fondo, el logo, los textos, el formulario y se pueden agregar publicidades. También se puede importar una página propia.

Por lo que vimos de Android, todo lo que quieras que la gente vea tiene que estar en esta página, no en la de llegada: la clave de otra red, los horarios, el menú, el aviso de condiciones de uso. Y que se lea bien en un celular: la vista previa tiene un botón para verla en pantalla chica.

Paso 5: Access Control, lo que se deja pasar sin autenticar

En la pestaña Access Control del portal hay dos opciones:

Pre-Authentication Access es la lista blanca: direcciones (URL o rangos de IP) a las que se puede entrar antes de autenticarse. Sirve, por ejemplo, para que la página del portal cargue el logo o las condiciones de uso desde tu sitio. La regla de oro: lo mínimo indispensable, y nunca dominios genéricos de Google, Apple o Microsoft. Si la consulta de prueba del celular pasa por la lista blanca, el celular cree que tiene Internet y el portal nunca aparece.

Authentication-Free Client libera equipos puntuales, por MAC o por IP, para que naveguen sin pasar por el portal. Es la solución para los que no pueden con un portal: Smart TV, Chromecast, consolas, impresoras, el posnet, cámaras. Si es por MAC, que sea la MAC real del equipo (en celulares, desactivando la MAC aleatoria para esa red).

Paso 6: la dirección del portal y HTTPS

Esto no está en el sitio sino en la configuración general del controlador: Global View → Settings → System Settings → Portal Access.

• Portal URL: con Auto Refresh, el controlador usa su propia IP como destino de la redirección. Con Manual, ponés un nombre de dominio o una IP que los clientes puedan alcanzar. Hace falta Manual si el controlador está en la nube, detrás de un NAT o si querés usar HTTPS con certificado.
• HTTP Redirect to HTTPS (Portal): manda a los clientes al portal por HTTPS en vez de HTTP. Solo tiene sentido con un nombre de dominio y un certificado válido para ese nombre, cargado en el mismo System Settings → HTTPS Certificate. Con el certificado autofirmado que trae el controlador, cada cliente ve un error de certificado antes del portal, que es lo peor que le podés hacer a un usuario de celular.
• HTTPS Portal Port y HTTP Portal Port: por defecto 8843 y 8088. El controlador recomienda que no sean los mismos que los de administración, y cualquier cambio en esta sección reinicia el controlador.

Si no tenés dominio y certificado, lo más seguro es dejar todo como viene: Auto Refresh, sin redirección a HTTPS.

Recién ahí, con todo revisado, volvé al portal y dale Apply.

Cómo probarlo antes de que lo usen los clientes

Desde una notebook conectada al SSID de invitados, antes de autenticarte, la consulta de prueba de Android tiene que devolver una redirección al portal:

curl -i http://connectivitycheck.gstatic.com/generate_204

HTTP/1.1 302 Found
Location: http://192.168.10.2:8088/portal/...

Si devuelve 204 No Content, el portal no está interceptando (o hay algo en la lista blanca que lo deja pasar). Si se queda colgado, el cliente no llega al controlador o el DNS no responde.

Después de autenticarte, la misma consulta tiene que dar 204. Y lo mismo con la de Apple, que tiene que mostrar Success:

curl -s http://captive.apple.com/hotspot-detect.html

Después, la prueba con equipos reales:

• Un Android de dos marcas distintas (Samsung y Motorola o Xiaomi, por ejemplo): aparece el aviso, se abre el portal, se autentica y navega.
• Un iPhone.
• Una notebook con Windows.
• Un Android con DNS privado configurado.
• Desconectarse y volver a conectarse: no tiene que pedir el portal de nuevo hasta que venza el tiempo.
• Al otro día, con el tiempo vencido: el portal tiene que volver a aparecer.
• Desde la red de invitados, no tiene que haber acceso a la red de la oficina ni a la administración del controlador (a los puertos del portal, sí).
• En Authorized Clients aparecen los equipos autenticados.

Problemas frecuentes

Una nota sobre los datos personales

Si el portal pide nombre, correo o teléfono (con Form Auth o SMS), eso es una base de datos personales, y en Argentina aplica la Ley 25.326: hay que avisar para qué se usan esos datos y cómo pedir que se borren. Lo mismo si se usan con fines de marketing. Si vas a juntar datos, asesorate antes. Si no los necesitás, no los pidas: los vouchers o la clave simple no guardan nada de la persona.

En resumen

El portal cautivo no es difícil de configurar en Omada: es difícil de hacer que ande en todos los equipos. Casi todo se reduce a entender cómo detecta el celular que hay un portal, y a no romper esa detección.

Si estás armando la red desde cero, están las entradas de configuración inicial del ER605 y del controlador Omada en Docker.

Fuentes: Cómo configurar la autenticación por portal en Omada 6.2 y posteriores y ¿El portal necesita que el controlador esté en línea?, de TP-Link. Para controladores 4.1 a 5.9, los menús cambian: está la guía para esas versiones.