Resolución de problemas de redirección del Captive Portal: cómo solucionar fallos de conexión en redes WiFi de invitados
Cuando los invitados se conectan a su WiFi pero no pueden acceder a internet, la causa casi siempre es una configuración incorrecta en la redirección del Captive Portal, no un fallo de hardware. Esta guía ofrece una referencia técnica detallada para directores de TI, arquitectos de red y CTO con el fin de diagnosticar y resolver toda la cadena de fallos: desde las sondas de conectividad a nivel de sistema operativo y los conflictos de certificados HSTS hasta las brechas de autorización de RADIUS y el agotamiento de DHCP. Relaciona cada modo de fallo con una solución concreta y muestra cómo la capa en la nube de Purple, independiente del hardware, elimina estos problemas en despliegues de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.
Video overview
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de Captive Portal →
Resumen ejecutivo
La consulta "guest WiFi connected but no internet" es una de las incidencias de soporte más comunes en las redes empresariales. El síntoma es visible para todos los visitantes; la causa es invisible para la mayoría de los equipos de TI hasta que entienden la cadena de redireccionamiento. Un Captive Portal (también llamado página de inicio o pasarela de punto de acceso) intercepta la sonda de conectividad HTTP inicial de un dispositivo y emite una redirección HTTP 302 a una página de inicio de sesión. Si se rompe algún paso de esa cadena (sondas bloqueadas, conflictos de HSTS, brechas en el walled garden, fallos de RADIUS o agotamiento de DHCP), el invitado no ve más que un icono de WiFi conectado y sin internet. Esta guía le guiará a través de cada modo de fallo, la mecánica del protocolo subyacente y los cambios de configuración que los resuelven. Purple opera en más de 80.000 recintos activos, procesando 440 millones de inicios de sesión anualmente (datos internos de Purple, 2024), y los patrones descritos aquí representan las causas principales más frecuentes que vemos en implementaciones de hostelería, comercio minorista, transporte y sector público.
Análisis técnico profundo
Cómo funciona realmente la detección de Captive Portal
Todos los principales sistemas operativos incorporan un mecanismo para detectar si una red requiere autenticación antes de conceder acceso a internet. Comprender estos mecanismos es la base de toda resolución de problemas de Captive Portal.
Cuando un dispositivo se asocia a un SSID, el SO envía una solicitud HTTP GET no cifrada a una URL predefinida. La siguiente tabla enumera las URL de sonda por plataforma.
| Sistema operativo | URL de sonda | Respuesta esperada |
|---|---|---|
| iOS / macOS | http://captive.apple.com/hotspot-detect.html |
HTTP 200 con cuerpo específico |
| Android (Google) | http://connectivitycheck.gstatic.com/generate_204 |
HTTP 204 No Content |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
HTTP 200 con cuerpo 'Microsoft Connect Test' |
| Chrome (todas las plataformas) | http://www.gstatic.com/generate_204 |
HTTP 204 No Content |
| Firefox | http://detectportal.firefox.com/success.txt |
HTTP 200 |
Si la pasarela intercepta una de estas solicitudes y devuelve una redirección HTTP 302 que apunta a la URL del Captive Portal, el SO reconoce que está detrás de un portal y abre un pseudonavegador (un WebView ligero) para mostrar la página de inicio. Si la sonda se bloquea por completo, el SO informa de "Sin conexión a internet" y nunca intenta abrir el portal. Esta es la causa más común del síntoma "guest WiFi connected but no internet".
El problema de HSTS
HTTP Strict Transport Security (HSTS) es una política de seguridad web definida en RFC 6797. Indica a los navegadores que rechacen todas las conexiones HTTP sin cifrar a un dominio y que rechacen cualquier certificado que no coincida exactamente. Los dominios principales, incluidos google.com, facebook.com y la mayoría de los sitios bancarios, están en la lista de precarga de HSTS integrada en Chrome, Firefox, Safari y Edge.
Cuando un invitado abre un navegador y escribe google.com, el navegador actualiza la solicitud a HTTPS antes de que salga del dispositivo. La puerta de enlace no puede interceptar una solicitud HTTPS y redireccionarla limpiamente; tendría que presentar un certificado para google.com, del cual no dispone. El navegador detecta la discrepancia de certificado y muestra una advertencia de seguridad grave. El invitado no puede continuar a la página de inicio de sesión.
La arquitectura correcta se basa completamente en las sondas HTTP a nivel de sistema operativo descritas anteriormente. Esas sondas utilizan HTTP sin cifrar hacia URLs que no son HSTS específicamente para que las puertas de enlace puedan interceptarlas y redireccionarlas sin conflictos de certificados. Su puerta de enlace debe interceptar estas sondas HTTP y emitir la redirección 302. No intente interceptar tráfico HTTPS para fines de Captive Portal.
El walled garden
Un walled garden es el conjunto de dominios y direcciones IP a los que un dispositivo puede acceder antes de haberse autenticado. Si el walled garden es demasiado estrecho, es posible que la página de bienvenida se cargue pero la autenticación falle. Las omisiones comunes incluyen:
- Dominios del proveedor de identidad: Si utiliza Microsoft Entra ID, Okta o Google Workspace para el inicio de sesión social o SSO, sus puntos de conexión de autenticación deben estar en el walled garden.
- Dominios de CDN y recursos: Su página de bienvenida puede cargar CSS, JavaScript o fuentes desde una red de entrega de contenido. Si esos dominios de CDN están bloqueados, la página se mostrará de forma incorrecta.
- Dominios del procesador de pagos: Si cobra por el acceso a través de Stripe u otro procesador, los dominios de su SDK de JavaScript deben estar preautenticados.
- Dominios de la plataforma Purple: La capa en la nube de Purple requiere que la puerta de enlace llegue a los servidores RADIUS y puntos de conexión del portal de Purple. Estos se documentan en las guías de integración de hardware de Purple para cada plataforma compatible.
RADIUS y la brecha de autorización
RADIUS (Remote Authentication Dial-In User Service) es el protocolo que conecta su puerta de enlace local con la plataforma de autenticación. Cuando un invitado completa el formulario de inicio de sesión, el Captive Portal envía las credenciales al servidor RADIUS. El servidor RADIUS devuelve un mensaje Access-Accept o Access-Reject. La puerta de enlace actúa en función de ese mensaje abriendo o manteniendo cerrada la regla del firewall que otorga acceso a internet.
La brecha de autorización - donde un invitado inicia sesión correctamente en la página de bienvenida pero sigue sin tener internet - casi siempre significa que la puerta de enlace no recibió o no procesó el mensaje Access-Accept. Las causas comunes incluyen una clave secreta compartida que no coincide, los puertos UDP 1812 y 1813 bloqueados por un firewall local, o la dirección IP del servidor RADIUS configurada incorrectamente en la puerta de enlace.
Agotamiento de DHCP en entornos de alta densidad
En estadios, centros de conferencias y nodos de transporte, el agotamiento de direcciones DHCP es una causa frecuente de fallos de conexión que parece idéntica a un problema de Captive Portal. Si el pool DHCP está lleno, un nuevo dispositivo se asocia con el punto de acceso pero nunca recibe una dirección IP. Sin una dirección IP, el dispositivo no puede enviar la sonda HTTP y nunca llega al Captive Portal. El dispositivo se muestra como conectado al SSID pero no tiene internet.
Para recintos como Manchester Airports Group (MAG), donde los volúmenes de pasajeros alcanzan picos muy pronunciados, las subredes deben dimensionarse para el número máximo de dispositivos simultáneos, no para el promedio. Los tiempos de concesión de DHCP cortos (de 15 a 30 minutos para redes de visitantes transitorios) recuperan rápidamente las direcciones de los dispositivos que se han marchado.
Guía de implementación
Los siguientes pasos se aplican a cualquier plataforma de hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet - cuando se integra con la capa de nube de Purple.
Paso 1: Configurar el SSID para el Captive Portal externo. En su controlador de hardware, configure el SSID de invitados para redirigir a los clientes no autenticados a la URL del portal externo de Purple. Desactive cualquier página de bienvenida local en el propio controlador.
Paso 2: Definir el Walled Garden (entorno cerrado). Añada como mínimo los siguientes dominios: los endpoints de RADIUS y del portal de Purple (consulte su guía de integración de hardware), las URL de las sondas de detección de SO indicadas anteriormente, los dominios de su proveedor de identidad (Microsoft Entra ID, Okta o Google Workspace) y cualquier dominio de CDN que utilicen los recursos de su página de bienvenida.
Paso 3: Configurar RADIUS. Introduzca las direcciones IP del servidor RADIUS de Purple, el secreto compartido de su panel de Purple, y configure el puerto de autenticación en 1812 y el puerto de contabilidad en 1813. Verifique que su cortafuegos local permita el tráfico UDP saliente en estos puertos.
Paso 4: Configurar los parámetros de sesión. Para hostelería y comercio minorista, configure la duración de la sesión en 24 horas con el almacenamiento en caché de direcciones MAC habilitado. Esto evita que los invitados se vean obligados a volver a autenticarse durante una misma visita. Para entornos de alta seguridad, es adecuado utilizar sesiones más cortas con reautenticación.
Paso 5: Dimensionar el rango de DHCP. Calcule el número máximo de dispositivos simultáneos en su recinto durante la capacidad pico. Un restaurante de 500 plazas puede registrar 800 dispositivos durante un servicio concurrido. Dimensione el pool DHCP a 1.000 direcciones con un tiempo de concesión de 30 minutos.
Paso 6: Probar en diferentes sistemas operativos. Tras la configuración, pruebe todo el flujo en dispositivos iOS, Android y Windows. Cada uno utiliza una URL de sonda y una implementación de WebView diferente. Un fallo en una plataforma mientras las demás funcionan suele ser casi siempre una omisión en el Walled Garden.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Buenas prácticas
Las siguientes recomendaciones reflejan los estándares y patrones de más de 80.000 despliegues de recintos de Purple.
Separe las redes de invitados y del personal. Tenga al menos tres SSIDs: Guest WiFi, Staff WiFi y una red IoT. El tráfico de invitados debe estar aislado de los sistemas internos. Consulte nuestra guía sobre Tres SSIDs para dominarlos a todos: invitados, Passpoint y WiFi IoT para obtener detalles sobre la arquitectura.
Utilice una VLAN de invitados dedicada. Segmente el tráfico de invitados en su propia VLAN para evitar el movimiento lateral y simplificar las políticas de firewall. Este es un requisito de PCI-DSS si se transmiten datos de tarjetas de pago a través de la red.
Implemente opciones de consentimiento consciente. El GDPR exige que la recopilación de datos en el Captive Portal se base en un consentimiento informado y afirmativo. Las opciones de consentimiento consciente de Purple presentan las opciones de recopilación de datos de forma clara, con casillas de verificación independientes para cada finalidad. Esto es obligatorio para los establecimientos que operan en el Reino Unido o la UE.
Supervise de forma proactiva el estado del portal. La plataforma de WiFi Analytics de Purple proporciona visibilidad en tiempo real de las tasas de inicio de sesión correcto, el número de sesiones y los fallos de autenticación. Una caída repentina en los inicios de sesión correctos es una alerta temprana de un problema de RADIUS o de Walled Garden antes de que los invitados comiencen a quejarse.
Aplique una imagen de marca coherente. La página de bienvenida es la primera interacción de marca que un invitado tiene con su red. Un portal bien diseñado aumenta las tasas de aceptación y establece las expectativas para la experiencia de WiFi. Consulte Cómo causar una excelente primera impresión con su WiFi de invitados para obtener orientación sobre el diseño.
-
Resolución de problemas y mitigación de riesgos
Cuando se notifique un problema con el Captive Portal, siga esta secuencia de diagnóstico antes de realizar cualquier cambio de configuración.
Aísle el punto de fallo. Pregunte al invitado qué sistema operativo y navegador está utilizando. Pruebe el mismo flujo usted mismo en el mismo sistema operativo. Si el problema es específico del sistema operativo, la causa es casi seguro la falta de una entrada de Walled Garden para la URL de sondeo de ese sistema operativo.
Verifique la resolución de DNS. Desde un dispositivo en la VLAN de invitados, intente resolver el nombre de host del Captive Portal. Si la resolución de DNS falla, el dispositivo no podrá acceder a la página de bienvenida aunque la redirección se realice correctamente. Verifique que su servidor DHCP esté distribuyendo direcciones DNS fiables y que la puerta de enlace permita consultas DNS en el estado previo a la autenticación.
Capture la redirección. Utilice las herramientas para desarrolladores del navegador (F12) o una captura de paquetes para observar el intercambio HTTP. Debería ver la solicitud de sondeo del sistema operativo seguida de una respuesta HTTP 302 que contiene la URL del portal. Si ve la solicitud de sondeo pero no la respuesta 302, la puerta de enlace no está realizando la interceptación correctamente. Si no ve ninguna solicitud de sondeo, el sistema operativo ya ha determinado que tiene acceso a Internet (posiblemente a partir de un estado almacenado en caché) y no está enviando el sondeo. Verifique la comunicación RADIUS. En la pasarela, compruebe los registros de contabilidad de RADIUS. Una autenticación correcta genera un registro de inicio de contabilidad (Accounting-Start). Si no ve registros de contabilidad después de que un invitado inicie sesión, la comunicación RADIUS está fallando. Compruebe el secreto compartido, la IP del servidor y las reglas del cortafuegos.
Compruebe la utilización de concesiones DHCP. En el servidor DHCP, revise el recuento actual de concesiones en comparación con el tamaño del grupo de direcciones. Si la utilización supera el 90%, se está acercando al agotamiento. Amplíe el grupo de direcciones o reduzca el tiempo de concesión de inmediato.
La siguiente tabla asocia los síntomas más comunes con sus causas principales y la solución correspondiente.
| Síntoma | Causa principal más probable | Solución |
|---|---|---|
| El portal nunca aparece en ningún dispositivo | Sonda del SO bloqueada por la ACL de la pasarela | Añada las URL de sonda a la lista de permitidos antes de la autenticación |
| El portal aparece en iOS, pero no en Android | Falta la URL de sonda de Android en el jardín vallado | Añada connectivitycheck.gstatic.com al jardín vallado |
| Error de certificado HTTPS al cargar el portal | La pasarela está interceptando HTTPS en lugar de HTTP | Confíe únicamente en la interceptación de sondas HTTP |
| El portal se carga, pero no hay internet tras iniciar sesión | La pasarela no recibe el mensaje RADIUS Access-Accept | Verifique el secreto compartido, los puertos 1812/1813 y la IP del servidor RADIUS |
| El botón de inicio de sesión social falla de forma silenciosa | El dominio del proveedor de identidad no está en el jardín vallado | Añada los endpoints de Microsoft Entra ID / Google Workspace |
| Los invitados deben volver a autenticarse en cada visita | Duración de la sesión demasiado corta o almacenamiento en caché de MAC desactivado | Establezca la sesión en 24 horas y active el almacenamiento en caché de direcciones MAC |
| Fallos intermitentes en horas punta | Agotamiento del grupo de direcciones DHCP | Amplíe la subred y reduzca el tiempo de concesión |
ROI e impacto empresarial
Cada fallo del Captive Portal es un evento de captura de datos perdido. La plataforma de Guest WiFi de Purple convierte cada autenticación correcta en un registro de datos de origen (nombre, correo electrónico, datos demográficos y frecuencia de visitas) que se integra directamente en la automatización de marketing y los programas de fidelización.
Para un operador de hostelería como Premier Inn o Whitbread, una mejora del 10% en las tasas de éxito de autenticación del portal en una propiedad de 700 establecimientos se traduce directamente en decenas de miles de registros de suscripción voluntaria adicionales al mes. Esos registros impulsan campañas de correo electrónico personalizadas con tasas de apertura mensurablemente más altas que las listas compradas.
Para los operadores de comercio minorista, el Captive Portal es el punto de entrada para comprender el tiempo de permanencia de los compradores, la frecuencia de las visitas repetidas y el comportamiento en distintas ubicaciones. Purple ha recopilado 29.000 millones de puntos de datos (datos internos de Purple) en toda su red de establecimientos. Esos datos son tan buenos como la tasa de autenticación que los genera.
Para los centros de transporte como Manchester Airports Group, un WiFi de invitados fiable es una métrica de satisfacción de los pasajeros de la que se realiza un seguimiento a nivel de consejo de administración. Un portal que falla de forma intermitente durante los periodos de mayor salida genera quejas y perjudica el Net Promoter Score del establecimiento. Para entornos de atención médica, un WiFi para visitantes fiable reduce la presión sobre el personal clínico, que de otro modo tendría que atender las quejas de conectividad, y respalda las métricas de experiencia del paciente.
El SLA de tiempo de actividad del 99.999% de Purple garantiza que la propia plataforma en la nube no sea el punto de fallo. Cuando ocurren problemas con el portal, la causa casi siempre es la configuración local, la cual esta guía le capacita para resolver sin tener que abrir un ticket de soporte.
Referencias
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, noviembre de 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409
[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910
[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, febrero de 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview
[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, febrero de 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues
[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0
Definiciones clave
Captive Portal
Una página web que se muestra a un dispositivo que se une a una red antes de que se le conceda acceso completo a Internet. La puerta de enlace intercepta la prueba inicial de conectividad HTTP del dispositivo y la redirige a la URL del portal.
El mecanismo que hay detrás de cada página de inicio de sesión de WiFi para invitados, desde los vestíbulos de hoteles hasta los pasillos de estadios. Definido en el RFC 8910.
Walled garden
El conjunto de dominios y direcciones IP a los que un dispositivo puede acceder antes de completar la autenticación en el Captive Portal. El tráfico hacia los destinos del walled garden evita el requisito de autenticación.
Debe incluir las URL de prueba del sistema operativo, los puntos de conexión del proveedor de identidad, los dominios de CDN y los dominios del procesador de pagos. Un walled garden mal configurado es la segunda causa más común de fallos en el Captive Portal.
NCSI (Network Connectivity Status Indicator)
Una función de Windows que realiza pruebas en `msftconnecttest.com` para determinar si el dispositivo tiene acceso a Internet o si se encuentra detrás de un Captive Portal. Se define en la documentación de red de Microsoft.
Si la puerta de enlace bloquea esta prueba, Windows informa "Sin acceso a Internet" y nunca activa la vista web del Captive Portal. La solución consiste en añadir la URL de NCSI a la lista de permitidos previa a la autenticación.
HSTS (HTTP Strict Transport Security)
Una política de seguridad web definida en RFC 6797 que indica a los navegadores que rechacen las conexiones HTTP estándar y descarten cualquier certificado que no coincida exactamente con el dominio.
Evita que las puertas de enlace intercepten peticiones HTTPS para la redirección del Captive Portal. Los dominios principales, incluido google.com, están en la lista de precarga de HSTS en todos los navegadores principales.
Redirección HTTP 302
Un código de respuesta HTTP estándar que indica que el recurso solicitado se encuentra temporalmente en una URI diferente, proporcionada en la cabecera Location.
El mecanismo que utilizan las puertas de enlace para desviar la prueba de conectividad de un dispositivo a la página de inicio de sesión del Captive Portal. Algunas puertas de enlace utilizan HTTP 303 o HTTP 200 con un cuerpo de redirección en su lugar.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA), funcionando sobre UDP en los puertos 1812 (autenticación) y 1813 (contabilidad).
La plataforma en la nube de Purple actúa como servidor RADIUS. La puerta de enlace local (Meraki, Aruba, etc.) envía solicitudes de autenticación a los servidores RADIUS de Purple y actúa en función de la respuesta Access-Accept o Access-Reject.
Caché de direcciones MAC
El proceso de almacenar el identificador de hardware único de un dispositivo para reconocer los dispositivos que regresan y mantener el estado de la sesión sin requerir una nueva autenticación.
Permite la persistencia de la sesión en desconexiones breves y visitas repetidas dentro del intervalo de la sesión. Es esencial para entornos de hostelería donde los huéspedes se desplazan entre distintas zonas.
Redes basadas en la identidad
El modelo de arquitectura de Purple en el que las políticas de acceso, la asignación de VLAN y las analíticas se aplican en función de la identidad autenticada del usuario, en lugar de hacerlo únicamente por la dirección IP o MAC del dispositivo.
Permite un control de acceso granular, experiencias personalizadas y una atribución precisa del comportamiento de la red a usuarios individuales en hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.
Agotamiento de DHCP
Una condición en la que se han asignado todas las direcciones IP disponibles en un grupo DHCP, lo que impide que los nuevos dispositivos obtengan una dirección y, por tanto, que accedan al Captive Portal.
Común en recintos de alta densidad durante periodos de máxima afluencia. Se manifiesta de forma idéntica a un fallo del Captive Portal - el dispositivo se muestra conectado al SSID pero no tiene acceso a Internet. Se diagnostica comprobando la utilización de concesiones DHCP en el servidor.
Ejemplos prácticos
Un hotel de 200 habitaciones que utiliza puntos de acceso HPE Aruba informa de que los huéspedes con dispositivos Android no pueden acceder al Captive Portal, mientras que los usuarios de iOS se conectan sin problemas. El equipo de TI ha confirmado que la URL del portal es accesible desde la VLAN de gestión.
El equipo de TI debe inspeccionar el walled garden de autenticación previa en el controlador de HPE Aruba. Los dispositivos iOS sondean captive.apple.com, que probablemente ya está en la lista blanca. Los dispositivos Android sondean connectivitycheck.gstatic.com y clients3.google.com/generate_204. Es casi seguro que estos dominios de Google no están en el walled garden. Añadirlos a la lista de permitidos antes de la autenticación resuelve el problema. El equipo también debe añadir connectivitycheck.android.com como URL secundaria de sonda de Android. Tras actualizar el walled garden, reinicie los SSID afectados y realice la prueba en un dispositivo Android restablecido de fábrica para confirmar la solución, ya que el estado de red guardado en caché en un dispositivo conectado previamente podría enmascarar el resultado.
Una cadena de tiendas con 150 dispositivos Cisco Meraki MX informa de que los invitados se autentican en la página de inicio de Purple - el panel de Purple muestra inicios de sesión correctos - pero los invitados siguen sin tener acceso a internet después de completar el formulario. El problema afecta a todas las ubicaciones simultáneamente.
Dado que la plataforma en la nube de Purple muestra inicios de sesión correctos, el paso de autenticación en sí está funcionando. El fallo está en el paso de autorización: el dispositivo Meraki no recibe o no procesa el mensaje RADIUS Access-Accept de los servidores RADIUS de Purple. El equipo debe comprobar tres cosas en orden: primero, verificar que el secreto compartido de RADIUS en el panel de Meraki coincide exactamente con el secreto en el portal de Purple (una diferencia de un solo carácter provoca un fallo silencioso); segundo, confirmar que el tráfico UDP saliente en los puertos 1812 y 1813 está permitido desde el dispositivo Meraki hacia las direcciones IP del servidor RADIUS de Purple; tercero, comprobar si un cambio reciente en la red ha introducido una regla de firewall o una política NAT que bloquee este tráfico. Dado que el problema afecta a las 150 ubicaciones simultáneamente, la causa es probablemente un cambio en la política de firewall centralizada o un cambio en la dirección IP del servidor RADIUS de Purple que no se propagó a las configuraciones de Meraki.
Preguntas de práctica
Q1. Durante una conferencia importante en un recinto con capacidad para 5.000 personas, el equipo de TI recibe informes de que cientos de asistentes no pueden acceder al portal de WiFi para invitados. Los puntos de acceso muestran recuentos de asociación normales. El problema comenzó a los 45 minutos de iniciarse el evento. ¿Cuál es la causa más probable y cuál es la solución inmediata?
Sugerencia: El problema comenzó después de que el evento ya estuviera en marcha, no en el momento del lanzamiento. Piense en qué recurso se ve limitado a medida que se unen más dispositivos.
Ver respuesta modelo
La causa más probable es el agotamiento de la asignación del pool DHCP. A medida que los asistentes llegaban y se asociaban al SSID, el pool DHCP se llenó. Los nuevos dispositivos se asocian al punto de acceso pero no pueden obtener una dirección IP, por lo que nunca envían la prueba HTTP requerida para activar el Captive Portal. La solución inmediata es reducir el tiempo de concesión (lease time) de DHCP a 15 minutos (recuperando las direcciones de los dispositivos que se han marchado más rápido) y, si es posible, ampliar el pool añadiendo una segunda subred. La solución a largo plazo es dimensionar el pool DHCP para el número máximo de dispositivos simultáneos en el próximo evento, no para la media.
Q2. ¿Ha implementado Purple en puntos de acceso Ubiquiti UniFi en una cadena de tiendas físicas. La página de bienvenida se carga correctamente en todos los dispositivos. Los clientes completan el formulario de registro de correo electrónico y ven un mensaje de éxito. Pero cuando intentan navegar, no tienen acceso a internet. El panel de Purple muestra los inicios de sesión como correctos. ¿Qué comprueba primero?
Sugerencia: La plataforma en la nube ha registrado la autenticación. El fallo se encuentra en el paso de ejecución local.
Ver respuesta modelo
Dado que el panel de Purple muestra inicios de sesión correctos, el paso de autenticación en la nube se completó correctamente. El fallo está en el paso de autorización RADIUS: el controlador UniFi no recibe o no actúa en función del mensaje Access-Accept de los servidores RADIUS de Purple. Compruebe en este orden: (1) que el secreto compartido de RADIUS en el controlador UniFi coincide exactamente con el secreto en el panel de Purple; (2) que se permite el tráfico UDP saliente en los puertos 1812 y 1813 desde el controlador hacia las direcciones IP del servidor RADIUS de Purple; (3) que las direcciones IP del servidor RADIUS configuradas en el controlador UniFi están actualizadas (es posible que Purple las haya actualizado). Una captura de paquetes en el controlador confirmará si el mensaje Access-Accept está llegando.
Q3. Un responsable de TI de un hotel informa que los huéspedes que usan una VPN en sus dispositivos no pueden acceder al Captive Portal en absoluto. Los huéspedes sin VPN se conectan con normalidad. El hotel utiliza dispositivos Cisco Meraki MX. ¿Debería el equipo de TI cambiar la configuración del Captive Portal para adaptarse a los usuarios de VPN?
Sugerencia: Considere qué hace una VPN con el tráfico de red del dispositivo antes de que el Captive Portal pueda interceptarlo.
Ver respuesta modelo
No - la configuración del Captive Portal no necesita cambiar. Un cliente VPN cifra todo el tráfico del dispositivo antes de que este salga del mismo, incluida la prueba de conectividad HTTP. La puerta de enlace no puede interceptar el tráfico VPN cifrado, por lo que nunca emite la redirección 302. El huésped debe desactivar su VPN, completar la autenticación del Captive Portal y luego volver a activar la VPN. Esta es una limitación arquitectónica fundamental de los sistemas de Captive Portal y las VPN, no un error de configuración. El equipo de TI debe añadir una nota a las instrucciones de WiFi para huéspedes aconsejando a los usuarios de VPN que la desactiven antes de conectarse.
Preguntas frecuentes
Why does the captive portal redirect fail to open automatically on mobile devices?
Mobile operating systems (iOS, Android, Windows) rely on unauthenticated HTTP probes to vendor endpoints (such as captive.apple.com or connectivitycheck.gstatic.com/generate_204). If the network gateway does not intercept port 80 traffic with a clean HTTP 302 redirect, or if DNS queries for those probe domains are dropped before authentication, the Captive Network Assistant (CNA) will not launch.
Why does the 'captive portal login keeps stopping' error occur on Android devices?
The 'captive portal login keeps stopping' error on Android occurs when the system WebView crashes during redirection or when the gateway drops the generate_204 HTTP probe midway through authentication. Clearing the cache of the Android System WebView or Chrome app, disabling randomized MAC addresses for the venue SSID, and navigating manually to an unencrypted HTTP probe address resolves the crash loop.
How do unencrypted HTTP sites like neverssl.com force a captive portal login screen to load?
Because modern browsers enforce HTTP Strict Transport Security (HSTS) on encrypted domains like google.com, wireless gateways cannot intercept HTTPS traffic without triggering browser certificate warnings. Navigating to an unencrypted HTTP destination such as http://neverssl.com or http://1.1.1.1 sends a plaintext request that the gateway can safely intercept with an HTTP 302 redirect to the login splash page.
Why do Android devices show 'Sign into network' errors or fail the generate_204 probe?
Android devices query clients3.google.com/generate_204 and connectivitycheck.gstatic.com. If the wireless controller or walled garden blocks access to Google IP addresses without intercepting the HTTP request with a 302 redirect, Android detects a connection error or assumes an isolated intranet, suppressing the portal prompt. Whitelisting the required probe domains or ensuring transparent HTTP redirection resolves this.
How do you prevent HTTPS certificate warnings when intercepting captive portal traffic?
When a guest browser navigates to an HTTPS domain prior to login, intercepting the TLS handshake triggers severe browser security warnings (such as NET::ERR_CERT_COMMON_NAME_INVALID) due to HSTS and certificate mismatch. Enterprise networks prevent this by leaving HTTPS traffic undisturbed and relying exclusively on plaintext HTTP probe interception to trigger the operating system's native captive portal browser.
What causes RADIUS authentication timeouts during captive portal guest login?
RADIUS timeouts occur when the wireless access point or controller fails to receive a RADIUS Access-Accept packet from the authentication server within the timeout window (typically 5 seconds). Common causes include outbound UDP ports 1812 and 1813 being filtered by perimeter firewalls, mismatched RADIUS shared secrets, or asymmetric routing between the access point and the cloud RADIUS service.
How does RFC 8910 (Captive Portal API) resolve modern captive portal connection issues?
RFC 8910 standardizes captive portal discovery via DHCP Option 114 and IPv6 Router Advertisements. Rather than intercepting DNS queries or HTTP packets, the network directly advertises the captive portal API endpoint URL to connecting client devices. Modern operating systems query this API directly, eliminating HSTS certificate collisions, DNS hijacking latency, and CNA browser rendering bugs.
How does MAC address randomisation affect captive portal reconnection?
iOS 14+ and Android 10+ rotate private MAC addresses periodically or when re-associating with SSIDs. If a guest network tracks sessions solely by physical MAC address, returning visitors are forced to authenticate repeatedly. Enterprise platforms like Purple solve this by tying session authorisation to user identity tokens and Passpoint (Hotspot 2.0) profiles rather than transient hardware MACs.
How does Purple resolve captive portal redirect failures across multi-vendor networks?
Purple operates as a hardware-agnostic cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Fortinet, and UniFi hardware. By automating walled garden configurations, managing trusted SSL redirect domains, and providing high-availability cloud RADIUS clusters with sub-second failover, Purple eliminates captive portal redirect drops and delivers reliable guest onboarding.
Continúe leyendo esta serie
El portal de invitados Ubiquiti UniFi no redirige: causas y soluciones
Esta guía aísla los fallos de redirección del portal de invitados de UniFi analizando en secuencia el estado del invitado, la redirección, la ruta de preautorización y la autorización del controlador. Ofrece a los equipos de TI de los establecimientos un método estructurado para resolver la confusión entre red de invitados y Hotspot, integraciones con portales externos, los requisitos actuales de las cuentas de UniFi OS y pruebas de aislamiento de DNS.
La página splash de Cisco Meraki no funciona: diagrama de flujo para la resolución de problemas
Esta práctica guía de mantenimiento identifica dónde ha fallado un flujo de splash de Cisco Meraki: autorización del cliente, inicio de redirección HTTP, accesibilidad de walled-garden o inicio de sesión RADIUS. Proporciona a los equipos de TI de los establecimientos una ruta de evidencias controlada para restablecer el WiFi de invitados sin realizar cambios drásticos en una red en producción.
Guía de configuración de WiFi para invitados empresariales: segmentación por VLAN, seguridad y Captive Portals
Esta guía técnica muestra a los equipos de TI cómo configurar el WiFi de invitados como un servicio controlado de acceso a internet, mediante segmentación por VLAN, políticas de firewall y un Captive Portal. También explica cómo los formularios de registro y los controles de incorporación de Purple admiten una experiencia de visitante proporcionada sin debilitar el límite en torno a los sistemas de personal, pago y operativos.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.