Troubleshooting Captive Portal Redirects: Resolving Guest WiFi Connection Failures

Cuando los invitados se conectan a su WiFi pero no pueden acceder a internet, la causa casi siempre es un redireccionamiento del captive portal mal configurado, no un fallo de hardware. Esta guía proporciona una referencia técnica detallada para directores de TI, arquitectos de red y CTO para diagnosticar y resolver toda la cadena de fallos: desde sondas de conectividad a nivel de sistema operativo y conflictos de certificados HSTS hasta brechas de autorización RADIUS y agotamiento de DHCP. Relaciona cada modo de fallo con una solución concreta y muestra cómo la capa en la nube agnóstica al hardware de Purple elimina estos problemas en despliegues de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet.

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

Escuchar esta guía

Ver transcripción del podcast

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

Bienvenido a la sesión técnica de Purple. Hoy abordamos uno de los dolores de cabeza más persistentes en las redes empresariales: el fallo de redirección del Captive Portal. Cuando el WiFi de invitados se muestra como conectado pero no hay acceso a internet, los visitantes se frustran, el servicio de soporte se satura y la estrategia de captura de datos se detiene por completo. En esta sesión, desglosaremos la arquitectura técnica de los portales cautivos, analizaremos por qué los sistemas operativos y los navegadores modernos suelen bloquearlos y le ofreceremos estrategias de implementación concretas para resolver estos problemas de forma permanente.

[PAUSA]

Pongámonos en situación. Ha desplegado puntos de acceso Cisco Meraki o HPE Aruba en un centenar de establecimientos comerciales. El hardware es sólido. Sin embargo, los invitados se quejan de que no pueden acceder a internet. Seleccionan el SSID, su dispositivo muestra el icono de WiFi, pero la página de bienvenida nunca aparece. O peor aún, ven un mensaje de error de certificado SSL alarmante.

¿Por qué ocurre esto? Todo se reduce a cómo detectan la conectividad a internet los sistemas operativos. Cuando un dispositivo se conecta a una red, envía un sondeo 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 pasarela de 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. A continuación, abre un pseudonavegador para cargar la página de bienvenida.

El fallo suele producirse en este punto de interceptación.

[PAUSA]

El primer punto crítico de fallo es el sondeo del Indicador de estado de conectividad de red, o NCSI. Si su cortafuegos o pasarela bloquea estas solicitudes HTTP no cifradas, el sistema operativo nunca recibe la redirección 302. Simplemente asume que la red no funciona. Para solucionar este problema, debe asegurarse de que sus listas de control de acceso de autenticación previa permitan el tráfico HTTP a esas URL específicas de detección del sistema operativo.

El segundo problema, cada vez más común, es la Seguridad de transporte estricta HTTP, o HSTS. Los navegadores modernos imponen el uso de HTTPS para los dominios principales. Si un usuario se conecta a su WiFi e intenta abrir inmediatamente google.com, su navegador exige una conexión cifrada. Cuando su pasarela intercepta esa solicitud HTTPS e intenta redirigirla al Captive Portal, el navegador detecta un ataque de intermediario (man-in-the-middle). El certificado presentado por su pasarela no coincide con google.com. El resultado es un bloqueo absoluto. El usuario ve una advertencia de seguridad y no puede acceder a la página de inicio de sesión.

La solución en este caso es doble. En primer lugar, confíe en los mecanismos de detección a nivel de sistema operativo que acabamos de describir. Utilizan HTTP no cifrado específicamente para evitar este conflicto de certificados. En segundo lugar, 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 utiliza el inicio de sesión social a través de Microsoft Entra ID o Google Workspace, o si procesa pagos a través de Stripe, esos dominios deben estar en su walled garden. Si no lo están, es posible que la página de bienvenida se 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 consulte su teléfono durante un almuerzo largo podría verse obligado a volver a autenticarse varias veces. Eso arruina la experiencia. Recomendamos establecer la duración de las sesiones en 24 horas para entornos de hostelería y comercio minorista, utilizando el almacenamiento en caché de direcciones MAC para reconocer los dispositivos recurrentes de forma transparente.

[PAUSE]

Pasemos ahora a las recomendaciones de implementación. Al desplegar un Captive Portal, debe configurar su pasarela para interceptar el tráfico DNS y HTTP correctamente. Si utiliza una superposición en la nube como Purple, su hardware local, ya sea Juniper Mist o Ubiquiti UniFi, debe poder comunicarse con los servidores RADIUS de Purple.

