Saltar al contenido principal
Español

Por qué su captive portal no se carga en iPhone: solucionar errores de Apple CNA

Solucione los fallos de apertura del captive portal en iPhone e iOS. Descubra cómo Apple CNA, iCloud Private Relay y la aleatorización de direcciones MAC interrumpen los inicios de sesión WiFi, y cómo solucionarlo.

Por Tom HackettPublicado
📖 10 min de lectura1,984 palabras2 ejemplos prácticos3 preguntas de práctica6 definiciones clave

Video overview

Escuchar esta guía

Ver transcripción del podcast
[Intro Music: Upbeat, modern electronic synth-pop with clean piano highlights, establishing a professional, tech-forward tone] **Host (Senior Consultant)**: Hola y bienvenidos a este Informe Técnico de Purple. Soy su anfitrión, y hoy vamos a analizar en detalle uno de los problemas más comunes —y, sinceramente, más frustrantes— a los que se enfrentan los administradores de redes, directores de TI y directores de operaciones de recintos en la actualidad. Todos hemos pasado por eso. Ha pasado semanas planificando, configurando y desplegando una red WiFi para invitados de última generación para su hotel, centro comercial o estadio. Cuenta con los puntos de acceso más recientes, un controlador robusto y una página de bienvenida atractiva lista para capturar datos de los invitados y fomentar la interacción. Pero entonces, empiezan a llegar los tickets de soporte. Y todos dicen exactamente lo mismo: "Me he conectado a la red WiFi para invitados en mi iPhone, pero la página de inicio de sesión no se carga". Para el invitado, su WiFi simplemente no funciona. Pero para nosotros, como ingenieros y arquitectos de redes, sabemos que se está librando una compleja batalla técnica bajo el capó de iOS. Hoy vamos a desgranar exactamente por qué su Captive Portal no se carga en los iPhones, cómo funciona la lógica de detección en segundo plano de Apple y los pasos de mitigación que puede implementar en su red este trimestre. [Brief transitional musical swell] **Host**: Comencemos con el análisis técnico detallado. ¿Por qué un iPhone se conecta a una red WiFi para invitados pero no muestra la pantalla de inicio de sesión? Para entender esto, debemos observar el **Captive Network Assistant** de Apple, o **CNA**. Cuando un iPhone se asocia con un SSID abierto y recibe una dirección IP a través de DHCP, no se limita a esperar a que el usuario abra un navegador. En su lugar, un demonio del sistema en segundo plano lanza inmediatamente una solicitud HTTP GET simple a una URL muy específica: `http://captive.apple.com/hotspot-detect.html`. Este sondeo en segundo plano utiliza un User-Agent del sistema exclusivo llamado `CaptiveNetworkSupport`. El demonio CNA busca una respuesta muy concreta. Si los servidores de Apple devuelven un código de estado HTTP **200 OK** con un cuerpo que contiene exactamente la palabra "Success", iOS concluye que la red tiene acceso ilimitado a internet. Establece silenciosamente la conexión WiFi como la interfaz de enrutamiento principal y el usuario continúa con su actividad. Sin embargo, si la pasarela de su red intercepta esa solicitud HTTP y devuelve cualquier otra cosa —como una redirección HTTP 302 o 307, o una página HTML personalizada— iOS reconoce instantáneamente que está detrás de un Captive Portal. Inmediatamente inicia la aplicación nativa **Websheet**. Se trata de esa conocida ventana modal emergente que muestra su página de inicio de sesión para invitados. Ahora, aquí está el primer gran obstáculo de ingeniería: **El Walled Garden**. Muchos ingenieros de red cometen el error de incluir los dominios de éxito de Apple, como `captive.apple.com`, en la lista de permitidos de sus listas de control de acceso de autenticación previa. Piensan: "Bueno, es un dominio de Apple, debería dejarlo pasar". Pero si lo incluyes en la lista de permitidos, el sondeo en segundo plano llega con éxito a los servidores de Apple, recibe la respuesta "Success" e iOS asume que no hay ningún Captive Portal. ¡La Websheet nunca se activa! Mientras tanto, el usuario tiene bloqueado el acceso a cualquier otro sitio web. Por lo tanto, regla número uno: **Nunca incluyas captive.apple.com en tu walled garden.** [Breve efecto de sonido de transición] **Anfitrión**: Pero ¿qué pasa con las funciones de privacidad modernas de iOS? Incluso con un walled garden perfecto, funciones como **iCloud Private Relay** y las **direcciones MAC privadas** están cambiando las reglas del juego. Hablemos de iCloud Private Relay, introducido en iOS 15. Esta función cifra y enruta el tráfico DNS y HTTP de Safari a través de una arquitectura de proxy de doble salto. Cuando un usuario con Private Relay activo se conecta a tu WiFi de invitados, el sondeo HTTP en segundo plano se encapsula dentro de un túnel cifrado. Debido a que la puerta de enlace de tu red no puede inspeccionar ni interceptar este paquete cifrado, no puede inyectar la redirección. El sondeo falla silenciosamente y el iPhone simplemente muestra una advertencia de "Sin conexión a Internet". Sin portal, sin inicio de sesión, solo fricción. Afortunadamente, existe una mitigación programática a nivel de red para esto. Apple ha diseñado Private Relay para que respete los bloqueos a nivel de red. Si tu servidor DNS local devuelve una respuesta **NXDOMAIN** para los dominios de Private Relay de Apple —específicamente `mask.icloud.com` y `mask-h2.icloud.com`— iOS reconoce que la red es incompatible con Private Relay. Inmediatamente mostrará un aviso del sistema preguntando al usuario si desea "Usar sin Private Relay" para esta red. En el momento en que pulsan esa opción, se omite el túnel cifrado, se intercepta el sondeo HTTP y tu Captive Portal se carga perfectamente. A continuación, las **direcciones MAC privadas** y las nuevas **direcciones MAC rotativas** en iOS 18. Por defecto, los iPhones aleatorizan su dirección MAC para cada SSID. En iOS 18, esta dirección rota periódicamente incluso estando conectado a la misma red. Si tu controlador inalámbrico realiza el seguimiento de las sesiones de invitados autenticadas únicamente por la dirección MAC, una rotación repentina hará que la puerta de enlace trate al iPhone como un dispositivo nuevo y no autenticado. El invitado se desconecta abruptamente y se ve obligado a iniciar sesión de nuevo. Para mitigar esto, los espacios empresariales deben alejarse del simple seguimiento basado en MAC. Plataformas como **Purple** resuelven esto depositando una cookie segura y persistente en la sesión del navegador o, mejor aún, mediante la transición de los espacios a **Passpoint**, también conocido como Hotspot 2.0. Passpoint utiliza perfiles seguros 802.1X para autenticar de forma automática y segura a los invitados que regresan sin mostrar nunca una página de Captive Portal. Es seguro, es fluido y evita por completo las limitaciones del CNA. [Breve aumento musical de transición] **Presentador**: Ahora, hablemos de los perfiles de DNS personalizados y las VPN locales. Muchos usuarios técnicos instalan perfiles de DNS personalizados como NextDNS o AdGuard que fuerzan DNS-over-HTTPS cifrado. Debido a que estos perfiles omiten sus servidores DNS asignados por DHCP local, su puerta de enlace no puede falsificar la búsqueda de DNS para `captive.apple.com`. Del mismo modo, los perfiles de VPN "Siempre activados" intentarán establecer un túnel cifrado en el instante en que se asigne una IP. Si la VPN tiene éxito, elude su redirección; si se bloquea, paraliza la conexión. Para estos usuarios, el último recurso manual es el truco de **neverssl.com**. Si un invitado está conectado a su WiFi pero el portal no se carga, dígale que abra Safari y escriba `neverssl.com` en la barra de direcciones. Debido a que este dominio es estrictamente HTTP no cifrado, se garantiza que la puerta de enlace interceptará el tráfico del puerto 80 y forzará la carga de la redirección, eludiendo cualquier interferencia de VPN o DNS personalizado. [Efecto de sonido: Timbre de transición rápida] **Presentador**: Repasemos una ronda rápida de preguntas y respuestas sobre las dudas más comunes que recibimos de los equipos de soporte de los establecimientos. *Pregunta uno: ¿Por qué mi iPhone muestra "Sin conexión a Internet" en naranja debajo del nombre de la red WiFi?* **Respuesta**: Esto significa que el iPhone completó la asociación WiFi y obtuvo una dirección IP, pero la sonda CNA de fondo no pudo obtener una respuesta de los servidores de éxito de Apple y no se redirigió correctamente, a menudo debido a iCloud Private Relay o a una VPN activa. *Pregunta dos: ¿Podemos simplemente desactivar el mini-navegador CNA por completo en nuestra red?* **Respuesta**: Sí, la mayoría de las controladoras de LAN inalámbrica empresariales tienen un ajuste llamado "CNA Bypass" o "Captive Portal Bypass". Cuando está activado, la controladora simula la sonda de éxito de Apple, diciéndole al iPhone que tiene acceso total a Internet. Esto evita que aparezca la ventana emergente de Websheet, pero depende de que el usuario abra manualmente Safari para activar la redirección, lo que a veces puede generar aún más confusión en el usuario. *Pregunta tres: ¿Qué es el problema de la sonda de post-autenticación?* **Respuesta**: Después de que el invitado inicia sesión, la Websheet de CNA ejecuta una sonda secundaria para verificar el acceso a Internet. Si su puerta de enlace los redirige a una página de destino pero continúa bloqueando los dominios de éxito de Apple, el botón superior derecho sigue bloqueado en "Cancelar". Al hacer clic en "Cancelar", se desconectan de la red WiFi. Debe asegurarse de que los dominios de éxito de Apple sean totalmente accesibles después de la autenticación. [Breve subida musical de transición] **Presentador**: Para terminar, analicemos el impacto empresarial en el mundo real. Optimizar su Captive Portal no es solo una cuestión de elegancia técnica; se trata de rentabilidad. Hace poco trabajamos con un grupo de resorts de lujo de 5 estrellas que experimentaba una tasa de fallos del 35% en las conexiones WiFi de sus huéspedes, lo que generaba más de 450 quejas en recepción cada semana. Al reestructurar su walled garden, bloquear los dominios de Private Relay a nivel de DNS para forzar el enrutamiento local e implementar la solución de **Guest WiFi de Purple**, vieron cómo los tickets de soporte por WiFi en recepción disminuían un **92%** en solo 30 días. Las puntuaciones de satisfacción de los huéspedes se dispararon y registraron miles de perfiles de huéspedes verificados. Si desea asegurarse de que su red WiFi para huéspedes interactúe a la perfección con el Captive Network Assistant de Apple al tiempo que maximiza la captura de datos y minimiza los costes de soporte, visite **purple.ai**. Nuestra plataforma está diseñada para gestionar de forma nativa todos estos matices específicos de iOS. Gracias por escuchar este Informe Técnico de Purple. Implemente estas estrategias de DNS y walled garden esta semana y vea cómo desaparecen sus tickets de soporte. Hasta la próxima, mantenga sus conexiones seguras y el registro de sus huéspedes sin complicaciones. [Música de cierre: Sintetizador electrónico de ritmo alegre que se desvanece lentamente]

