Resolución de problemas de redirección de Captive Portal: Solución de fallas de conexión de WiFi para invitados

Cuando los invitados se conectan a su WiFi pero no pueden acceder a internet, la causa casi siempre es un Captive Portal mal configurado, no una falla de hardware. Esta guía proporciona una referencia técnica profunda para gerentes de TI, arquitectos de red y CTOs para diagnosticar y resolver toda la cadena de fallas: desde pruebas de conectividad a nivel de sistema operativo y conflictos de certificados HSTS hasta brechas de autorización RADIUS y agotamiento de DHCP. Mapea cada modo de falla con una solución concreta y muestra cómo la capa en la nube agnóstica de hardware de Purple elimina estos problemas en implementaciones de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet.

📖 9 min de lectura📝 2,237 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del podcast

PRESENTADOR (INGLÉS DEL REINO UNIDO, TONO DE CONSULTOR CONFIADO):

Bienvenido al Resumen Técnico de Purple. Hoy abordaremos uno de los dolores de cabeza más persistentes en las redes empresariales: la falla de redirección de Captive Portal. Cuando su WiFi de invitados se muestra como conectado pero no hay acceso a internet, sus visitantes se frustran, su mesa de ayuda se inunda y su estrategia de captura de datos se detiene por completo. En este resumen, desglosaremos la arquitectura técnica de los captive portals, exploraremos por qué los sistemas operativos y navegadores modernos a menudo los bloquean, y le daremos estrategias de implementación concretas para resolver estos problemas de forma permanente.

[PAUSA]

Pongamos el escenario. Ha implementado puntos de acceso Cisco Meraki o HPE Aruba en cien ubicaciones minoristas. El hardware es sólido. Pero los invitados se quejan de que no pueden acceder a internet. Seleccionan el SSID, su dispositivo muestra el ícono de WiFi, pero la página de inicio nunca aparece. O peor aún, ven un error de certificado SSL aterrador.

¿Por qué sucede esto? Se debe a cómo los sistemas operativos detectan la conectividad a internet. Cuando un dispositivo se conecta a una red, envía una sonda HTTP a una URL conocida. Para iOS, es captive.apple.com. Para Android, es connectivitycheck.gstatic.com. Windows utiliza msftconnecttest.com. Si el dispositivo recibe una respuesta HTTP 200 OK estándar, asume que tiene acceso directo a internet. Si la puerta de enlace de la red intercepta esa solicitud y responde con una redirección HTTP 302 a una URL diferente, el sistema operativo sabe que está detrás de un Captive Portal. Luego, abre un pseudonavegador para cargar la página de inicio.

La falla generalmente ocurre en este punto de interceptación.

[PAUSA]

El primer punto importante de falla es la sonda del Indicador de Estado de Conectividad de Red, o NCSI. Si su firewall o puerta de enlace bloquea estas solicitudes HTTP no cifradas, el sistema operativo nunca recibe la redirección 302. Simplemente asume que la red no funciona. Para solucionar esto, debe asegurarse de que sus listas de control de acceso previas a la autenticación permitan el tráfico HTTP a esas URL específicas de detección del sistema operativo.

El segundo problema, y cada vez más común, es la Seguridad de Transporte Estricta HTTP, o HSTS. Los navegadores modernos exigen HTTPS para los dominios principales. Si un usuario se conecta a su WiFi e intenta abrir google.com de inmediato, su navegador insistirá en una conexión cifrada. Cuando su puerta de enlace intercepta esa solicitud HTTPS e intenta redirigirla al Captive Portal, el navegador detecta un ataque de intermediario. El certificado presentado por su puerta de enlace no coincide con google.com. El resultado es un bloqueo total. El usuario ve una advertencia de seguridad y no puede proceder a la página de inicio de sesión.

La solución aquí es doble. Primero, confíe en los mecanismos de detección a nivel de sistema operativo que acabamos de discutir. Utilizan HTTP no cifrado específicamente para evitar este desajuste de certificados. Segundo, asegúrese de que la configuración de su walled garden sea impecable.

¿Qué es un walled garden? Es la lista de dominios y direcciones IP a las que un usuario invitado puede acceder antes de autenticarse. Si utilizas el inicio de sesión social a través de Microsoft Entra ID o Google Workspace, o si procesas pagos a través de Stripe, esos dominios deben estar en tu walled garden. Si no están, es posible que la página de bienvenida cargue, pero el proceso de autenticación fallará de forma silenciosa.

