Solución de problemas de redireccionamiento del portal cautivo: cómo resolver fallas de conexión en el WiFi para invitados

Cuando el WiFi para invitados muestra que está conectado pero no tiene internet, significa que el dispositivo se ha unido a la red pero la redirección del portal cautivo ha fallado. Las causas habituales son una comprobación del sistema operativo bloqueada, entradas faltantes en la lista de acceso permitido (walled garden) o fallas en el DNS. Otras causas son un grupo DHCP agotado o un mensaje Access-Accept de RADIUS que nunca llega a la puerta de enlace. Cada uno de estos problemas se puede solucionar mediante la configuración.

¿Qué significa que el "WiFi para invitados aparezca como conectado pero sin internet"?

El dispositivo se une al nombre de la red (SSID) y muestra una señal completa, pero no carga nada. Cada plataforma lo reporta de manera diferente:

• iOS muestra "Sin conexión a Internet" debajo del nombre de la red.
• Android muestra "Conectado, sin internet" o un aviso de "Iniciar sesión en la red" que no lleva a ninguna parte.
• Windows marca la red como "Sin internet".

El visitante ve un ícono de WiFi funcionando y un navegador inactivo, por lo que culpa al establecimiento.

Un solo síntoma puede ocultar varias fallas distintas. Por lo general, verá uno de los siguientes patrones:

• La página de inicio de sesión nunca aparece en ningún dispositivo.
• La página de inicio de sesión aparece en iPhones pero no en teléfonos Android, o viceversa.
• El navegador muestra una advertencia de certificado o privacidad en lugar de la página de inicio de sesión.
• El visitante completa el formulario, ve un mensaje de éxito y aún no tiene internet.
• Todo funciona en momentos de poca actividad y falla en los momentos de mayor tráfico.

Cada patrón señala a una capa diferente de la red. Comience por interpretar el patrón, no reiniciando los puntos de acceso.

Cómo funciona la detección del portal cautivo

Un portal cautivo es la página web que muestra una puerta de enlace antes de conceder acceso a internet. La puerta de enlace es su controlador, firewall o punto de acceso, según su diseño.

Todos los sistemas operativos principales comprueban si hay un portal cautivo tan pronto como se unen a una red. Envían una solicitud HTTP simple a una dirección conocida y comparan la respuesta con lo que esperan. Cada resultado tiene un significado diferente:

• La respuesta coincide. El dispositivo asume que tiene internet abierto.
• La puerta de enlace devuelve una redirección HTTP 302. El dispositivo reconoce que está detrás de un portal. Abre una ventana de navegador ligera, a menudo llamada asistente de red cautiva, y carga su página de inicio de sesión.
• La solicitud no recibe respuesta. El dispositivo reporta que no hay internet y no abre nada.

Microsoft documenta que su Indicador de estado de conectividad de red (NCSI) también resuelve dns.msftncsi.com como una comprobación de DNS. Por lo tanto, una laptop con Windows puede reportar que no hay internet cuando el DNS previo a la autenticación no funciona, incluso si HTTP funciona.

¿Qué suele hacer que falle la redirección a un portal cautivo?

Siete causas explican la mayoría de los casos. Se ubican en diferentes capas, desde el direccionamiento hasta la autenticación.

La prueba del sistema operativo está bloqueada

La lista de control de acceso (ACL) previa a la autenticación de la puerta de enlace descarta la prueba en lugar de redirigirla. El dispositivo no recibe respuesta y determina que no hay internet. Nunca abre el portal.

Un servicio de filtrado DNS que bloquea los nombres de host de prueba tiene el mismo efecto. Esta es la razón más común por la que un portal nunca aparece.

HTTPS y HSTS rompen la intercepción

HTTP Strict Transport Security (HSTS), definido en RFC 6797, indica a los navegadores que accedan a un dominio únicamente a través de HTTPS. Los navegadores vienen con una lista de precarga de dominios HSTS, incluidos los de Google y la mayoría de los bancos. Cuando un visitante escribe google.com, el navegador se actualiza a HTTPS antes de que la solicitud salga del dispositivo.

La puerta de enlace no puede redirigir esa solicitud sin presentar un certificado para google.com, el cual no posee. El navegador muestra una advertencia de seguridad estricta sin forma de continuar.

La solución consiste en redirigir únicamente las pruebas de HTTP sin cifrar de la tabla anterior, que existen exactamente para este propósito. Nunca intercepte HTTPS para la redirección del portal.

El jardín amurallado es demasiado estrecho

El jardín amurallado es la lista de dominios y direcciones IP a las que un dispositivo puede acceder antes de autenticarse. Si falta una entrada, la página de inicio de sesión se carga parcialmente o el paso de inicio de sesión falla. Las omisiones habituales son:

• Puntos de enlace de proveedores de identidad para inicio de sesión social o de acceso único (SSO), como Microsoft Entra ID, Okta o Google Workspace.
• Dominios de redes de distribución de contenido que sirven las fuentes, scripts y hojas de estilo de su página de inicio de sesión.
• Dominios de procesadores de pago, si cobra por el acceso.
• El portal cautivo de Purple y los puntos de enlace de RADIUS, enumerados en la guía de integración de Purple para su hardware.

El DNS falla antes de la autenticación

El dispositivo debe resolver el nombre de host del portal antes de poder cargar la página. La redirección no apunta a ninguna parte en dos casos:

• La puerta de enlace bloquea el DNS en el estado previo a la autenticación.
• DHCP asigna un servidor DNS al que el dispositivo no puede acceder.

Android añade una complicación. Si un visitante ha configurado un nombre de host DNS privado específico, Android espera DNS sobre TLS en el puerto 853. En modo automático, vuelve al DNS ordinario.

El grupo de DHCP se ha agotado

Cuando el grupo de direcciones se agota, un nuevo dispositivo se asocia con el punto de acceso pero no obtiene una dirección IP. Windows se asigna a sí mismo una dirección de enlace local 169.254.x.x, y otros sistemas muestran un estado autoasignado similar.

Sin una dirección válida, el dispositivo no puede enviar una prueba. Parece conectado pero no tiene internet. Este es el fallo clásico en horas pico dentro de estadios, centros de conferencias y nodos de transporte.

RADIUS nunca entrega el Access-Accept

RADIUS (Servicio de usuario de marcado de autenticación remota) transmite la decisión de inicio de sesión desde el servidor de autenticación hacia su puerta de enlace. El servidor responde Access-Accept o Access-Reject, como se define en RFC 2865. La puerta de enlace luego permite el acceso o lo mantiene cerrado.

Si un visitante completa el formulario pero permanece sin conexión, casi siempre significa que la puerta de enlace no recibió la respuesta Access-Accept. Las tres causas más comunes son:

• Un secreto compartido no coincidente.
• Un firewall que bloquea UDP 1812 (autenticación) o UDP 1813 (contabilidad). Las RFC 2865 y RFC 2866 definen estos puertos.
• Una dirección de servidor incorrecta en el controlador.

El certificado propio del portal ha expirado

Su página de inicio de sesión se ofrece mediante HTTPS. Si su certificado TLS expira, cualquier navegador moderno bloqueará la página con una advertencia de seguridad. La redirección funciona a la perfección; sin embargo, el visitante no puede iniciar sesión.

¿Cómo determinar cuál es la causa?

Avance en el stack en orden. Cada verificación descarta una capa, así que deténgase en el primer error.

1. ¿El dispositivo tiene una dirección IP válida? Ejecute ipconfig /all en Windows, o consulte los detalles de la red en un teléfono. Una dirección 169.254.x.x, o la ausencia total de dirección, indica un problema con DHCP. Verifique la utilización del grupo en el servidor DHCP. Por encima del 90 %, está cerca del agotamiento.
2. ¿DNS realiza la resolución? Desde un dispositivo en la LAN virtual de invitados (VLAN), un segmento de red lógicamente separado, busque el nombre de host del portal. Si la búsqueda falla, la DNS de preautenticación está bloqueada o el servidor DNS asignado por DHCP es incorrecto.
3. ¿La prueba recibe un código 302? Realice una captura de paquetes en la VLAN de invitados o navegue a una de las URL de prueba HTTP. Debería ver la prueba y luego un HTTP 302 que apunta al portal. Una prueba sin respuesta significa que la ACL la descartó. Si no hay ninguna prueba, significa que el dispositivo cree que ya está en línea, a menudo debido a un estado almacenado en caché. Olvide la red y vuelva a conectarse.
4. ¿La página de inicio de sesión carga por completo? Abra las herramientas para desarrolladores del navegador (F12) y revise la pestaña de red. Las solicitudes bloqueadas a dominios de terceros indican omisiones en el walled garden.
5. ¿La puerta de enlace recibe un Access-Accept? Revise los registros de RADIUS del controlador. Un inicio de sesión correcto va seguido de un Accounting-Request con estado Start. Si no aparece ningún registro de contabilidad después del inicio de sesión, la ruta de RADIUS está interrumpida.

A continuación, compare lo que ve con esta tabla.

Escenario práctico: un centro de conferencias de 1,500 asientos en hora pico

