Solución de problemas de redireccionamientos del portal cautivo: cómo resolver los fallos de conexión a la red WiFi WiFi para invitados

Cuando la red WiFi muestra que está conectada pero no hay internet, significa que el dispositivo se ha unido a la red pero la redirección del portal cautivo ha fallado. Las causas habituales son un sondeo del sistema operativo bloqueado, entradas ausentes en el jardín vallado o fallos de DNS. Otras causas son el agotamiento de la reserva DHCP o una respuesta Access-Accept de RADIUS que nunca llega a la pasarela. Todas ellas se pueden corregir mediante configuración.

¿Qué aspecto tiene "WiFi conectada pero sin internet"?

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

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

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

Un mismo síntoma puede ocultar varios fallos diferentes. Por lo general, verá uno de estos patrones:

• La página de inicio de sesión no aparece nunca en ningún dispositivo.
• La página de inicio de sesión aparece en los iPhone pero no en los teléfonos Android, o viceversa.
• El navegador muestra un aviso de certificado o de privacidad en lugar de la página de inicio de sesión.
• El visitante completa el formulario, ve un mensaje de éxito y sigue sin tener internet.
• Todo funciona en momentos de poca actividad y falla durante las horas punta.

Cada patrón apunta a una capa diferente de la red. Empiece por interpretar el patrón, no por reiniciar los puntos de acceso.

Cómo funciona la detección del portal cautivo

Un portal cautivo es la página web que muestra una pasarela antes de conceder acceso a internet. La pasarela es su controlador, cortafuegos 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 básica a una dirección conocida y comparan la respuesta con lo que esperan. Cada resultado significa algo diferente:

• La respuesta coincide. El dispositivo asume que tiene internet abierto.
• La pasarela devuelve una redirección HTTP 302. El dispositivo sabe que está detrás de un portal. Abre una ventana del navegador reducida, a menudo llamada asistente de red cautiva, y carga su página de inicio de sesión.
• La solicitud no recibe respuesta. El dispositivo notifica 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, un portátil con Windows puede notificar que no hay internet cuando el DNS de preautenticación falla, incluso si el protocolo HTTP funciona.

¿Qué suele causar que falle la redirección del portal cautivo?

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

La comprobación del sistema operativo está bloqueada

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

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

HTTPS y HSTS rompen la intercepción

La seguridad de transporte estricta HTTP (HSTS), definida en la norma RFC 6797, indica a los navegadores que accedan a un dominio únicamente mediante HTTPS. Los navegadores incluyen una lista de precarga de dominios HSTS, entre los que se encuentran el de Google y los de la mayoría de los bancos. Cuando un visitante escribe google.com, el navegador actualiza la conexión a HTTPS antes de que la solicitud salga del dispositivo.

La pasarela no puede redirigir esa solicitud sin presentar un certificado para google.com del que no dispone. El navegador muestra una advertencia de seguridad estricta sin opción de continuar.

La solución consiste en redirigir únicamente las comprobaciones HTTP simples de la tabla anterior, que existen precisamente con ese fin. No intercepte nunca HTTPS para la redirección al portal.

El entorno controlado es demasiado restringido

El entorno controlado (walled garden) es la lista de dominios y direcciones IP a los que un dispositivo puede acceder antes de autenticarse. Si falta alguna entrada, la página de inicio de sesión se carga de forma parcial o el paso de acceso falla. Las omisiones habituales son:

• Puntos de enlace de proveedores de identidad para inicios de sesión mediante redes sociales o inicio de sesión único, 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.
• Puntos de enlace del portal cautivo y de RADIUS de Purple, incluidos en la guía de integración de Purple para su hardware.

Falso fallo de DNS 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 pasarela bloquea las DNS en el estado previo a la autenticación.
• DHCP asigna un servidor DNS al que el dispositivo no puede acceder.

Android añade un matiz. Si un visitante ha configurado un nombre de host de DNS privado específico, Android espera DNS sobre TLS en el puerto 853. En modo automático, recurre a las DNS habituales.

El grupo DHCP se ha agotado

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

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