[PAUSE]

Veamos un escenario del mundo real. McDonald's atiende a millones de clientes en miles de ubicaciones. Utilizan Purple para gestionar su WiFi para invitados. Si el tiempo de espera de la sesión se configura demasiado corto, un cliente que revisa su teléfono durante una comida larga podría verse obligado a volver a autenticarse varias veces. Eso arruina la experiencia. Recomendamos configurar la duración de las sesiones en 24 horas para entornos de hotelería y retail, utilizando el almacenamiento en caché de direcciones MAC para reconocer los dispositivos recurrentes sin problemas.

[PAUSE]

Ahora algunas recomendaciones de implementación. Al implementar un Captive Portal, debes configurar tu puerta de enlace para interceptar el tráfico DNS y HTTP correctamente. Si utilizas una superposición en la nube como Purple, tu hardware local, ya sea Juniper Mist o Ubiquiti UniFi, debe ser capaz de comunicarse con los servidores RADIUS de Purple.

Aquí hay un error crítico: la resolución DNS. Si el dispositivo de un invitado no puede resolver el nombre de host de tu Captive Portal, la redirección falla. Asegúrate de que tu servidor DHCP entregue direcciones DNS confiables y verifica que tu puerta de enlace permita que las consultas DNS pasen a través del walled garden.

Además, considera el entorno físico. Los lugares de alta densidad como estadios o centros de transporte, como Manchester Airports Group, manejan miles de intentos de conexión simultáneos. Si tu grupo de DHCP local se agota, los nuevos dispositivos se conectarán al punto de acceso pero no recibirán una dirección IP. Ni siquiera llegarán a la fase del Captive Portal. Siempre calcula el tamaño de tus subredes de manera adecuada para la capacidad máxima y utiliza tiempos de concesión de DHCP cortos para redes de visitantes transitorios.

[PAUSE]

Ahora una sesión de preguntas y respuestas rápidas basada en los casos de soporte más comunes.

Pregunta uno: ¿Por qué el portal funciona en iPhones pero falla en dispositivos Android?

Respuesta: Es casi seguro que sea un problema de walled garden. Es probable que hayas incluido en la lista de permitidos captive.apple.com pero hayas omitido connectivitycheck.gstatic.com. Actualiza tus listas de control de acceso previas a la autenticación.

Pregunta dos: Los invitados se autentican con éxito, pero siguen sin tener internet. ¿Por qué?

Respuesta: Verifica tu configuración de RADIUS. Es probable que la puerta de enlace no esté recibiendo el mensaje Access-Accept del servidor RADIUS, o que las reglas del firewall posteriores a la autenticación estén bloqueando el tráfico. Verifica el secreto compartido y asegúrate de que los puertos 1812 y 1813 estén abiertos.

Pregunta tres: ¿Podemos usar HTTPS para la redirección inicial y así evitar advertencias de seguridad?

Respuesta: No. No se puede interceptar una solicitud HTTPS sin causar un error de certificado, a menos que instales un certificado raíz en cada dispositivo invitado, lo cual es imposible para WiFi público. Debes confiar en las sondas HTTP no cifradas del sistema operativo para activar el portal.

[PAUSE]

En resumen: las fallas de Captive Portal raras veces son fallas de hardware. Casi siempre son discrepancias de configuración en el flujo de redirección, el walled garden o la configuración de DNS.

Punto uno: Asegúrese de que las URL de detección de OS sean accesibles antes de la autenticación.

Punto dos: Configure su walled garden para incluir todos los proveedores de identidad y redes de distribución de contenido necesarios.

Punto tres: Verifique la comunicación RADIUS entre su gateway y su plataforma de autenticación.

Punto cuatro: Dimensione sus alcances DHCP para la densidad máxima.

Al dominar estos elementos, elimina la fricción de conexión. Deja de frustrar a sus visitantes y comienza a capturar los datos de primera mano que necesita para impulsar la lealtad y los ingresos. Las redes basadas en identidad de Purple simplifican este proceso, proporcionando una capa de nube agnóstica de hardware que maneja la complejidad de RADIUS, captive portals y analítica de manera fluida en 80,000 sitios activos en todo el mundo.