Situación. Un centro de conferencias operaba su red de asistentes en una sola subred /24 con una concesión de DHCP de ocho horas. Las conferencias magistrales de la mañana funcionaron sin problemas. Después del almuerzo, los asistentes que llegaban a las sesiones de la tarde veían el mensaje "conectado, sin internet". El mesa de ayuda lo trató como una falla del portal y reinició el controlador dos veces.

Lo que se hizo. El paso 1 del diagnóstico encontró que los dispositivos nuevos mantenían direcciones 169.254.x.x. Una subred /24 ofrece 254 direcciones utilizables y la concesión de ocho horas mantuvo reservada cada dirección de la mañana. El equipo movió el VLAN de asistentes a una subred /21 y redujo la concesión a 30 minutos.

Resultado. Las direcciones utilizables aumentaron de 254 a 2,046, aproximadamente ocho veces la capacidad anterior. Una dirección abandonada por un asistente que se retira ahora vuelve al pool en un plazo de 30 minutos, no de ocho horas. La solución requirió una sola ventana de cambio y ningún hardware nuevo.

Escenario práctico: un hotel de 200 habitaciones donde los huéspedes de Android no podían iniciar sesión

Situación. Tras un rediseño de la página de inicio de sesión, un hotel de 200 habitaciones recibió quejas en recepción por parte de huéspedes de Android. La mayoría de ellos eligió la opción de inicio de sesión con Google. El portal aparecía, pero el botón no hacía nada.

Lo que se hizo. El gerente de TI probó el flujo en un iPhone, un teléfono Android y una laptop con Windows. Las herramientas de desarrollador en la laptop mostraron solicitudes bloqueadas a una red de distribución de fuentes y a los dominios de inicio de sesión de Google. El rediseño había añadido ambos. El equipo los agregó al walled garden.

Resultado. El inicio de sesión con Google se completó en los tres dispositivos de prueba en el primer reintento. La solución requirió dos entradas en el walled garden y ningún cambio de hardware.

Escenario práctico: una red minorista de 40 tiendas tras una actualización de firewall

Situación. Un minorista reemplazó los firewalls en 40 tiendas durante un fin de semana. El lunes, los compradores de cada tienda actualizada podían completar el formulario de inicio de sesión, pero permanecían desconectados. Las tiendas aún no actualizadas funcionaban con normalidad.

Lo que se hizo. El paso 5 no encontró registros de contabilidad (accounting) de las tiendas actualizadas. La nueva plantilla de firewall denegaba el tráfico UDP saliente por defecto, bloqueando los puertos 1812 y 1813. El equipo agregó reglas salientes explícitas a la plantilla y la implementó en las 40 tiendas.

Resultado. Los registros de contabilidad reaparecieron en todas las tiendas después de la actualización. Debido a que solo fallaron las tiendas actualizadas, el patrón apuntó directamente a la plantilla y no al WiFi.

¿Cómo solucionarlo en cada sistema operativo y controlador?

La solución en el controlador sigue el mismo patrón en todas las plataformas. Las soluciones en los sistemas operativos consisten principalmente en saber cómo se comporta cada uno.

En su controlador

Purple se ejecuta como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. El patrón de solución es el mismo en los ocho:

1. Apunte el SSID para invitados a la URL del portal cautivo externo de su guía de integración de Purple y deshabilite cualquier página de bienvenida local.
2. Redirija el tráfico HTTP no autenticado, incluidas las comprobaciones, a esa URL. No modifique HTTPS.
3. Permita DNS y DHCP antes de la autenticación.
4. Agregue las entradas del walled garden: puntos de enlace de Purple, puntos de enlace del proveedor de identidad y dominios de recursos de la página de inicio de sesión.
5. Ingrese las direcciones del servidor RADIUS y el secreto compartido desde su panel de control de Purple. Luego, confirme que el firewall permita el tráfico saliente UDP 1812 y 1813.

Los nombres de los menús varían según el proveedor y la versión de firmware, por lo que debe seguir la guía de integración de Purple para su plataforma. La documentación comunitaria de Fortinet sobre el flujo del portal cautivo de FortiGate es una referencia útil del lado del proveedor para la secuencia de redirección.

En iOS y macOS

Si el asistente de red cautiva no se abre, olvide la red en Configuración y vuelva a unirse. Esto fuerza una nueva comprobación.

Las versiones recientes de iOS y macOS también son compatibles con el portal cautivo API. Permite que la red anuncie su portal a través de la opción 114 de DHCP, definida en el RFC 8910, lo que reduce la dependencia de la intercepción. Si el asistente se abre pero permanece en blanco, verifique los dominios de recursos en el walled garden.

En Android