He aquí un error crítico: la resolución DNS. Si el dispositivo de un invitado no puede resolver el nombre de host de su Captive Portal, la redirección falla. Asegúrese de que su servidor DHCP asigne direcciones DNS fiables y verifique que su pasarela permita que las consultas DNS pasen a través del walled garden.

Además, tenga en cuenta el entorno físico. Los recintos de alta densidad como estadios o centros de transporte, como Manchester Airports Group, gestionan miles de intentos de conexión simultáneos. Si su grupo 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. Dimensione siempre sus subredes de forma adecuada para la capacidad máxima y utilice tiempos de concesión 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 se trata de un problema de walled garden. Es probable que haya incluido captive.apple.com en la lista blanca pero haya omitido connectivitycheck.gstatic.com. Actualice sus listas de control de acceso previas a la autenticación.

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

Respuesta: Compruebe su configuración de RADIUS. Es probable que la pasarela no esté recibiendo el mensaje Access-Accept del servidor RADIUS, o que las reglas del cortafuegos posteriores a la autenticación estén bloqueando el tráfico. Verifique el secreto compartido y asegúrese 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 instale un certificado raíz en cada dispositivo invitado, lo cual es imposible para redes WiFi públicas. Debe confiar en las sondas HTTP no cifradas del sistema operativo para activar el portal.

[PAUSE]

En resumen: los fallos del Captive Portal rara vez se deben a fallos de hardware. Casi siempre se trata de desajustes de configuración en el flujo de redirección, el walled garden o los ajustes de DNS.

Punto uno: asegúrese de que las URL de detección del sistema operativo estén 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 puerta de enlace y su plataforma de autenticación.

Punto cuatro: dimensione sus ámbitos DHCP para picos de densidad.

Al dominar estos elementos, eliminará las fricciones en la conexión. Dejará de frustrar a sus visitantes y comenzará a capturar los datos de origen que necesita para impulsar la fidelidad y los ingresos. Las redes basadas en identidad de Purple simplifican este proceso, proporcionando una capa superpuesta de nube independiente del hardware que gestiona la complejidad de RADIUS, los Captive Portals y las analíticas de forma fluida en 80.000 establecimientos activos en todo el mundo.

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

Conclusiones clave

✓Los fallos del Captive Portal casi siempre son problemas de configuración, no fallos de hardware. La cadena de redirección tiene seis pasos y cualquiera de ellos puede fallar.
✓Cada OS envía una URL de sondeo HTTP diferente para detectar Captive Portals. Si su pasarela bloquea cualquiera de estos sondeos, ese OS nunca verá la splash page.
✓Nunca intente interceptar el tráfico HTTPS para la redirección del Captive Portal. HSTS provoca errores graves de certificado. Confíe en los sondeos HTTP no cifrados del OS.
✓El walled garden debe incluir las URL de sondeo del OS, los dominios del proveedor de identidad (Microsoft Entra ID, Google Workspace), los activos de CDN y los dominios del procesador de pagos antes de la autenticación.
✓La autenticación (completar el formulario de inicio de sesión) y la autorización (la pasarela abriendo la regla de firewall) son pasos independientes. Si el portal muestra que se ha completado con éxito pero no hay internet, la comunicación RADIUS entre la pasarela y los servidores de Purple está rota.
✓En entornos de alta densidad, el agotamiento de DHCP produce síntomas idénticos a los de un fallo del Captive Portal. Dimensione su pool de DHCP para el número máximo de dispositivos simultáneos y utilice tiempos de concesión cortos.
✓Pruebe cada implementación en iOS, Android y Windows antes de la aprobación final. Los fallos específicos de un OS apuntan a lagunas en el walled garden, no a errores de configuración fundamentales.

Resumen ejecutivo

La consulta "WiFi de invitados conectado pero sin 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 redirección. Un Captive Portal (también llamado página de bienvenida o gateway 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 algún paso de esa cadena falla - 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 sedes activas, procesando 440 millones de inicios de sesión anualmente (datos internos de Purple, 2024), y los patrones descritos aquí representan las causas de origen más frecuentes que vemos en implementaciones de hostelería, retail, transporte y sector público.

Análisis técnico profundo

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

Todos los sistemas operativos principales incluyen un mecanismo integrado 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 OS 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 el gateway intercepta una de estas solicitudes y devuelve una redirección HTTP 302 que apunta a la URL del Captive Portal, el OS reconoce que está detrás de un portal y abre un pseudonavegador (un WebView ligero) para mostrar la página de bienvenida. Si la sonda se bloquea por completo, el OS informa "Sin conexión a internet" y nunca intenta abrir el portal. Esta es la causa más común del síntoma "WiFi de invitados conectado pero sin internet".

