Solución de problemas de redirección del Captive Portal: resolución de fallas 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 un Captive Portal mal configurado - no una falla de hardware. Esta guía proporciona una referencia técnica detallada para gerentes de TI, arquitectos de red y CTO 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 al hardware de Purple elimina estos problemas en implementaciones de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.
Video overview
Escucha 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 uno de los tickets 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 comprenden la cadena de redireccionamiento. Un Captive Portal (también conocido como página de bienvenida o gateway de hotspot) intercepta la prueba de conectividad HTTP inicial de un dispositivo y emite un redireccionamiento HTTP 302 a una página de inicio de sesión. Si algún paso de esa cadena se rompe (pruebas 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 de los protocolos subyacentes y los cambios de configuración que los resuelven. Purple opera en más de 80,000 establecimientos activos, 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 hotelería, retail, transporte y sector público.
Análisis técnico profundo
Cómo funciona realmente la detección de Captive Portal
Cada sistema operativo principal cuenta con un mecanismo integrado para detectar si una red requiere autenticación antes de otorgar acceso a internet. Comprender estos mecanismos es la base para la resolución de problemas de cualquier Captive Portal.
Cuando un dispositivo se asocia a un SSID, el sistema operativo envía una solicitud HTTP GET no cifrada a una URL predefinida. La siguiente tabla enumera las URL de prueba por plataforma.
| Sistema operativo | URL de prueba | 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 el 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 un redireccionamiento HTTP 302 apuntando a la URL del Captive Portal, el sistema operativo reconoce que está detrás de un portal y abre un pseudonavegador (un WebView ligero) para mostrar la página de bienvenida. Si la prueba se bloquea por completo, el sistema operativo 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 sencillas 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. La puerta de enlace 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 continuar a la página de inicio de sesión.
La arquitectura correcta depende completamente de las sondas HTTP a nivel del sistema operativo descritas anteriormente. Esas sondas utilizan HTTP sencillo hacia URL 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 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 inicio 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 de recursos: Su página de inicio 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á 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: El overlay en la nube de Purple requiere que la puerta de enlace se conecte con los servidores RADIUS y los puntos de conexión del portal de Purple. Estos se encuentran documentados 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 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 otorga el acceso a internet.
La brecha de autorización - donde un invitado inicia sesión correctamente en la página de inicio pero sigue sin tener acceso a internet - casi siempre significa que la puerta de enlace no recibió o no procesó el mensaje Access-Accept. Las causas comunes incluyen un secreto compartido que no coincide, los puertos UDP 1812 y 1813 bloqueados por un firewall local, o la dirección IP del servidor RADIUS configurada de forma incorrecta 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 fallas de conexión que parece idéntica a un problema de Captive Portal. Si el grupo 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 tienen picos 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 retirado.
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 superposición 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. Agregue los siguientes dominios como mínimo: el portal de Purple y los puntos finales RADIUS (consulte su guía de integración de hardware), las URL de las sondas 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 bienvenida.
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 de salida 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 las 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 recinto en su capacidad máxima. Un restaurante de 500 asientos puede ver 800 dispositivos durante un servicio concurrido. Dimensione el grupo de DHCP a 1,000 direcciones con un tiempo de concesión de 30 minutos.
Paso 6: Probar en todos los 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 las demás funcionan es casi siempre una brecha en el Walled Garden.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Mejores prácticas
Las siguientes recomendaciones reflejan los estándares y patrones en las más de 80,000 implementaciones de recintos 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 y IoT WiFi 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 la política de firewall. Este es un requisito de PCI-DSS si los datos de tarjetas de pago transitan por la red.
Implemente opciones de consentimiento de elección 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 de elección 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 el estado 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 advertencia temprana de un problema de RADIUS o del walled garden antes de que los invitados comiencen a quejarse.
Aplique una imagen de marca consistente. 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 suscripción y define 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.
-
Solución de problemas y mitigación de riesgos
Cuando se reporte 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 falla. Pregunte al invitado qué OS y navegador está utilizando. Pruebe el mismo flujo usted mismo en el mismo OS. Si el problema es específico del OS, la causa es casi seguro que falta una entrada de walled garden para la URL de prueba de ese OS.
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 emita 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 la redirección. 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 OS 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 OS ya ha determinado que tiene acceso a internet (posiblemente debido a 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 genera un registro Accounting-Start. Si no ve registros de contabilidad después de que un invitado inicia sesión, la comunicación RADIUS está fallando. Verifique la contraseña secreta compartida, la IP del servidor y las reglas del firewall.
Verifique la utilización de concesiones DHCP. En el servidor DHCP, revise el conteo actual de concesiones 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 concesión 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 previa a la autenticación |
| El portal aparece en iOS, pero no en Android | Falta la URL de sonda de Android en el walled garden | Agregue connectivitycheck.gstatic.com al walled garden |
| Error de certificado HTTPS al cargar el portal | La puerta de enlace intercepta HTTPS en lugar de HTTP | Dependa únicamente de la intercepción de sondas HTTP |
| El portal carga, pero no hay internet tras iniciar sesión | RADIUS Access-Accept no recibido por la puerta de enlace | Verifique la contraseña secreta compartida, los puertos 1812/1813 y la IP del servidor RADIUS |
| El botón de inicio de sesión social falla sin mostrar errores | 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 sesión demasiado corta o caché de MAC desactivada | Establezca la sesión en 24 horas, active la caché de direcciones MAC |
| Fallas intermitentes en horas pico | Agotamiento del pool DHCP | Amplíe la subred, reduzca el tiempo de concesión |
ROI e impacto empresarial
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 primera mano (nombre, correo electrónico, datos demográficos y frecuencia de visitas) que se alimenta directamente en la automatización de marketing y los programas de fidelización.
Para un operador de hospitality 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 considerablemente 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 visitas repetidas y el comportamiento en múltiples ubicaciones. Purple ha recopilado 29 mil 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 transport como Manchester Airports Group, un WiFi de invitados confiable es una métrica de satisfacción del pasajero que se supervisa a nivel directivo. Un portal que falla de manera intermitente durante los períodos de salida pico genera quejas y daña el Net Promoter Score del lugar. 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 tiempo de actividad de 99.999% de Purple garantiza que la infraestructura de la nube en sí 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 ayudará a resolver sin tener que abrir un ticket de soporte.
Referencias
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Comunidad Fortinet, 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. Comunidad Ubiquiti. 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 otorgue acceso total 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 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 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 fallas 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 está detrás de un Captive Portal. Definido en la documentación de redes de Microsoft.
Si la puerta de enlace bloquea esta prueba, Windows reporta 'Sin acceso a internet' 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 las puertas de enlace intercepten peticiones HTTPS para la redirección del Captive Portal. Los dominios principales, incluyendo 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 el encabezado 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), que funciona sobre UDP en los puertos 1812 (autenticación) y 1813 (contabilidad).
La plataforma en la nube de Purple actúa como el 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 a través de desconexiones breves y visitas repetidas dentro del intervalo de la sesión. Es esencial para entornos de hotelería donde los huéspedes se desplazan entre áreas.
Redes basadas en 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 utilizar únicamente 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 pool de DHCP, lo que impide que los nuevos dispositivos obtengan una dirección y, por lo 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 una falla del 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 en 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 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 para Android. Después de actualizar el walled garden, reinicie los SSID afectados y realice una 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 previamente conectado puede enmascarar el resultado.
Una cadena minorista con 150 dispositivos Cisco Meraki MX informa que los invitados se autentican en la página de inicio de Purple - el panel de Purple muestra inicios de sesión exitosos - pero los invitados siguen sin tener 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 en sí está funcionando. La falla está en el paso de autorización: el dispositivo Meraki no recibe o no actúa 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 provoca una falla silenciosa); segundo, confirmar que se permite el tráfico UDP saliente en los puertos 1812 y 1813 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 NAT que bloquea este tráfico. Debido a que el problema afecta a las 150 ubicaciones simultáneamente, la causa probablemente sea un cambio centralizado en la política de firewall o un cambio de 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 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ó 45 minutos después 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 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 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 a 15 minutos (recuperando más rápido las direcciones de los dispositivos que se han ido) y, si es posible, ampliar 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 tiendas 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 panel de Purple muestra los inicios de sesión como exitosos. ¿Qué verifica 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
Debido a que el panel 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 actúa sobre el mensaje Access-Accept de los servidores RADIUS de Purple. Verifique en este orden: (1) que el secreto compartido de RADIUS en el controlador UniFi coincida 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 de los servidores RADIUS de Purple; (3) que las direcciones IP de los servidores 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 gerente 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 del dispositivo antes de que 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 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 a las instrucciones de WiFi para huéspedes que aconseje a los usuarios de VPN desactivarla antes de conectarse.
Continúe leyendo esta serie
El portal de invitados de Ubiquiti UniFi no redirige: causas y soluciones
Esta guía aisla una falla de redirección en el portal de invitados de UniFi siguiendo 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 abordar la confusión entre red de invitados y Hotspot, integraciones con portales externos, los requisitos actuales de cuenta de UniFi OS y pruebas de aislamiento de DNS.
La página de splash de Cisco Meraki no funciona: un diagrama de flujo para la resolución de problemas
Esta guía práctica de día dos aísla el punto de falla en un flujo de splash de Cisco Meraki: autorización del cliente, inicio de redirección HTTP, accesibilidad del walled garden o inicio de sesión RADIUS. Proporciona a los equipos de TI de los establecimientos una ruta de evidencia controlada para restaurar el WiFi de invitados sin realizar cambios drásticos en un entorno de producción.
Guía de configuración de WiFi para invitados empresarial: segmentación de VLAN, seguridad y Captive Portals
Esta guía técnica muestra a los equipos de TI cómo configurar el WiFi para invitados como un servicio de acceso controlado a internet, utilizando segmentación de 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 respaldan una experiencia de visitante proporcionada sin debilitar el límite en torno a los sistemas operativos, de pago y del personal.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.