Android muestra una notificación de "Iniciar sesión en la red" cuando detecta un portal. Si la notificación nunca aparece, confirme que la puerta de enlace redirija connectivitycheck.gstatic.com en lugar de descartarlo.

Si un visitante ve el mensaje "No se puede acceder al servidor DNS privado", significa que su teléfono tiene configurado un nombre de host de DNS privado estricto. Tiene dos opciones:

• Permitir DNS sobre TLS en el puerto 853 antes de la autenticación.
• Solicitar al visitante que cambie el DNS privado a automático.

En Windows

Windows confía en la comprobación HTTP de NCSI y su verificación de DNS. Si el portal no se abre automáticamente, navegue a cualquier sitio HTTP común para activar la redirección manualmente. Si aparece un mensaje persistente de "Sin internet" después de iniciar sesión, generalmente significa que la puerta de enlace aún está redirigiendo la comprobación. En ese caso, la puerta de enlace no ha aplicado el Access-Accept.

En el navegador

Instruya al personal de primera línea para que envíe a los visitantes a una dirección HTTP, nunca a un dominio HSTS como google.com. Firefox ejecuta su propia comprobación en detectportal.firefox.com, por lo que debe incluir ese host en sus pruebas de redirección.

¿Cómo evitar que vuelvan a ocurrir fallas de redirección en el WiFi para invitados?

La mayoría de los incidentes recurrentes se deben a cambios y no a la configuración original. Una actualización de firmware, una nueva plantilla de firewall, un rediseño de la página de inicio de sesión o un certificado a punto de vencer pueden pasar desapercibidos en las pruebas. Incorpore estos controles en su proceso de gestión de cambios:

• Realice pruebas en tres plataformas después de cada cambio. Utilice un iPhone, un teléfono Android y una computadora portátil con Windows. Si una plataforma falla mientras las demás funcionan, busque primero una omisión en el walled garden.
• Calcule el tamaño para el punto máximo, no para el promedio. Calcule el número máximo de dispositivos concurrentes y agregue un margen de seguridad. Las redes temporales de visitantes suelen tener concesiones de 15 a 30 minutos.
• Configure las sesiones para que coincidan con la visita. Los establecimientos de hospitalidad y venta al por menor suelen configurar sesiones de 24 horas, de modo que el invitado inicie sesión una vez por estancia o visita.
• Monitoree los volúmenes de inicio de sesión a diario. En WiFi Analytics de Purple se reportan los inicios de sesión por establecimiento. Una caída repentina en un sitio le advierte sobre una falla de RADIUS o del jardín amurallado, a menudo antes de que los visitantes se quejen.
• Ponga los certificados y los secretos compartidos bajo control de cambios. Programe la fecha de vencimiento del certificado del portal en su agenda. Guarde el secreto compartido de RADIUS donde los equipos de firewall y de controladores puedan consultarlo.
• Segmente el tráfico de invitados. Coloque a los invitados en su propia VLAN. El estándar PCI DSS considera la segmentación como la forma de mantener la red de invitados fuera del alcance de su entorno de datos de tarjetahabientes.
• Planifique la aleatorización de direcciones MAC. Las versiones recientes de iOS y Android utilizan una dirección MAC aleatoria para cada red, y algunos modos la rotan con el tiempo. El almacenamiento en caché de la sesión basado en la dirección MAC solicitará a los visitantes que regresan que vuelvan a iniciar sesión.
• Recopile el consentimiento correctamente. El GDPR requiere un consentimiento informado y afirmativo para los datos de marketing. Las opciones de suscripción de elección consciente de Purple presentan una opción independiente para cada propósito.

Omita el portal cautivo para los visitantes que regresan

La solución más duradera elimina por completo la redirección para las visitas repetidas.

• Passpoint es la certificación de la industria creada a partir de la especificación Hotspot 2.0. Permite que un dispositivo se una a una red automáticamente mediante un perfil almacenado.
• OpenRoaming, gestionado por la Wireless Broadband Alliance, federará proveedores de identidad. Las credenciales existentes de un visitante funcionarán en todos los establecimientos participantes.

Ambos utilizan IEEE 802.1X, el estándar para el control de acceso a redes basado en puertos, por lo que no hay ningún portal que pueda fallar.

Dónde encaja Purple

Purple WiFi para invitados funciona como una superposición en la nube independiente del hardware, por lo que las fallas de redirección se corrigen mediante configuración y no con hardware nuevo. Purple da servicio a más de 80,000 establecimientos activos en más de 90 países y admite 500 millones de usuarios e inicios de sesión al año. La plataforma opera con un tiempo de actividad del 99.999 % y cuenta con las certificaciones ISO 27001, Cyber Essentials y B Corp. También cumple con los estándares GDPR y CCPA.