El problema de HSTS

HTTP Strict Transport Security (HSTS) es una política de seguridad web definida en la norma RFC 6797. Indica a los navegadores que rechacen todas las conexiones HTTP estándar a un dominio y que descarten cualquier certificado que no coincida exactamente. Los principales dominios, incluidos google.com, facebook.com y la mayoría de los sitios web bancarios, están en la lista de precarga de HSTS integrada en Chrome, Firefox, Safari y Edge.

Cuando un usuario 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 de forma limpia, ya que tendría que presentar un certificado para google.com que no posee. El navegador detecta la incoherencia del certificado y muestra una advertencia de seguridad crítica. El usuario invitado no puede acceder a la página de inicio de sesión.

La arquitectura correcta depende por completo de las sondas HTTP a nivel de sistema operativo descritas anteriormente. Esas sondas utilizan HTTP estándar para 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 el tráfico HTTPS para funciones 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 restrictivo, la página de bienvenida se cargará pero la autenticación fallará. Entre los problemas más comunes se incluyen:

Dominios de proveedores 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 activos: es posible que su página de bienvenida cargue CSS, JavaScript o fuentes desde una red de distribución de contenido. Si esos dominios de CDN están bloqueados, la página se mostrará de forma incorrecta.
Dominios de procesadores de pago: si cobra por el acceso a través de Stripe u otro procesador, los dominios de su SDK de JavaScript deben estar autenticados previamente.
Dominios de la plataforma Purple: la capa de la nube de Purple requiere que la puerta de enlace acceda a los servidores RADIUS de Purple y a los puntos de conexión del portal. Estos se detallan en las guías de integración de hardware de Purple para cada plataforma compatible.

RADIUS y el intervalo 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 usuario 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. La puerta de enlace actúa en función de ese mensaje abriendo o manteniendo cerrada la regla del firewall que concede el acceso a Internet.