Gracias por acompañarnos en este Purple Technical Briefing. Para obtener guías de configuración y diagramas de arquitectura más detallados, visite purple.ai.

Puntos clave

✓Las fallas en el Captive Portal casi siempre son problemas de configuración, no fallas de hardware. La cadena de redireccionamiento tiene seis pasos y cualquiera de ellos puede fallar.
✓Cada OS envía una URL de prueba HTTP diferente para detectar Captive Portals. Si su gateway bloquea alguna de estas pruebas, ese OS nunca verá la página de inicio.
✓Nunca intente interceptar tráfico HTTPS para el redireccionamiento del Captive Portal. HSTS provoca errores graves de certificado. Confíe en las pruebas HTTP no cifradas del OS.
✓El walled garden debe incluir las URL de prueba de los OS, dominios de proveedores de identidad (Microsoft Entra ID, Google Workspace), recursos de CDN y dominios de procesadores de pago antes de la autenticación.
✓La autenticación (completar el formulario de inicio de sesión) y la autorización (el gateway abriendo la regla de firewall) son pasos separados. Si el portal muestra éxito pero no hay Internet, la comunicación RADIUS entre el gateway y los servidores de Purple está rota.
✓En entornos de alta densidad, el agotamiento de DHCP produce síntomas idénticos a los de una falla del Captive Portal. Dimensione su pool de DHCP para la cantidad pico de dispositivos simultáneos y use tiempos de concesión cortos.
✓Pruebe cada implementación en iOS, Android y Windows antes de la entrega final. Las fallas específicas de un OS indican omisiones en el walled garden, no errores fundamentales de configuración.

Resumen ejecutivo

La consulta "guest WiFi connected but no internet" es uno de los tickets de soporte más comunes en redes empresariales. El síntoma es visible para cada visitante; 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 splash page o puerta de enlace de hotspot) 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 cualquier paso de esa cadena se rompe - sondas bloqueadas, conflictos de HSTS, brechas en el walled garden, fallas de RADIUS o agotamiento de DHCP - el invitado no ve más que un ícono de WiFi conectado y sin internet. Esta guía le guiará a través de cada modo de falla, la mecánica del protocolo subyacente y los cambios de configuración que los resuelven. Purple opera en más de 80,000 sitios en vivo, procesando 440 millones de inicios de sesión anualmente (datos internos de Purple, 2024), y los patrones descritos aquí representan las causas raíz más frecuentes que vemos en implementaciones de hospitalidad, retail, transporte y sector público.

Inmersión técnica profunda

Cómo funciona realmente la detección de Captive Portal

Cada sistema operativo principal incluye un mecanismo integrado para detectar si una red requiere autenticación antes de otorgar acceso a internet. Comprender estos mecanismos es la base de toda resolución de problemas de Captive Portal.

Cuando un dispositivo se asocia con 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 puerta de enlace intercepta una de estas solicitudes y devuelve un redireccionamiento 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 splash page. Si la sonda se bloquea por completo, el SO informa "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 simples a un dominio y que descarten cualquier certificado que no coincida exactamente. Los dominios principales, incluidos google.com, facebook.com y la mayoría de los sitios bancarios, se encuentran 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. El gateway no puede interceptar una solicitud HTTPS y redireccionarla de forma limpia; tendría que presentar un certificado para google.com, el cual no posee. El navegador detecta la discrepancia del certificado y muestra una advertencia de seguridad persistente. El invitado no puede avanzar a la página de inicio de sesión.

La arquitectura correcta depende por completo de las pruebas HTTP a nivel de sistema operativo descritas anteriormente. Esas pruebas utilizan HTTP simple hacia URLs que no son de HSTS específicamente para que los gateways puedan interceptarlas y redireccionarlas sin conflictos de certificados. Su gateway debe interceptar estas pruebas HTTP y emitir el redireccionamiento 302. No intente interceptar el tráfico HTTPS para fines de Captive Portal.

El walled garden

Un walled garden es el conjunto de dominios y direcciones IP que un dispositivo puede alcanzar antes de autenticarse. Si el walled garden es demasiado limitado, la splash page puede cargar pero la autenticación fallará. 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 endpoints de autenticación deben estar en el walled garden.
Dominios de CDN y recursos: Su splash page puede cargar CSS, JavaScript o fuentes desde una red de distribución de contenido. Si esos dominios de CDN están bloqueados, la página se renderizará con errores.
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 el gateway se conecte a los servidores RADIUS y a los endpoints 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 gateway 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 de Access-Accept o Access-Reject. El gateway actúa en función de ese mensaje abriendo o manteniendo cerrada la regla de firewall que otorga acceso a internet.