RADIUS nunca entrega el Access-Accept

RADIUS (Remote Authentication Dial-In User Service) transmite la decisión de inicio de sesión desde el servidor de autenticación a su pasarela. El servidor responde Access-Accept o Access-Reject, según define la norma RFC 2865. A continuación, la pasarela permite el acceso o lo mantiene cerrado.Un visitante que completa el formulario pero permanece sin conexión casi siempre significa que la pasarela perdió el Access-Accept. Las tres causas habituales son:

• Un secreto compartido no coincidente.
• Un cortafuegos que bloquea los puertos UDP 1812 (autenticación) o UDP 1813 (contabilidad). RFC 2865 y RFC 2866 definen estos puertos.
• La dirección del servidor no es correcta en el controlador.

El certificado del propio portal ha caducado

Su página de inicio de sesión se ofrece a través de HTTPS. Si su certificado TLS caduca, todos los navegadores modernos bloquean la página con una advertencia de seguridad. La redirección funciona perfectamente, pero el visitante sigue sin poder iniciar sesión.

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

Trabaje en la pila por orden. Cada comprobación descarta una capa, así que deténgase en el primer fallo.

1. ¿Tiene el dispositivo una dirección IP válida? Ejecute ipconfig /all en Windows, o compruebe los detalles de la red en un teléfono. Una dirección 169.254.x.x, o la ausencia de dirección, apunta a DHCP. Compruebe la utilización del fondo de direcciones en el servidor DHCP. Por encima del 90 %, está cerca del agotamiento.
2. ¿Resuelve el DNS? 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, el DNS de preautenticación está bloqueado o el servidor DNS asignado por DHCP es incorrecto.
3. ¿Recibe la prueba un 302? Realice una captura de paquetes en la VLAN de invitados o navegue a una de las URL de prueba de HTTP. Debería ver la prueba y, a continuación, un HTTP 302 que apunta al portal. Una prueba sin respuesta significa que la ACL la descarta. La ausencia total de prueba significa que el dispositivo cree que ya está en línea, a menudo por un estado en caché. Olvide la red y vuelva a conectarse.
4. ¿Se carga completamente la página de inicio de sesión? Abra las herramientas para desarrolladores del navegador (F12) y observe la pestaña de red. Las solicitudes bloqueadas a dominios de terceros apuntan a deficiencias en el walled garden.
5. ¿Recibe la pasarela un Access-Accept? Compruebe los registros del controlador RADIUS. Un inicio de sesión correcto va seguido de un Accounting-Request con el estado Start. Si no aparece ningún registro de contabilidad tras el inicio de sesión, la ruta RADIUS está rota.

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

Caso práctico: un centro de conferencias de 1.500 asientos en hora punta

Situación. Un centro de conferencias operaba su red de asistentes en una única subred /24 con una concesión DHCP de ocho horas. Las ponencias principales de la mañana transcurrieron sin problemas. Después del almuerzo, los asistentes que llegaban para las sesiones de la tarde veían el mensaje "conectado, sin internet". El servicio de asistencia lo trató como un fallo del portal y reinició el controlador dos veces.

Qué se hizo. El paso 1 del diagnóstico detectó nuevos dispositivos con 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. La dirección que deja un asistente al salir vuelve ahora al pool en 30 minutos, no en ocho horas. La solución requirió solo una ventana de cambio y ningún hardware nuevo.

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

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

Qué se hizo. El responsable de TI probó el flujo en un iPhone, un teléfono Android y un portátil Windows. Las herramientas de desarrollador del portátil 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 incluyó en el walled garden.

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

Caso práctico: una red de 40 tiendas minoristas tras renovar el firewall

Situación. Una empresa minorista sustituyó los firewalls de 40 tiendas durante un fin de semana. El lunes, los compradores de todas las tiendas renovadas podían completar el formulario de inicio de sesión, pero permanecían sin conexión. Las tiendas que aún no se habían renovado funcionaban con normalidad.