Parte de nuestra serie principal: Guía de captive portal →

Resumen ejecutivo

El fallo de inicio de sesión en el Captive Portal en dispositivos iOS (iPhone y iPad) es una de las causas principales de quejas de conexión WiFi de invitados en entornos de hostelería, comercio, sanidad y corporativos. Cuando un dispositivo iOS se asocia a una red inalámbrica abierta o con autenticación web, el demonio Captive Network Assistant (CNA) de Apple inicia una serie de sondeos HTTP en segundo plano. Si estos sondeos se bloquean, se desvían de forma incorrecta o se interceptan de manera inapropiada, la página de bienvenida del Captive Portal no se carga, lo que deja al usuario sin acceso a Internet y sin una forma obvia de iniciar sesión.

Esta guía técnica detalla el funcionamiento interno de la detección de Apple CNA, analiza las funciones de privacidad clave de iOS - incluidas iCloud Private Relay, direcciones WiFi privadas (aleatorización de MAC) y DNS cifrado - y proporciona estrategias de mitigación paso a paso para ingenieros de redes y operadores de recintos.

¿Tiene problemas con el abandono de WiFi de invitados en iOS?

La plataforma de WiFi de invitados gestionada en la nube de Purple gestiona los sondeos de Apple CNA, iCloud Private Relay y la aleatorización de MAC de forma automática, ofreciendo una incorporación fluida al Captive Portal en todos los dispositivos iOS y Android.