La brecha de autorización - donde un invitado inicia sesión correctamente en la splash page pero sigue sin tener internet - casi siempre significa que el gateway 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 el gateway.

Agotamiento de DHCP en entornos de alta densidad

En estadios, centros de conferencias y centros de transporte, el agotamiento de DHCP es una causa frecuente de fallas de conexión que parece idéntica a un problema de Captive Portal. Si el pool de 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 sedes como Manchester Airports Group (MAG), donde los volúmenes de pasajeros tienen picos muy pronunciados, las subredes deben dimensionarse para el número máximo de dispositivos simultáneos, no para el promedio. Los tiempos de arrendamiento de DHCP cortos (15 - 30 minutos para redes de visitantes transitorios) recuperan rápidamente las direcciones de los dispositivos que se retiran.

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 Networks o Fortinet - cuando se integra con la superposición en la nube de Purple.

Paso 1: Configurar el SSID para 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 inicio local en el propio controlador.

Paso 2: Definir el walled garden. Agregue los siguientes dominios como mínimo: el portal de Purple y los endpoints de RADIUS (consulte su guía de integración de hardware), las URL de sonda de detección de SO enumeradas 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 inicio.

Paso 3: Configurar RADIUS. Ingrese 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 firewall local permita UDP saliente en estos puertos.

Paso 4: Establecer los parámetros de sesión. Para hotelerí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 sola visita. Para entornos de alta seguridad, son apropiadas sesiones más cortas con reautenticación.

Paso 5: Dimensionar su alcance de DHCP. Calcule el número máximo de dispositivos simultáneos para su sede en su capacidad máxima. Un restaurante de 500 asientos puede ver 800 dispositivos durante un servicio concurrido. Dimensione el pool de DHCP a 1,000 direcciones con un tiempo de arrendamiento de 30 minutos.

Paso 6: Probar en diferentes sistemas operativos. Después de la configuración, pruebe el flujo completo en dispositivos iOS, Android y Windows. Cada uno utiliza una URL de sonda y una implementación de WebView diferentes. Una falla en una plataforma mientras que las otras funcionan es casi siempre una brecha en el walled garden.

Mejores prácticas

Las siguientes recomendaciones reflejan estándares y patrones en las más de 80,000 implementaciones en sedes de Purple.Separe las redes de invitados y del personal. Utilice 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 e IoT WiFi para conocer los detalles de la arquitectura.

Utilice una VLAN dedicada para invitados. 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 los datos de tarjetas de pago transitan por la red.

Implemente opciones de consentimiento consciente. El GDPR exige que la recopilación de datos en el portal cautivo 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 separadas para cada propósito. Esto no es opcional para los establecimientos que operan en el Reino Unido o la UE.

Monitoree la salud del portal de forma proactiva. La plataforma WiFi Analytics de Purple proporciona visibilidad en tiempo real de las tasas de éxito de inicio de sesión, el recuento de sesiones y los fallos de autenticación. Una caída repentina en los inicios de sesión exitosos 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 consistente. La página de inicio es la primera interacción de marca que un invitado tiene con su red. Un portal bien diseñado aumenta las tasas de registro 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 pautas de diseño.

Resolución de problemas y mitigación de riesgos

Cuando se reporte un problema con el portal cautivo, siga esta secuencia de diagnóstico antes de realizar cualquier cambio de configuración.

Aísle el punto de falla. 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 en el walled garden para la URL de prueba 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 portal cautivo. Si la resolución de DNS falla, el dispositivo no puede acceder a la página de inicio incluso si el redireccionamiento se emite correctamente. Verifique que su servidor DHCP esté distribuyendo direcciones DNS confiables y que la puerta de enlace permita consultas DNS en el estado previo a la autenticación.