Qué se hizo. El paso 5 no encontró registros de contabilidad de las tiendas renovadas. La plantilla del nuevo firewall denegaba el tráfico UDP saliente por defecto, bloqueando los puertos 1812 y 1813. El equipo añadió reglas salientes explícitas a la plantilla y la aplicó a las 40 tiendas.

Resultado. Los registros de contabilidad reaparecieron en todas las tiendas tras la actualización. Dado que solo fallaban las tiendas renovadas, el patrón apuntó directamente a la plantilla y descartó problemas en el WiFi.

¿Cómo se soluciona 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 se resumen principalmente en conocer cómo se comporta cada uno de ellos.

En su controlador

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

1. Apunte la red 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 el tráfico HTTPS.
3. Permita DNS y DHCP antes de la autenticación.
4. Añada las entradas del walled garden: extremos de Purple, extremos del proveedor de identidades y dominios de recursos de la página de inicio de sesión.
5. Introduzca las direcciones del servidor RADIUS y el secreto compartido de su panel de control de Purple. A continuación, confirme que el firewall permite la salida 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 Ajustes y vuelva a conectarse. Esto fuerza una nueva comprobación.

Las versiones recientes de iOS y macOS también son compatibles con la API de portal cautivo. Permite que la red anuncie su portal a través de la opción DHCP 114, definida en el RFC 8910, lo que reduce la dependencia de la intercepción. Si el asistente se abre pero permanece en blanco, compruebe 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 no aparece nunca, confirme que la pasarela redirige 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 depende de la comprobación HTTP de NCSI y de su verificación de DNS. Si el portal no se abre automáticamente, navegue a cualquier sitio HTTP no seguro para activar la redirección manualmente. Si aparece el mensaje persistente "Sin Internet" tras iniciar sesión, suele significar que la pasarela sigue redirigiendo la comprobación. En ese caso, la pasarela 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 realiza 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 producirse fallos de redirección en la red WiFi para invitados?

La mayoría de los incidentes recurrentes se deben a cambios y no a la configuración inicial. 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 caducado pueden superar las pruebas sin ser detectados. Incorpore estos controles a su proceso de gestión de cambios:

• Realice pruebas en tres plataformas tras cada cambio. Utilice un iPhone, un teléfono Android y un portátil con Windows. Si una plataforma falla mientras las demás funcionan correctamente, busque primero una omisión en el walled garden.
• Dimensione para el pico, no para la media. Calcule el número máximo de dispositivos concurrentes y añada margen. Las redes de visitantes temporales suelen utilizar concesiones de 15 a 30 minutos.
• Configure las sesiones para que coincidan con la visita. Los establecimientos de hostelería y comercio minorista suelen configurar sesiones de 24 horas, de modo que el invitado inicia sesión una vez por estancia o visita.
• Supervise los volúmenes de inicio de sesión a diario. En WiFi Analytics de Purple se informan los inicios de sesión por establecimiento. Una caída repentina en una ubicación le advierte de un fallo en RADIUS o en el portal cautivo, a menudo antes de que los visitantes se quejen.
• Ponga los certificados y los secretos compartidos bajo control de cambios. Calendorice la fecha de caducidad del certificado del portal. 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. PCI DSS considera la segmentación como la forma de mantener la red de invitados fuera del alcance de su entorno de datos de titulares de tarjetas.
• Planifique para la aleatorización de 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 recurrentes que vuelvan a iniciar sesión.
• Recopile el consentimiento correctamente. El GDPR exige un consentimiento informado y afirmativo para los datos de marketing. Las opciones de inclusión consciente de Purple presentan una elección independiente para cada finalidad.

Exima a los visitantes recurrentes del portal cautivo

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

• Passpoint es la certificación del sector basada en 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, federa a los proveedores de identidad. De este modo, las credenciales existentes de un visitante funcionan en los establecimientos participantes.

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

Dónde encaja Purple

Purple Guest WiFi se ejecuta como una superposición en la nube independiente del hardware, por lo que las fallas de redirección se solucionan en la configuración, no con hardware nuevo. Purple presta 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 funciona con un tiempo de actividad del 99,999 % y cuenta con las certificaciones ISO 27001, Cyber Essentials y B Corp. También cumple con el GDPR y la CCPA.