Cuando un portal falla, la causa casi siempre es local: una regla de sondeo, una entrada de jardín vallado, un pool de DHCP o una regla de firewall.

Los patrones se repiten en todos los sectores:

• Los hoteles experimentan fallas de redirección en las horas pico de check-in.
• Los establecimientos del sector minorista las experimentan después de realizar cambios de firewall en toda la red.
• Los trenes y las estaciones enfrentan presión en el servicio DHCP a medida que los pasajeros abordan en oleadas.
• Los centros de atención médica necesitan un WiFi de pacientes y visitantes que funcione sin que el personal clínico tenga que atender llamadas de soporte técnico.

Preguntas frecuentes

¿Funciona Purple con los puntos de acceso que ya tenemos?

Sí. Purple es independiente del hardware y se ejecuta como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Usted conserva sus puntos de acceso y controladores actuales. Dirija su SSID para invitados al portal cautivo de Purple, agregue las entradas de jardín vallado y los detalles de RADIUS de la guía de integración de Purple y, a continuación, realice la prueba. No es necesario reemplazar ningún equipo.

¿Necesitamos hardware nuevo para solucionar el problema de WiFi para invitados conectado pero sin internet?

No. En casi todos los casos, la falla se debe a la configuración: un sondeo bloqueado, un vacío en el jardín vallado, el DNS de preautenticación, un pool de DHCP agotado o una regla de firewall de RADIUS. Usted soluciona cada uno de ellos en el controlador, el firewall o el servidor DHCP que ya utiliza. El hardware solo se convierte en un problema cuando la densidad de los puntos de acceso no puede atender su cantidad máxima de dispositivos, lo cual se reflejará en un estudio de cobertura del sitio.

¿Qué se necesita para migrar nuestro WiFi para invitados a Purple?

Migrar a Purple es un proyecto de configuración, no un proyecto de instalación. En cada controlador, configure el SSID para invitados al portal externo de Purple y agregue los ajustes del jardín vallado y de RADIUS. Luego, confirme las reglas del firewall para UDP 1812 y 1813. A continuación, cree su página de inicio de sesión y las opciones de consentimiento en Purple y realice pruebas en iOS, Android y Windows. Las empresas con múltiples sedes pueden crear plantillas con la configuración del controlador.

¿Un portal cautivo cumple con el GDPR?

Sí, siempre que el consentimiento sea informado, específico y se otorgue libremente. El GDPR exige una opción afirmativa independiente para cada finalidad, como el correo electrónico de marketing, y excluye las casillas preseleccionadas. Las opciones de aceptación consciente de Purple presentan cada opción por separado. Purple cuenta con la certificación ISO 27001, posee la certificación Cyber Essentials y cumple con el GDPR y la norma CCPA. Eso le proporciona a su oficial de protección de datos los estándares sobre los cuales le preguntará.

¿Los visitantes que regresan pueden omitir la página de inicio de sesión?

Sí. Passpoint y OpenRoaming permiten que un dispositivo se conecte automáticamente utilizando un perfil almacenado o una identidad federada. Ambos utilizan la autenticación IEEE 802.1X con cifrado WPA2 o WPA3-Enterprise, por lo que no hay redirección a un portal cautivo que pueda fallar en las visitas recurrentes. Muchos establecimientos utilizan ambos: un portal cautivo para los visitantes primerizos y la captura de datos, y OpenRoaming para los invitados que regresan, los pasajeros y los estudiantes.

¿Cómo sabremos cuándo comiencen a fallar los inicios de sesión?

Consulte los volúmenes de inicio de sesión por sucursal. Los informes de analítica de WiFi de Purple registran los inicios de sesión de cada sitio, por lo que una caída repentina en una ubicación se destaca en comparación con su patrón normal y sus demás sucursales. Esa caída suele indicar una falla de RADIUS, jardín vallado o DHCP ocasionada por un cambio reciente. Detectarlo en el panel de control es más rápido que esperar a que las quejas de la recepción lleguen al departamento de TI.

¿Debemos usar un portal cautivo o una contraseña de WiFi compartida?

Utilice un portal cautivo si desea obtener datos propios y consentimiento, y una contraseña compartida solo si no necesita ninguno de los dos. Una clave precompartida cifra el tráfico con WPA2 o WPA3-Personal. Sin embargo, no le brinda información sobre quién se conectó y la contraseña se divulga. Un portal cautivo recopila datos propios con consentimiento, y Passpoint o OpenRoaming agrega un acceso cifrado y automático para las visitas recurrentes.