Capture el redireccionamiento. Utilice las herramientas de desarrollo del navegador (F12) o una captura de paquetes para observar el intercambio HTTP. Debería ver la solicitud de prueba del sistema operativo seguida de una respuesta HTTP 302 que contiene la URL del portal. Si ve la solicitud de prueba pero no la respuesta 302, la puerta de enlace no está interceptando correctamente. Si no ve ninguna solicitud de prueba, el sistema operativo ya ha determinado que tiene acceso a internet (posiblemente por un estado guardado en caché) y no está enviando la prueba. Verifique la comunicación RADIUS. En la puerta de enlace, revise los registros de contabilidad RADIUS. Una autenticación exitosa produce un registro de Accounting-Start. Si no ve registros de contabilidad después de que un invitado inicia sesión, la comunicación RADIUS está rota. Verifique el secreto compartido, la IP del servidor y las reglas del firewall.

Verifique la utilización del direccionamiento DHCP. En el servidor DHCP, revise el recuento de arrendamientos actual frente al tamaño del pool. Si la utilización supera el 90%, se está acercando al agotamiento. Amplíe el pool o reduzca el tiempo de arrendamiento de inmediato.

La siguiente tabla mapea los síntomas más comunes con sus causas raíz y la solución correspondiente.

Síntoma	Causa raíz más probable	Solución
El portal nunca aparece en ningún dispositivo	Sonda del SO bloqueada por la ACL de la puerta de enlace	Agregue las URL de sonda a la lista de permitidos de preautenticación
El portal aparece en iOS, no en Android	Falta la URL de la sonda de Android en el walled garden	Agregue `connectivitycheck.gstatic.com` al walled garden
Error de certificado HTTPS al cargar el portal	Puerta de enlace interceptando HTTPS en lugar de HTTP	Confíe únicamente en la interceptación de la sonda HTTP
El portal carga, no hay internet después de iniciar sesión	RADIUS Access-Accept no recibido por la puerta de enlace	Verifique el secreto compartido, los puertos 1812/1813 y la IP del servidor RADIUS
El botón de inicio de sesión social falla silenciosamente	El dominio del proveedor de identidad no está en el walled garden	Agregue 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, habilite el almacenamiento en caché de direcciones MAC
Fallas intermitentes en horas pico	Agotamiento del pool DHCP	Amplíe la subred, reduzca el tiempo de arrendamiento

ROI e impacto comercial

Cada falla en el Captive Portal es un evento de captura de datos perdido. La plataforma de Guest WiFi de Purple convierte cada autenticación exitosa 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 hospitalidad como Premier Inn o Whitbread, una mejora del 10% en las tasas de éxito de autenticación del portal en un patrimonio de 700 propiedades se traduce directamente en decenas de miles de registros de suscripción voluntaria adicionales por mes. Esos registros impulsan campañas de correo electrónico personalizadas con tasas de apertura mediblemente más altas que las listas compradas.

Para los operadores de retail , el Captive Portal es el punto de partida para comprender el tiempo de permanencia de los compradores, la frecuencia de las visitas repetidas y el comportamiento entre ubicaciones. Purple ha recopilado 29,000 millones de puntos de datos (datos internos de Purple) a través de 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 confiable para invitados es una métrica de satisfacción del pasajero que se monitorea a nivel de junta directiva. Un portal que falla de forma intermitente durante los períodos pico de salida genera quejas y daña el Net Promoter Score del establecimiento. Para entornos de atención médica , un WiFi para visitantes confiable reduce la presión sobre el personal clínico que de otro modo tendría que atender quejas de conectividad, y respalda las métricas de experiencia del paciente.

El SLA de disponibilidad del 99.999% de Purple garantiza que la capa de red en la nube en sí misma no sea el punto de falla. Cuando ocurren problemas con el portal, la causa casi siempre es la configuración local - la cual esta guía le equipa para resolver sin necesidad de generar 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 presenta a un dispositivo que se une a una red antes de que se le conceda acceso total a internet. El gateway intercepta la sonda de conectividad HTTP inicial del dispositivo y la redirige a la URL del portal.

El mecanismo detrás de cada página de inicio de sesión de WiFi para invitados, desde vestíbulos de hoteles hasta pasillos de estadios. Definido en el RFC 8910.

Walled garden

El conjunto de dominios y direcciones IP que un dispositivo puede alcanzar 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 sondeo del SO, los endpoints de proveedores de identidad, los dominios CDN y los dominios de procesadores de pago. Un walled garden mal configurado es la segunda causa más común de fallas en el Captive Portal.

NCSI (Network Connectivity Status Indicator)