Cuando un portal falla, la causa es casi siempre local: una regla de sondeo, una entrada de jardin vallado, un conjunto DHCP o una regla de cortafuegos.

Los patrones se repiten en todos los sectores:

• Los hoteles experimentan fallos de redireccion en los picos de registro de entrada.
• El sector minorista los sufre tras cambios en los cortafuegos de toda su red de tiendas.
• Los trenes y las estaciones se enfrentan a la presion de DHCP a medida que los pasajeros embarcan en oleadas.
• El sector sanitario necesita un servicio de WiFi que funcione sin que el personal clinico tenga que atender llamadas de soporte tecnico.

Preguntas frecuentes

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

Si. Purple es independiente del hardware y se ejecuta como una superposicion en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Mantiene sus puntos de acceso y controladores actuales. Solo tiene que apuntar su SSID al portal cautivo de Purple, anadir las entradas de jardin vallado y los detalles de RADIUS de la guia de integracion de Purple y, a continuacion, realizar la prueba. No es necesario desmantelar ni sustituir nada.

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

No. En casi todos los casos, el fallo se debe a la configuracion: un sondeo bloqueado, una brecha en el jardin vallado, un DNS de preautenticacion, un conjunto DHCP agotado o una regla de cortafuegos de RADIUS. Cada uno de estos problemas se soluciona en el controlador, cortafuegos o servidor DHCP que ya utiliza. El hardware solo supone un problema cuando la densidad de los puntos de acceso no puede dar servicio a su numero maximo de dispositivos, algo que mostrara un estudio de cobertura.

¿Que se necesita para migrar nuestro WiFi a Purple?

Migrar a Purple es un proyecto de configuracion, no de instalacion. En cada controlador, debe configurar el SSID para que apunte al portal externo de Purple y anadir los ajustes de jardin vallado y RADIUS. A continuacion, confirme las reglas de cortafuegos para UDP 1812 y 1813. Despues, cree su pagina de inicio de sesion y las opciones de consentimiento en Purple y realice pruebas en iOS, Android y Windows. Las redes multisede pueden crear plantillas de la configuracion del controlador.

¿Cumple un portal cautivo con el GDPR?

Si, siempre que el consentimiento sea informado, especifico y prestado libremente. El GDPR exige una eleccion afirmativa independiente para cada finalidad, como el correo electronico de marketing, y desestima las casillas preseleccionadas. Las opciones de suscripcion de eleccion consciente de Purple presentan cada opcion por separado. Purple cuenta con la certificacion ISO 27001, posee la acreditacion Cyber Essentials y cumple con el GDPR y la norma CCPA. Esto proporciona a su delegado de proteccion de datos las normas sobre las que preguntara.

¿Pueden los visitantes habituales omitir la pagina de inicio de sesion?

Si. Passpoint y OpenRoaming permiten que un dispositivo se conecte automaticamente mediante un perfil almacenado o una identidad federada. Ambos utilizan la autenticacion IEEE 802.1X con cifrado WPA2 o WPA3-Enterprise, por lo que no hay ninguna redireccion al portal cautivo que pueda fallar en las visitas recurrentes. Muchos establecimientos utilizan ambos sistemas: un portal cautivo para los visitantes nuevos y la captura de datos, y OpenRoaming para invitados habituales, pasajeros y estudiantes.

¿Como sabremos si los inicios de sesion empiezan a fallar?

Supervise los volúmenes de inicio de sesión por recinto. 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 destaca frente a su patrón habitual y el resto de sus recintos. Esa caída suele indicar un fallo de RADIUS, del jardín vallado o del DHCP provocado 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.

¿Deberíamos utilizar 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 ninguna de las dos cosas. Una clave precompartida cifra el tráfico con WPA2 o WPA3-Personal. Sin embargo, no le ofrece información sobre quién se ha conectado y la contraseña acaba difundiéndose. Un portal cautivo recopila datos propios con consentimiento, y Passpoint o OpenRoaming añade un acceso automático y cifrado para las visitas recurrentes.