Explore Purple Guest WiFi →

Análisis técnico profundo

Lógica de detección y mecanismo de sondeo de Apple

Cuando un iPhone se conecta a un punto de acceso inalámbrico, la pila de red de iOS envía inmediatamente un demonio llamado captivenetworkd. Este demonio emite solicitudes HTTP GET de texto plano a URL de verificación de Apple predefinidas, que incluyen:

  • http://captive.apple.com/hotspot-detect.html
  • http://www.apple.com/library/test/success.html
  • http://gsp1.apple.com/pep/gcc
+-------------------+       HTTP GET captive.apple.com       +----------------------+
|   iPhone (iOS)    | -------------------------------------> |  Network Controller  |
+-------------------+                                        +----------------------+
          |                                                             |
          | <--- HTTP 302 Redirect (https://portal.purple.ai) ---------+
          |
          v
[ Launch CNA Websheet ] ---> [ Render Purple Captive Portal ]

El demonio evalúa el estado y el cuerpo de la respuesta HTTP:

  1. Respuesta correcta (HTTP 200 con <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>"): El sistema operativo concluye que la red proporciona acceso a internet sin restricciones. No se muestra ninguna página de inicio (splash page).
  2. Respuesta de redirección (HTTP 302 / 307): La puerta de enlace de la red intercepta la solicitud HTTP del puerto 80 y redirige al cliente a la URL del Captive Portal. iOS reconoce la redirección e inicia la CNA Websheet (una ventana de navegador modal especializada).
  3. Tiempo de espera de conexión agotado o reinicio: Si la puerta de enlace descarta los paquetes del puerto 80 o no responde a las consultas DNS, la sonda agota el tiempo de espera. iOS muestra un aviso de "Sin conexión a internet" debajo del nombre del SSID en Ajustes, pero no muestra la página de inicio de sesión.

Sondeo posterior a la autenticación (el desafío del botón "Listo")

Una vez que el usuario envía sus credenciales o acepta los términos de servicio en la splash page, el controlador de LAN inalámbrica (WLC) actualiza el estado de la ACL del cliente a "autenticado". El demonio CNA emite inmediatamente un sondeo HTTP de seguimiento a captive.apple.com.

Si el segundo sondeo devuelve HTTP 200 "Success", el botón de la esquina superior derecha de la CNA Websheet cambia de "Cancelar" a "Listo". Si la red no permite el acceso HTTP fuera de banda inmediatamente después de la autenticación, el botón sigue bloqueado en "Cancelar" y, al tocarlo, el dispositivo puede desconectarse por completo de la red WiFi.

Factores de interferencia específicos de iOS

1. iCloud Private Relay

Introducido en iOS 15, iCloud Private Relay es un servicio de Apple diseñado para proteger la privacidad de la navegación web. Cuando está habilitado, Safari y el tráfico HTTP no cifrado se cifran y se enrutan a través de dos retransmisiones de Internet independientes:

[ iPhone ] === Encrypted QUIC/TLS ===> [ Apple Ingress Proxy ] ---> [ Egress Proxy ] ---> [ Web Target ]
  • El problema: Private Relay cifra las solicitudes DNS mediante Oblivious DNS-over-HTTPS (ODoH) y canaliza el tráfico HTTP mediante QUIC (puerto UDP 443). Dado que los routers de la puerta de enlace local no pueden inspeccionar ni interceptar el tráfico QUIC cifrado, no pueden inyectar la redirección HTTP 302 estándar.
  • Impacto: El sondeo HTTP inicial a captive.apple.com se canaliza fuera de la puerta de enlace local, lo que provoca tiempos de espera de conexión agotados y la pérdida de las splash pages.

2. Direcciones MAC privadas e identificadores rotativos

A partir de iOS 14 y con una mayor expansión en iOS 18, Apple habilita la Dirección WiFi privada de forma predeterminada. En lugar de utilizar la dirección MAC de hardware permanente del dispositivo, iOS genera una dirección MAC aleatoria para cada SSID.

  • El problema: En las redes que utilizan autorización de sesión basada en MAC (donde los usuarios autenticados tienen permitido el acceso durante 24 horas según la dirección MAC), la rotación de MAC hace que la puerta de enlace de la red considere a los dispositivos que regresan como clientes nuevos y no autenticados.
  • Impacto: A los usuarios se les presenta repetidamente la splash page del Captive Portal, lo que genera una mala experiencia de usuario y tickets de soporte técnico.

3. Perfiles de DNS cifrados (DoH / DoT)

Los usuarios con perfiles de configuración personalizados de iOS (como NextDNS, Cloudflare 1.1.1.1 o ajustes DNS de MDM corporativos) transmiten todas las consultas DNS a través de HTTPS cifrado (DoH) o TLS (DoT) directamente a resolutores externos.

  • El problema: El servidor DNS de la red local no puede interceptar ni suplantar las solicitudes DNS para captive.apple.com o dominios inexistentes.
  • Impacto: La resolución DNS inicial elude por completo el controlador local, lo que evita que se active la redirección al portal.

-

Guía de implementación y mitigación

Diseño de Walled Garden (ACL de autenticación previa)

Para garantizar una visualización fiable del Captive Portal en iOS, los ingenieros de red deben configurar con precisión la lista de control de acceso (ACL) del Walled Garden de autenticación previa:

Tipo de regla Destino / Dominio Propósito
Permitir *.purple.ai, *.purpleshield.com Permite que los clientes no autenticados accedan a la infraestructura y activos del portal de Purple.
Interceptar HTTP (Puerto TCP 80) a cualquier destino Intercepta el tráfico web HTTP sin cifrar para activar la redirección 302.
Bloquear / NXDOMAIN mask.icloud.com, mask-h2.icloud.com Devuelve NXDOMAIN para indicar que Private Relay no está disponible en la red local.
NO incluir en la lista de permitidos captive.apple.com, www.apple.com NO se debe incluir en la lista de permitidos. Hacerlo provoca que los sondeos tengan éxito sin iniciar el portal.

Configuración paso a paso del WLC (Ejemplo de Cisco Catalyst / Meraki)

  1. Configurar la interceptación de DNS: Configure el servidor DHCP para que asigne la dirección IP de la puerta de enlace como el servidor DNS primario para los clientes no autenticados.
  2. Configurar la señalización de Private Relay: Añada una regla de reescritura de DNS en los servidores DNS locales:
    mask.icloud.com      IN A 0.0.0.0 (o NXDOMAIN)
mask-h2.icloud.com   IN A 0.0.0.0 (o NXDOMAIN)
    Cuando iOS recibe NXDOMAIN para estos nombres de host, muestra el aviso del sistema: "Esta red bloquea iCloud Private Relay. ¿Quieres utilizar esta red sin Private Relay?" Al pulsar Usar sin Private Relay se restablece la redirección estándar del portal.
  3. Configurar el tiempo de espera de la sesión: Establezca el tiempo de espera de la sesión de la puerta de enlace en función de los pares de IP/MAC o elimine las cookies de autorización persistentes.

-

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.

Buenas prácticas y estándares del sector

La gestión del acceso de invitados a la red inalámbrica a gran escala requiere el cumplimiento de los estándares de red modernos:

  • Transición a WPA3-Personal (OWE): Los portales de invitados heredados funcionan en SSIDs abiertos y sin cifrar. Los entornos empresariales deberían adoptar Opportunistic Wireless Encryption (OWE) (IEEE 802.11aq) para ofrecer cifrado individualizado sin contraseñas.
  • Cumplimiento de PCI-DSS y GDPR: Los portales de invitados deben aislar el tráfico de invitados de las redes de pago PCI-DSS. Al capturar datos de contacto, los portales deben presentar casillas de verificación de consentimiento explícitas y desglosadas de acuerdo con el GDPR, gestionadas fácilmente a través de una plataforma de WiFi Analytics.
  • Implementar Passpoint (Hotspot 2.0): para eliminar por completo la fricción del Captive Portal, los establecimientos pueden implementar Passpoint (Hotspot 2.0). Passpoint utiliza una autenticación de estilo celular para conectar los dispositivos iOS de forma segura y automática a través de un perfil preinstalado, evitando por completo el demonio CNA.

Resolución de problemas y mitigación de riesgos

Ruta de autorremediación para el usuario final

  1. Desactivar iCloud Private Relay para la red: abra Ajustes > WiFi, pulse el icono (i) junto al nombre de la red y desactive Limitar seguimiento de dirección IP.
  2. Desactivar Dirección WiFi privada: en el mismo menú de ajustes de red, desactive Dirección WiFi privada si se requiere acceso basado en MAC.
  3. Forzar la redirección del portal a través de Safari: abra Safari e introduzca la dirección HTTP sin cifrar: http://neverssl.com Dado que neverssl.com no utiliza HTTPS, el router local interceptará la solicitud de forma fiable y cargará el portal.

Ruta de diagnóstico para el ingeniero de red

                  [ iPhone se conecta al SSID de invitados ]
                                  |
                                  v
                        [ ¿IP DHCP asignada? ]
                        /                    \
                     (No)                    (Sí)
                      /                        \
        [ Comprobar pool DHCP ]      [ ¿Resuelve captive.apple.com? ]
                                        /                             \
                                     (No)                             (Sí)
                                      /                                 \
                         [ Comprobar ACL de DNS ]           [ ¿Apple en lista blanca? ]
                                                             /                       \
                                                          (Sí)                       (No)
                                                           /                           \
                                            [ ELIMINAR de Walled Garden ]    [ ¿Redirige puerto 80? ]
                                                                               /                   \
                                                                            (No)                   (Sí)
                                                                             /                       \
                                                                 [ Corregir redirección WLC ] [ Carga CNA Websheet ]

ROI e impacto empresarial

Optimizar la experiencia de incorporación a la red WiFi para invitados en iOS tiene un impacto directo y medible en las operaciones del establecimiento y en las métricas empresariales.

Caso de éxito en hostelería: Grupo de resorts de cinco estrellas

  • Desafío: un grupo hotelero de lujo con 12 propiedades sufría una tasa de fallos de conexión a la red WiFi para invitados del 35%, lo que generaba más de 450 quejas semanales en recepción.
  • Implementación: El equipo de TI reestructuró su walled garden, desactivó el seguimiento de sesiones basado en MAC y desplegó la solución Guest WiFi de Purple con una gestión optimizada de CNA.
  • Resultados: Las quejas relacionadas con el WiFi en recepción disminuyeron un 92% en un plazo de 30 días. Las puntuaciones de satisfacción del cliente (CSAT) aumentaron 18 puntos y el recinto captó 40.000 nuevas direcciones de correo electrónico verificadas en el primer trimestre.

Caso de estudio de retail: Operador nacional de centros comerciales

  • Desafío: Un operador de retail con 45 centros comerciales tenía dificultades para fomentar la interacción con los visitantes porque iCloud Private Relay impedía que el Captive Portal se cargara en el 40% de los dispositivos iOS.
  • Implementación: Se implementó el bloqueo de Private Relay a nivel de red (devolviendo NXDOMAIN para los dominios de relay de Apple para forzar el enrutamiento local) y se desplegó WiFi Analytics.
  • Resultados: Las tasas de finalización del portal aumentaron del 58% al 94%. El equipo de marketing monetizó el inventario recuperado del portal con campañas de medios de retail localizadas, generando 120.000 $ adicionales en ingresos publicitarios por trimestre.

Recursos relacionados

Para los equipos de red que despliegan sistemas inalámbricos para invitados en empresas, estos recursos proporcionan un contexto técnico más profundo:

La plataforma de Guest WiFi de Purple presta servicio a recintos de hostelería, retail, sanidad y transporte en todo el mundo, ofreciendo experiencias de inicio de sesión para invitados optimizadas para CNA a gran escala.

Definiciones clave

Apple Captive Network Assistant (CNA)

Un demonio del sistema operativo iOS y macOS que sondea la conectividad a internet e inicia automáticamente un modal WebKit restringido (WebSheet) cuando se detecta un captive portal.

Controla si la página de inicio de sesión aparece automáticamente en los iPhones al conectarse a una red WiFi de invitados.

URL de sondeo canario

Un endpoint HTTP ligero (como http://captive.apple.com/hotspot-detect.html) solicitado por los sistemas operativos cliente para verificar la accesibilidad a internet sin restricciones.

Si la respuesta del sondeo se modifica o se redirecciona, el sistema operativo activa su controlador de captive portal.

API de captive portal RFC 8908

Un protocolo estándar IETF que proporciona un endpoint de API donde los dispositivos pueden consultar el estado de cautividad de la red, los términos del establecimiento y el tiempo de sesión restante a través de JSON.

Reemplaza el secuestro HTTP heredado con una detección de red cautiva estructurada y criptográficamente segura.

Opción DHCP 114 (Captive-Portal)

Una opción DHCP (RFC 8910) que pasa la URI de la API de captive portal RFC 8908 al dispositivo cliente durante la asignación inicial de direcciones de Capa 3.

Señala la cautividad a iOS 14+ inmediatamente durante la adquisición de la IP, evitando la manipulación de DNS.

iCloud Private Relay

Un servicio de privacidad de Apple que redirige el tráfico de Safari y el DNS no cifrado a través de una arquitectura de proxy cifrado de doble salto.

Puede enmascarar las consultas DNS previas a la autenticación a menos que la red local emita una señal explícita de deterioro de red (NXDOMAIN).

Dirección WiFi privada (aleatorización de MAC)

Una función de privacidad en iOS 14+ que genera una dirección MAC aleatoria única por SSID para evitar el seguimiento físico entre diferentes establecimientos.

Puede desincronizar las sesiones de contabilidad de RADIUS si las direcciones MAC rotan a mitad de la sesión o durante la reautenticación.

Ejemplos prácticos

Un hotel de lujo que implementa WLC Cisco Catalyst 9800 observa que los usuarios de iPhone invitados nunca reciben la pantalla de bienvenida de captive portal cuando se conectan al SSID WiFi de invitados abierto. Los portátiles Android y Windows cargan el portal de inmediato. ¿Cómo debe el equipo de red diagnosticar y solucionar el problema de detección de Apple CNA?

  1. Inspeccionar la ACL de redirección previa a la autenticación: verifique que la ACL de redirección de Cisco 9800 deniegue (omita) el puerto UDP 53 DNS y permita el puerto TCP 80 HTTP para activar la redirección. 2. Comprobar la lista blanca de sondeo de Apple: asegúrese de que captive.apple.com NO esté en la lista blanca de la zona de acceso limitado (walled garden) previa a la autenticación antes de la redirección; incluirlo en la lista blanca hace que iOS piense que internet está abierto y suprima el portal. 3. Verificar HTTP 302 frente a 307: configure el mapa de parámetros de autenticación web de la WLC para devolver una redirección HTTP 302 Found con el FQDN del portal. 4. Desactivar la interceptación HTTPS: asegúrese de que el tráfico HTTPS del puerto 443 se descarte o se rechace en lugar de ser interceptado con un certificado no fiable. 5. Implementar la opción DHCP 114: añada la opción 114 ascii https://app.purplewifi.net/api/v1/capport al grupo DHCP de invitados para la detección nativa de iOS 14-18.
Comentario del examinador: Los dispositivos Apple dependen de una coincidencia estricta para el token de éxito de captive.apple.com. Si el dominio de sondeo se permite prematuramente a través de la zona de acceso limitado (walled garden), iOS asume erróneamente que hay internet abierto y nunca activará la WebSheet.

El administrador de red de un estadio observa que los usuarios de iOS 17 e iOS 18 experimentan un bucle de inicio de sesión infinito: aparece la pantalla de CNA, el usuario acepta los términos y hace clic en Conectar, el modal se cierra, pero 30 segundos después se vuelve a abrir solicitando el inicio de sesión de nuevo. ¿Cuál es la causa principal y cómo se soluciona?

  1. Seguimiento de sesión RADIUS: en iOS 17/18, las direcciones de Private Wi-Fi utilizan direcciones MAC rotativas si están configuradas, o el dispositivo puede renegociar el DHCP al salir del modal. 2. Configuración de RADIUS CoA: verifique que el controlador procese la desconexión del cambio de autorización (CoA) RADIUS RFC 3576 en el puerto UDP 3799 para que la ACL previa a la autenticación se elimine inmediatamente después de la autenticación. 3. Tiempo de espera de sesión y período de gracia: aumente el tiempo de espera de la caché de derivación de autenticación MAC (MAB) a 1440 minutos (24 horas) con un período de gracia de concesión de 15 minutos. 4. Recursos de OAuth de la zona de acceso limitado (walled garden): verifique que todos los endpoints de OAuth (Google, Apple, Microsoft) y las fuentes/hojas de estilo estén en la zona de acceso limitado (walled garden) para que la sesión termine de cargarse por completo antes de cerrar la WebSheet.
Comentario del examinador: Los bucles de redirección infinitos suelen deberse a retrasos en el CoA de RADIUS, donde el controlador aún no ha actualizado el estado del cliente de previo a la autenticación a posterior a la autenticación cuando iOS envía su sondeo de verificación posterior al inicio de sesión.

Preguntas de práctica

Q1. ¿Por qué el intento de redirigir el tráfico HTTPS (puerto 443) provoca errores de Captive Portal en dispositivos iOS en lugar de abrir la página de bienvenida?

Sugerencia: Considere cómo el cifrado TLS, la verificación de certificados y HSTS protegen el tráfico web.

Ver respuesta modelo

HTTPS establece un túnel TLS cifrado de extremo a extremo entre el navegador del cliente y el servidor web de destino. Cuando una pasarela inalámbrica intenta interceptar el puerto 443 y ofrecer una redirección, el certificado SSL/TLS proporcionado por la pasarela no coincide con el nombre de host solicitado (por ejemplo, google.com o apple.com). iOS aplica HTTP Strict Transport Security (HSTS), lo que hace que Safari y WebKit aborten la conexión con una advertencia de seguridad grave en lugar de seguir la redirección.

Q2. ¿Cómo debe gestionar una red de invitados empresarial iCloud Private Relay para garantizar una redirección fluida al Captive Portal en dispositivos iOS?

Sugerencia: Revise las directrices de red oficiales de Apple relativas a las respuestas DNS de mask.icloud.com.

Ver respuesta modelo

Los administradores de red deben configurar sus servidores DNS recursivos locales para que devuelvan una respuesta NXDOMAIN (o un fallo de resolución DNS) para los nombres de dominio mask.icloud.com y mask-h2.icloud.com. Cuando iOS recibe una respuesta NXDOMAIN para estos dominios canario, muestra una alerta del sistema que informa al usuario de que la red no es compatible con Private Relay y recurre de forma limpia a la gestión estándar de sondeos DNS y HTTP.

Q3. ¿Cuál es la ventaja de implementar la API de Captive Portal RFC 8908 frente a las técnicas tradicionales de secuestro de DNS y HTTP?

Sugerencia: Piense en la claridad del protocolo, la señalización de Capa 3 y la experiencia del usuario.

Ver respuesta modelo

RFC 8908 proporciona una API REST JSON estandarizada que se comunica a través de la Opción DHCP 114 o de los anuncios de router IPv6. En lugar de interceptar el tráfico web del usuario, el sistema operativo del cliente consulta la API directamente a través de HTTPS para saber si la red es cautiva, obtener la URL de inicio de sesión del portal, inspeccionar la cuota restante y recibir una notificación con la marca del establecimiento. Esto elimina las advertencias de certificados SSL, admite gestores de contraseñas y preserva la integridad de la seguridad del navegador.

Preguntas frecuentes

Why is my captive portal not popping up on iPhone?

Captive portals fail to pop up on iPhones when the Apple Captive Network Assistant (CNA) cannot complete its probe to http://captive.apple.com/hotspot-detect.html. Common causes include: 1) Pre-authentication firewalls blocking UDP port 53 DNS; 2) The network prematurely whitelisting captive.apple.com in the walled garden; 3) Gateways attempting HTTPS interception instead of HTTP 302 redirection; or 4) iCloud Private Relay interfering with DNS resolution.

How do I force the WiFi login screen to appear on iOS?

To manually trigger the captive portal on iPhone: 1) Open Safari and navigate to a plaintext HTTP URL such as http://captive.apple.com, http://neverssl.com, or http://1.1.1.1; 2) Go to Settings > Wi-Fi, tap the info (i) icon next to the network, and ensure Auto-Join and Auto-Login are toggled ON; 3) Turn Wi-Fi off and back on to trigger the CNA probe daemon.

What domains must be in the walled garden for Apple devices?

To support Apple iOS and macOS captive portal detection and assets, whitelist: captive.apple.com, www.airport.us, appleiphonecell.com, *.apple.com, *.purple.ai, *.purplewifi.net, and any third-party OAuth provider domains (e.g. accounts.google.com) or CDN assets used on the splash page.

How does RFC 8908 solve iOS captive portal issues?

RFC 8908 (Captive Portal API) and RFC 8910 (DHCP Option 114) pass the captive portal URL directly to iOS during the DHCP IP lease negotiation. This allows iOS 14+ to recognize network captivity instantly at Layer 3 without relying on fragile HTTP redirection or DNS hijacking.

How does MAC address randomisation affect captive portal authentication?

iOS Private Wi-Fi Addresses use unique MAC addresses per SSID. If the device rotates its MAC address or if session caching is tied strictly to physical MAC addresses without RADIUS accounting grace periods, the user may be forced to re-authenticate repeatedly. Configuring a 24-hour lease grace period and deploying Passpoint (Hotspot 2.0) resolves this issue.

Fuentes

  1. Apple Developer Documentation - Captive Network Architecture and CNA
  2. Apple Support - Prepare Your Network for iCloud Private Relay
  3. IETF RFC 8908 - Captive Portal API Specification
  4. IETF RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance (WBA) - Captive Portal Standards and Best Practices
  6. Purple - Captive Portal Architecture & Troubleshooting Guide
  7. Purple - MAC Address Randomisation Impact Guide

Continúe leyendo esta serie

El portal de invitados Ubiquiti UniFi no redirige: causas y soluciones

Esta guía aísla los fallos de redirección del portal de invitados de UniFi analizando 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 resolver la confusión entre red de invitados y Hotspot, integraciones con portales externos, los requisitos actuales de las cuentas de UniFi OS y pruebas de aislamiento de DNS.

Leer la guía →

La página splash de Cisco Meraki no funciona: diagrama de flujo para la resolución de problemas

Esta práctica guía de mantenimiento identifica dónde ha fallado un flujo de splash de Cisco Meraki: autorización del cliente, inicio de redirección HTTP, accesibilidad de walled-garden o inicio de sesión RADIUS. Proporciona a los equipos de TI de los establecimientos una ruta de evidencias controlada para restablecer el WiFi de invitados sin realizar cambios drásticos en una red en producción.

Leer la guía →

Guía de configuración de WiFi para invitados empresariales: segmentación por VLAN, seguridad y Captive Portals

Esta guía técnica muestra a los equipos de TI cómo configurar el WiFi de invitados como un servicio controlado de acceso a internet, mediante segmentación por 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 admiten una experiencia de visitante proporcionada sin debilitar el límite en torno a los sistemas de personal, pago y operativos.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.