Una función de Windows que sondea `msftconnecttest.com` para determinar si el dispositivo tiene acceso a internet o si se encuentra detrás de un Captive Portal. Definido en la documentación de redes de Microsoft.

Si el gateway bloquea este sondeo, Windows reporta "No internet access" y nunca activa la WebView del Captive Portal. La solución es agregar 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 conexiones HTTP simples y que descarten cualquier certificado que no coincida exactamente con el dominio.

Evita que los gateways intercepten solicitudes HTTPS para la redirección al Captive Portal. Los dominios principales, incluyendo google.com, están en la lista de precarga de HSTS en todos los navegadores importantes.

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 el encabezado Location.

El mecanismo que utilizan los gateways para desviar el sondeo de conectividad de un dispositivo a la página de inicio de sesión del Captive Portal. Algunos gateways 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), operando sobre UDP en los puertos 1812 (autenticación) y 1813 (contabilidad).

La plataforma en la nube de Purple actúa como el servidor RADIUS. El gateway 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 de la ventana de sesión. Esencial para entornos de hospitalidad donde los huéspedes se mueven entre diferentes áreas.

Redes basadas en identidad

El modelo de arquitectura de Purple en el cual 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 basarse únicamente en 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 lo tanto, que alcancen el Captive Portal.

Común en recintos de alta densidad durante períodos de máxima afluencia. Se manifiesta de forma idéntica a una falla de Captive Portal - el dispositivo se muestra conectado al SSID pero no tiene internet. Se diagnostica verificando la utilización de concesiones DHCP en el servidor.

Ejemplos resueltos

Un hotel de 200 habitaciones que utiliza puntos de acceso HPE Aruba informa 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 prueban captive.apple.com, que probablemente ya está en la lista de permitidos. Los dispositivos Android prueban connectivitycheck.gstatic.com y clients3.google.com/generate_204. Es casi seguro que estos dominios de Google no estén en el walled garden. Agregarlos a la lista de permitidos de autenticación previa resuelve el problema. El equipo también debe agregar connectivitycheck.android.com como una URL de prueba secundaria de Android. Después de actualizar el walled garden, reinicie los SSIDs afectados y realice pruebas 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 previamente conectado puede enmascarar el resultado.

Comentario del examinador: Este escenario ilustra la naturaleza específica de cada sistema operativo en la detección de un Captive Portal. Cada plataforma utiliza diferentes URLs de prueba, y un walled garden configurado solo para un sistema operativo producirá exactamente este patrón de falla asimétrico. La señal de diagnóstico clave es que la falla es específica del tipo de dispositivo, no intermitente en todos los dispositivos. Las fallas intermitentes en todos los dispositivos apuntarían en su lugar a problemas de RADIUS o DHCP.

Una cadena de retail con 150 dispositivos Cisco Meraki MX informa que los invitados se autentican en la página de inicio de Purple - el portal de Purple muestra inicios de sesión exitosos - pero los invitados aún no tienen acceso a internet después de completar el formulario. El problema afecta a todas las ubicaciones simultáneamente.

Debido a que la plataforma en la nube de Purple muestra inicios de sesión exitosos, el paso de autenticación funciona correctamente. La falla está en el paso de autorización: el dispositivo Meraki no está recibiendo o no está actuando según el mensaje RADIUS Access-Accept de los servidores RADIUS de Purple. El equipo debe verificar tres cosas en secuencia: primero, verificar que el secreto compartido de RADIUS en el panel de Meraki coincida exactamente con el secreto en el portal de Purple (una diferencia de un solo carácter causa una falla silenciosa); 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, verificar si un cambio reciente en la red introdujo una regla de firewall o una política de NAT que bloquee este tráfico. Debido a que el problema afecta a las 150 ubicaciones simultáneamente, la causa probablemente sea 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.

Comentario del examinador: La información de diagnóstico crítica aquí es que el hecho de que el portal de Purple muestre inicios de sesión exitosos significa que el paso de autenticación en la nube se completó. Por lo tanto, la falla está en el paso de aplicación local: el mensaje RADIUS desde la nube hacia la puerta de enlace. Esta distinción entre la autenticación del lado de la nube y la autorización del lado local es fundamental para resolver problemas en cualquier implementación de Captive Portal que utilice una arquitectura de capa en la nube.

Preguntas de práctica