El intervalo de autorización (cuando un usuario invitado inicia sesión correctamente en la página de bienvenida pero sigue sin tener conexión a Internet) casi siempre significa que la puerta de enlace no recibió o no procesó el mensaje Access-Accept. Entre las causas comunes se incluyen una clave secreta compartida que no coincide, el bloqueo de los puertos UDP 1812 y 1813 por parte de un firewall local o una configuración incorrecta de la dirección IP del servidor RADIUS en la puerta de enlace.

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 fallos 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 recintos como Manchester Airports Group (MAG), donde los volúmenes de pasajeros alcanzan picos muy marcados, las subredes deben dimensionarse para el número máximo de dispositivos simultáneos, no para la media. Los tiempos de concesión de DHCP cortos (15 - 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 Networks o Fortinet - cuando se integra con la capa en la 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. Añada como mínimo los siguientes dominios: los endpoints de portal y RADIUS 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 de contabilidad en 1813. Verifique que su firewall local permita UDP saliente en estos puertos.

Paso 4: Configurar los parámetros de sesión. Para hostelería y comercio minorista, establezca la duración de la sesión en 24 horas con el almacenamiento en caché de direcciones MAC habilitado. Esto evita que los huéspedes se vean obligados a volver a autenticarse durante una única visita. Para entornos de alta seguridad, es adecuado utilizar sesiones más cortas con reautenticación.

Paso 5: Dimensionar el alcance de DHCP. Calcule el número máximo de dispositivos simultáneos para su recinto en su capacidad máxima. Un restaurante de 500 plazas puede albergar 800 dispositivos durante un servicio concurrido. Dimensione el pool de DHCP a 1.000 direcciones con un tiempo de concesión de 30 minutos.

Paso 6: Probar en diferentes sistemas operativos. Después de 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 diferentes. Un fallo en una plataforma mientras que las otras funcionan es casi siempre un problema de configuración en el Walled Garden.

Buenas prácticas

Las siguientes recomendaciones reflejan los estándares y patrones en los más de 80.000 despliegues en recintos de Purple.

Separate guest and staff networks. Run at least three SSIDs: Guest WiFi, Staff WiFi, and an IoT network. Guest traffic must be isolated from internal systems. See our guide on Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi for architecture detail.

Use a dedicated guest VLAN. Segment guest traffic into its own VLAN to prevent lateral movement and simplify firewall policy. This is a PCI-DSS requirement if any payment card data traverses the network.

Implement conscious-choice opt-ins. GDPR requires that data collection at the captive portal is based on informed, affirmative consent. Purple's Conscious-choice opt-ins present data collection choices clearly, with separate tick boxes for each purpose. This is not optional for venues operating in the UK or EU.

Monitor portal health proactively. Purple's WiFi Analytics platform provides real-time visibility into login success rates, session counts, and authentication failures. A sudden drop in successful logins is an early warning of a RADIUS or walled garden issue before guests start complaining.

Apply consistent branding. The splash page is the first branded interaction a guest has with your network. A well-designed portal increases opt-in rates and sets expectations for the WiFi experience. See How to make a great first impression with your guest WiFi for design guidance.

Troubleshooting and risk mitigation

When a captive portal issue is reported, follow this diagnostic sequence before making any configuration changes.

Isolate the failure point. Ask the guest which OS and browser they are using. Test the same flow yourself on the same OS. If the issue is OS-specific, the cause is almost certainly a missing walled garden entry for that OS's probe URL.

Check DNS resolution. From a device on the guest VLAN, attempt to resolve the captive portal hostname. If DNS resolution fails, the device cannot reach the splash page even if the redirect is issued correctly. Verify that your DHCP server is distributing reliable DNS addresses and that the gateway permits DNS queries in the pre-authentication state.

Capture the redirect. Use browser developer tools (F12) or a packet capture to observe the HTTP exchange. You should see the OS probe request followed by an HTTP 302 response containing the portal URL. If you see the probe request but no 302 response, the gateway is not intercepting correctly. If you see no probe request at all, the OS has already determined it has internet access (possibly from a cached state) and is not sending the probe.

Verifique la comunicación RADIUS. En la puerta de enlace, compruebe los registros de contabilidad de RADIUS. Una autenticación correcta genera un registro Accounting-Start. Si no ve registros de contabilidad después de que un invitado inicie sesión, la comunicación RADIUS está fallando. Compruebe la clave secreta compartida, la IP del servidor y las reglas del firewall.

Compruebe la utilización de concesiones DHCP. En el servidor DHCP, revise el recuento de concesiones actuales frente al tamaño del grupo. Si la utilización supera el 90 %, se está acercando al agotamiento. Amplíe el grupo o reduzca el tiempo de concesión inmediatamente.

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 puerta de enlace	Añada las URL de sonda a la lista de permitidos previa a la autenticación
El portal aparece en iOS, pero no en Android	Falta la URL de la sonda de Android en el walled garden	Añada `connectivitycheck.gstatic.com` al walled garden
Error de certificado HTTPS al cargar el portal	La puerta de enlace intercepta HTTPS en lugar de HTTP	Confíe únicamente en la interceptación de sondas HTTP
El portal se carga, no hay internet tras iniciar sesión	La puerta de enlace no recibe el Access-Accept de RADIUS	Verifique la clave secreta compartida, 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	Añada los endpoints de Microsoft Entra ID / Google Workspace
Los invitados deben volver a autenticarse en cada visita	Duración de sesión demasiado corta o almacenamiento en caché de MAC desactivado	Establezca la sesión en 24 horas, active el almacenamiento en caché de direcciones MAC
Fallos intermitentes en horas punta	Agotamiento del grupo DHCP	Amplíe la subred, 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 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 alimenta directamente en los programas de fidelización y automatización de marketing.

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 un patrimonio de 700 propiedades 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 retail , 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 múltiples ubicaciones. Purple ha recopilado 29.000 millones de puntos de datos (datos internos de Purple) en 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 junta directiva. Un portal que falla de forma intermitente durante los periodos de mayor salida genera quejas y daña el Net Promoter Score del establecimiento.

Para entornos de healthcare , un WiFi para visitantes fiable reduce la presión sobre el personal clínico, que de otro modo tendría que gestionar las quejas de conectividad, y mejora 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 no sea el punto de fallo. Cuando se producen problemas con el portal, la causa casi siempre es la configuración local, algo que esta guía le ayuda a 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 presenta a un dispositivo que se conecta a una red antes de que se le conceda acceso total a internet. La pasarela intercepta la sonda de conectividad HTTP inicial 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 vestíbulos de hoteles hasta pasillos de estadios. Definido en RFC 8910.

Walled garden

El conjunto de dominios y direcciones IP a los que un dispositivo puede acceder antes de completar la autenticación del Captive Portal. El tráfico dirigido a los destinos del walled garden evita el requisito de autenticación.

Debe incluir las URL de sondeo del SO, los endpoints del proveedor de identidad, los dominios 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 sondea `msftconnecttest.com` para determinar si el dispositivo tiene acceso a internet o si se encuentra tras un Captive Portal. Definido en la documentación de red de Microsoft.

Si la pasarela bloquea esta sonda, Windows informa "Sin acceso a internet" y nunca activa el WebView 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 que descarten cualquier certificado que no coincida exactamente con el dominio.

Evita que las pasarelas intercepten peticiones HTTPS para la redirección al Captive Portal. Los principales dominios, incluido google.com, están en la lista de precarga de HSTS de los navegadores más 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 la cabecera Location.

El mecanismo que utilizan las pasarelas para desviar la sonda de conectividad de un dispositivo a la página de inicio de sesión del Captive Portal. Algunas pasarelas utilizan en su lugar HTTP 303 o HTTP 200 con un cuerpo de redirección.

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), que funciona sobre UDP en los puertos 1812 (autenticación) y 1813 (contabilidad).