Q1. Durante una conferencia importante en un recinto con capacidad para 5,000 personas, el equipo de TI recibe reportes 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 iniciado 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 estaba en marcha, no al inicio. Considere qué recurso se limita a medida que se unen más dispositivos.

Ver respuesta modelo

La causa más probable es el agotamiento del pool de DHCP. A medida que los asistentes llegaron y se asociaron al SSID, el pool de 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 de DHCP (lease time) a 15 minutos (para recuperar más rápido las direcciones de los dispositivos que ya se retiraron) y, si es posible, expandir el pool agregando una segunda subred. La solución a largo plazo es dimensionar el pool de DHCP para la cantidad máxima de dispositivos simultáneos en el próximo evento, no para el promedio.

Q2. Ha implementado Purple en puntos de acceso Ubiquiti UniFi en una cadena de retail. La página de inicio carga correctamente en todos los dispositivos. Los clientes completan el formulario de captura de correo electrónico y ven un mensaje de éxito. Sin embargo, al intentar navegar, no tienen acceso a Internet. El dashboard de Purple muestra los inicios de sesión como exitosos. ¿Qué debe verificar primero?

Sugerencia: La plataforma en la nube ha registrado la autenticación. La falla se encuentra en el paso de aplicación local.

Ver respuesta modelo

Dado que el dashboard de Purple muestra inicios de sesión exitosos, el paso de autenticación en la nube se completó correctamente. La falla está en el paso de autorización RADIUS: el controlador UniFi no recibe o no procesa el mensaje Access-Accept de los servidores RADIUS de Purple. Verifique en este orden: (1) que el secreto compartido RADIUS en el controlador UniFi coincida exactamente con el secreto en el dashboard de Purple; (2) que el tráfico UDP saliente en los puertos 1812 y 1813 esté permitido 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. El administrador 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 normalmente. 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 lo que 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 desde el dispositivo antes de que salga de este, incluida la prueba de conectividad HTTP. El gateway no puede interceptar el tráfico VPN cifrado, por lo que nunca genera el redireccionamiento 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 Captive Portals y las VPN, no un error de configuración. El equipo de TI debe agregar una nota en las instrucciones de WiFi para huéspedes aconsejando a los usuarios de VPN que la desactiven antes de conectarse.

Continúe leyendo esta serie

Resolución de problemas en WiFi público: Cómo solucionar 'Conectado, sin internet' y fallas de redirección a la página de bienvenida

Esta guía de referencia técnica autorizada explica la mecánica subyacente de la detección de Captive Portal y detalla los seis modos principales de falla que evitan que el WiFi de invitados se conecte. Proporciona a los gerentes de TI y arquitectos de red un marco práctico de resolución de problemas para resolver problemas de redirección HTTP, conflictos de DNS y desafíos de aleatorización de MAC.

Las 10 principales causas de tiempos de espera de DHCP (DHCP Timeouts) en redes inalámbricas de alta densidad

Esta guía de referencia técnica autorizada identifica las diez principales causas de los tiempos de espera de DHCP en redes inalámbricas de alta densidad y proporciona estrategias de remediación prácticas y neutrales respecto al proveedor. Diseñada para líderes de TI sénior, arquitectos de redes y directores de operaciones de recintos, cubre principios de ingeniería a profundidad, flujos de trabajo de implementación paso a paso y resultados comerciales medibles. Aprenda a eliminar los cuellos de botella de conexión y optimice su infraestructura inalámbrica para ofrecer una conectividad sin interrupciones en entornos empresariales exigentes.

Uso de la captura de paquetes (PCAP) para diagnosticar el bajo rendimiento de WiFi

Esta guía de referencia técnica proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de recintos una metodología estructurada a nivel de paquetes para diagnosticar y resolver el bajo rendimiento de WiFi empresarial mediante el análisis de captura de paquetes (PCAP). Al diseccionar tramas 802.11 sin procesar —incluidas las tasas de retransmisión, la utilización del tiempo de aire y los metadatos de la capa física—, los equipos pueden aislar con precisión los cuellos de botella de la capa de RF de los problemas de la red cableada o de las aplicaciones. Aplicable en recintos de alta densidad, como hoteles, cadenas de retail, estadios y centros de conferencias, esta guía ofrece flujos de trabajo de diagnóstico prácticos, casos de estudio del mundo real y pasos de remediación de configuración para recuperar la capacidad de la red y proteger la experiencia del huésped.