La plataforma en la nube de Purple actúa como servidor RADIUS. La pasarela 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 necesidad de volver a autenticarse.

Permite la persistencia de la sesión en caso de desconexiones breves y visitas consecutivas dentro del intervalo de sesión. Esencial para entornos de hostelería donde los clientes 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 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 de 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 espacios de alta densidad durante períodos 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 internet. Se diagnostica comprobando la utilización de las 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 preautenticación en el controlador HPE Aruba. Los dispositivos iOS sondean captive.apple.com, que probablemente ya esté en la lista permitida. 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 de preautenticación resuelve el problema. El equipo también debe añadir connectivitycheck.android.com como URL de sonda secundaria para 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 almacenado en caché en un dispositivo conectado previamente puede enmascarar el resultado.

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

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 tras 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 propiamente dicho está funcionando. El fallo está en el paso de autorización: el dispositivo Meraki no recibe ni 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 del 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 introdujo una regla de firewall o una política NAT que bloquea 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.

Comentario del examinador: La información de diagnóstico fundamental aquí es que el panel de Purple que muestra inicios de sesión correctos significa que el paso de autenticación en la nube se completó. Por lo tanto, el fallo está en el paso de aplicación local: el mensaje RADIUS de la nube a la puerta de enlace. Esta distinción entre la autenticación en el lado de la nube y la autorización en el lado local es fundamental para solucionar problemas en cualquier despliegue de captive portal que utilice una arquitectura de capa en la nube.

Preguntas de práctica

Q1. Durante un congreso importante en un recinto con capacidad para 5000 personas, el equipo de TI recibe avisos 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 al inicio. Considere qué recurso se ve limitado 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 llegaban y se asociaban 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 el sondeo HTTP necesario para activar el Captive Portal. La solución inmediata es reducir el tiempo de concesión 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 de 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. La splash page se carga correctamente en todos los dispositivos. Los invitados completan el formulario de captura 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 está en el paso de aplicació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 ni actúa según el 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 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. Un responsable de TI de un hotel informa que los huéspedes que utilizan 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 salga del mismo, incluido el sondeo de conectividad HTTP. La pasarela 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. Se trata de una limitación de arquitectura fundamental de los Captive Portal y las VPN, no de un error de configuración. El equipo de TI debería añadir una nota a las instrucciones de la WiFi para huéspedes aconsejando a los usuarios de VPN que desactiven su VPN antes de conectarse.

Continúe leyendo esta serie

Resolución de problemas de WiFi público: Solucionando "Conectado, sin Internet" y fallos de redirección a la página de bienvenida

Esta guía técnica de referencia explica el funcionamiento interno de la detección de Captive Portal y detalla los seis principales modos de fallo que impiden la conexión del WiFi de invitados. Proporciona a los responsables de TI y arquitectos de red un marco práctico de resolución de problemas para solventar incidencias de redirección HTTP, conflictos de DNS y los retos de la aleatorización de direcciones MAC.

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

Esta guía de referencia técnica autorizada identifica las diez causas principales de los tiempos de espera (timeouts) 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 red y directores de operaciones de recintos, cubre principios de ingeniería detallados, flujos de trabajo de implementación paso a paso y resultados comerciales medibles. Aprenda a eliminar los cuellos de botella en las conexiones y a optimizar su infraestructura de WiFi para ofrecer una conectividad fluida en entornos empresariales exigentes.

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

Esta guía de referencia técnica proporciona a los responsables 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 las redes WiFi empresariales mediante el análisis de captura de paquetes (PCAP). Al diseccionar las 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 tiendas, estadios y centros de conferencias, esta guía ofrece flujos de trabajo de diagnóstico prácticos, casos de estudio reales y pasos de corrección de configuración para recuperar la capacidad de la red y proteger la experiencia del cliente.