Saltar al contenido principal
Español (México)

Por qué tu Captive Portal no carga en iPhone: Solucionar errores de Apple CNA

Diagnostica y soluciona fallas en la ventana emergente del Captive Portal en iPhone e iOS. Conoce cómo Apple CNA, iCloud Private Relay y la aleatorización de MAC interrumpen los inicios de sesión en WiFi, y cómo solucionarlo.

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

Video overview

Escucha esta guía

Ver transcripción del podcast
[Música de introducción: Synth-pop electrónico, alegre y moderno con toques limpios de piano, estableciendo un tono profesional y tecnológico] **Anfitrión (Consultor Sénior)**: Hola y bienvenidos al Informe Técnico de Purple. Soy su anfitrión, y hoy nos adentraremos en uno de los problemas más comunes y, francamente, más frustrantes a los que se enfrentan hoy en día los administradores de redes, los gerentes de TI y los directores de operaciones de recintos. Todos hemos estado ahí. Han pasado semanas planificando, configurando e implementando una red WiFi para invitados de última generación para su hotel, centro comercial o estadio. Tienen los puntos de acceso más recientes, un controlador robusto y una hermosa página de inicio lista para capturar datos de los invitados y fomentar la interacción. Pero entonces, los tickets de soporte técnico comienzan a llegar. Y todos dicen exactamente lo mismo: "Me conecté al WiFi de invitados en mi iPhone, pero la página de inicio de sesión no carga". Para el invitado, simplemente su WiFi no funciona. Pero para nosotros, como ingenieros y arquitectos de redes, sabemos que hay una batalla técnica compleja ocurriendo bajo el cofre de iOS. Hoy vamos a analizar 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 pueden implementar en su red este trimestre. [Breve transición musical] **Anfitrión**: Comencemos con el análisis técnico profundo. ¿Por qué un iPhone se conecta al WiFi de invitados pero no muestra la pantalla de inicio de sesión? Para entender esto, tenemos que examinar 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`. Esta sonda en segundo plano utiliza un User-Agent del sistema único llamado `CaptiveNetworkSupport`. El demonio CNA busca una respuesta muy específica. 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 el WiFi como la interfaz de enrutamiento principal, y el usuario continúa con sus actividades. Sin embargo, si la puerta de enlace 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. De inmediato inicia la aplicación nativa **Websheet**. Esta es la conocida pantalla modal deslizable 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 en la lista blanca los dominios de éxito de Apple, como `captive.apple.com`, en sus listas de control de acceso previas a la autenticación. Piensan, "Bueno, es un dominio de Apple, debería dejarlo pasar". Pero si lo incluyes en la lista blanca, la prueba de fondo llega con éxito a los servidores de Apple, recibe la respuesta "Success", e iOS asume que no hay un Captive Portal. ¡La Websheet nunca se activa! Mientras tanto, el usuario tiene bloqueado el acceso a cualquier otro sitio web. Así que, regla número uno: **Nunca incluyas captive.apple.com en tu jardín vallado.** [Breve efecto de sonido de transición] **Host**: ¿Pero qué pasa con las características modernas de privacidad de iOS? Incluso con un jardín vallado perfecto, funciones como **iCloud Private Relay** y las **Private MAC Addresses** 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 su WiFi de invitados, la prueba HTTP de fondo se encapsula dentro de un túnel cifrado. Debido a que su puerta de enlace de red no puede inspeccionar ni interceptar este paquete cifrado, no puede inyectar la redirección. La prueba 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 respetar los bloqueos a nivel de red. Si su 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 tocan eso, se omite el túnel cifrado, se intercepta la prueba HTTP y su Captive Portal se carga perfectamente. El siguiente paso son las **Private MAC Addresses** y las nuevas **Rotating MAC Addresses** 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 mientras se está conectado a la misma red. Si su controlador inalámbrico rastrea 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 recintos empresariales deben alejarse del simple rastreo 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 recintos 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 recurrentes sin mostrar nunca una hoja de Captive Portal. Es seguro, es fluido y evita por completo las limitaciones de la 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 gateway no puede suplantar la búsqueda de DNS para `captive.apple.com`. De manera similar, los perfiles de VPN "Always-On" intentarán establecer un túnel cifrado en el segundo en que se asigne una dirección IP. Si la VPN tiene éxito, omite su redirección; si se bloquea, paraliza la conexión por completo. Para estos usuarios, la solución manual definitiva 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 el gateway interceptará el tráfico del puerto 80 y forzará la carga de la redirección, omitiendo cualquier interferencia de VPN o DNS personalizada. [Efecto de sonido: Campana de transición rápida] **Presentador**: Repasemos una sesión 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 en segundo plano no obtuvo respuesta de los servidores de verificación de Apple y no se redireccionó correctamente, a menudo debido a iCloud Private Relay o a una VPN activa. *Pregunta dos: ¿Podemos simplemente desactivar por completo el mini-navegador CNA en nuestra red?* **Respuesta**: Sí, la mayoría de los controladores de LAN inalámbrica empresariales tienen una configuración llamada 'CNA Bypass' o 'Captive Portal Bypass'. Cuando se activa, el controlador suplanta la sonda de verificación 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 Safari manualmente 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 posterior a la 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 gateway los redirige a una página de destino pero continúa bloqueando los dominios de verificación de Apple, el botón superior derecho se queda atascado en 'Cancelar'. Al hacer clic en 'Cancelar', se desconectan de la red WiFi. Debe asegurarse de que los dominios de verificación de Apple sean totalmente accesibles después de la autenticación. [Breve puente musical de transición] **Presentador**: Para terminar, analicemos el impacto comercial en el mundo real. Optimizar su Captive Portal no es sólo una cuestión de elegancia técnica; se trata de resultados financieros. Recientemente trabajamos con un grupo de resorts de lujo de 5 estrellas que experimentaba una tasa de falla del 35% en las conexiones de WiFi de invitados, lo que generaba más de 450 quejas en la recepción cada semana. Al reestructurar su walled garden, bloquear los dominios de Private Relay a nivel DNS para forzar el enrutamiento local y desplegar la solución de **Guest WiFi de Purple**, vieron cómo los tickets de soporte por WiFi en recepción disminuyeron un **92%** en sólo 30 días. Sus puntajes de satisfacción de los huéspedes se dispararon y capturaron miles de perfiles de huéspedes verificados. Si desea asegurarse de que su red de WiFi de invitados interactúe a la perfección con el Captive Network Assistant de Apple mientras maximiza la captura de datos y minimiza los costos de soporte, visite **purple.ai**. Nuestra plataforma está diseñada para manejar todos estos matices específicos de iOS de manera predeterminada. 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 la incorporación de sus huéspedes sin fricciones. [Música de salida: Sintetizador electrónico pop alegre que se desvanece lentamente]

Parte de nuestra serie principal: Guía del 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 principales causas de quejas de conexión WiFi de invitados en entornos de hotelería, comercio minorista, atención médica y corporativos. Cuando un dispositivo iOS se asocia con una red inalámbrica abierta o con autenticación web, el demonio Captive Network Assistant (CNA) de Apple inicia una serie de pruebas HTTP en segundo plano. Si estas pruebas se bloquean, se desvían de forma incorrecta o se interceptan de manera inapropiada, la página de inicio 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 la mecánica subyacente de la detección de CNA de Apple, analiza las características clave de privacidad de iOS - incluyendo iCloud Private Relay, Private WiFi Addresses (aleatorización de direcciones MAC) y Encrypted DNS - y proporciona estrategias de mitigación paso a paso para ingenieros de redes y operadores de establecimientos.

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

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

Explore Purple Guest WiFi →

Análisis Técnico Detallado

Lógica de Detección y Mecanismo de Pruebas de Apple

Cuando un iPhone se conecta a un punto de acceso inalámbrico, la pila de red de iOS envía de inmediato 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 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 redirecciona 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 restablecimiento: 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 una advertencia de "Sin conexión a Internet" debajo del nombre del SSID en Configuración, pero no muestra la página de inicio de sesión.

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

Después de que un 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 de inmediato un sondeo HTTP de seguimiento a captive.apple.com.

Si el segundo sondeo devuelve HTTP 200 "Success", el botón superior derecho 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 se queda atascado en "Cancelar" y tocarlo puede desconectar el dispositivo de la red WiFi por completo.

-

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, el tráfico de Safari y el tráfico HTTP no cifrado se cifran y se enrutan a través de dos retransmisores de internet independientes:

[ iPhone ] === Encrypted QUIC/TLS ===> [ Apple Ingress Proxy ] ---> [ Egress Proxy ] ---> [ Web Target ]
  • El problema: Private Relay cifra las solicitudes DNS a través de Oblivious DNS-over-HTTPS (ODoH) y tuneliza el tráfico HTTP a través de QUIC (puerto UDP 443). Debido a que los routers de la puerta de enlace local no pueden inspeccionar o 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 tuneliza 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 ampliado 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 la 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 vea 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 provoca una mala experiencia de usuario y tickets de soporte técnico.

3. Perfiles DNS cifrados (DoH / DoT)

Los usuarios con perfiles de configuración personalizados de iOS (como NextDNS, Cloudflare 1.1.1.1 o configuraciones DNS de MDM corporativas) transmiten todas las consultas DNS a través de HTTPS cifrado (DoH) o TLS (DoT) directamente a los solucionadores 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 de DNS inicial pasa por alto por completo al controlador local, lo que evita que se active el redireccionamiento al portal.

¿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.

Guía de implementación y mitigación

Diseño de Walled Garden (ACL de preautenticación)

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

Tipo de regla Destino / Dominio Propósito
Permitir *.purple.ai, *.purpleshield.com Permite que los clientes no autenticados lleguen a la infraestructura y los recursos del portal de Purple.
Interceptar HTTP (Puerto TCP 80) a cualquier destino Intercepta el tráfico web HTTP simple para activar el redireccionamiento 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 lista de permitidos captive.apple.com, www.apple.com NO se debe incluir en la lista de permitidos. Hacerlo provoca que las pruebas tengan éxito sin lanzar el portal.

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

  1. Configurar la interceptación de DNS: Configure el servidor DHCP para asignar 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: Agregue 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, presenta el mensaje del sistema: "Esta red bloquea iCloud Private Relay. ¿Deseas utilizar esta red sin Private Relay?" Al tocar Usar sin Private Relay se restaura el redireccionamiento estándar al portal.
  3. Configurar el tiempo de espera de la sesión: Configure 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.

Mejores prácticas y estándares de la industria

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

  • Transición a WPA3 - Personal (OWE): Los portales de invitados heredados se ejecutan en SSIDs abiertos y sin cifrar. Los recintos 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 los 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 GDPR - gestionadas fácilmente a través de una plataforma de WiFi Analytics.
  • Desplegar 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 mediante un perfil preinstalado, evitando por completo el demonio CNA.

-

Solución de problemas y mitigación de riesgos

Ruta de autorremediación del usuario final

  1. Desactivar el Relay privado de iCloud para la red: Abra Configuración > WiFi, toque el icono (i) junto al nombre de la red y desactive Limitar rastreo de dirección IP.
  2. Desactivar Dirección WiFi privada: En el mismo menú de configuración de red, desactive Dirección WiFi privada si se requiere acceso basado en MAC.
  3. Forzar redirección de portal a través de Safari: Abra Safari e introduzca la dirección HTTP simple: http://neverssl.com Debido a que neverssl.com no utiliza HTTPS, el router local interceptará de forma confiable la solicitud y cargará el portal.

Ruta de diagnóstico del ingeniero de red

                  [ iPhone se conecta al SSID de invitados ]
                                  |
                                  v
                     [ ¿IP de DHCP asignada? ]
                        /                   \
                     (No)                   (Sí)
                      /                       \
     [ Verificar pool de DHCP ]      [ ¿Resuelve captive.apple.com? ]
                                        /                             \
                                     (No)                             (Sí)
                                      /                                 \
                      [ Verificar ACL de DNS ]           [ ¿Apple está 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 de WiFi para invitados en iOS tiene un impacto directo y medible en las operaciones del establecimiento y en las métricas del negocio.

Caso de estudio de hospitalidad: Grupo de resorts de cinco estrellas

  • Desafío: Un grupo de hoteles de lujo con 12 propiedades sufría una tasa de fallos de conexión 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 de Guest WiFi de Purple con un manejo optimizado de CNA.
  • Resultados: Las quejas relacionadas con el WiFi en la recepción disminuyeron un 92% en 30 días. Las puntuaciones de satisfacción del cliente (CSAT) aumentaron 18 puntos y el establecimiento capturó 40,000 direcciones de correo electrónico verificadas durante el primer trimestre.

Caso de Éxito en Retail: Operador Nacional de Centros Comerciales

  • Desafío: Un operador de retail con 45 centros comerciales tenía dificultades para impulsar el engagement de los visitantes debido a que Private Relay de iCloud 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 implementó 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 retail media localizadas, generando $120,000 USD adicionales en ingresos publicitarios por trimestre.

Recursos Relacionados

Para los equipos de redes que implementan redes inalámbricas empresariales para invitados, estos recursos proporcionan un contexto técnico más profundo:

La plataforma de Guest WiFi de Purple brinda servicio a establecimientos de hotelería, retail, salud y transporte en todo el mundo, ofreciendo experiencias de inicio de sesión de invitados optimizadas para CNA a 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 WiFi de invitados.

Canary probe URL

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

Si la respuesta de sondeo se modifica o redirige, el sistema operativo activa su controlador de Captive Portal.

RFC 8908 Captive Portal API

Un protocolo estándar de la 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 restante de la sesión a través de JSON.

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

DHCP Option 114 (Captive-Portal)

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

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

iCloud Private Relay

Un servicio de privacidad de Apple que enruta 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 resueltos

Un hotel de lujo que implementa Cisco Catalyst 9800 WLCs detecta que los usuarios invitados con iPhone nunca reciben la pantalla de inicio del Captive Portal al conectarse al SSID abierto de la WiFi de invitados. Las laptops con Android y Windows cargan el portal de inmediato. ¿Cómo debería 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: Verifica que la ACL de redirección de Cisco 9800 deniegue (omita) UDP 53 DNS y permita TCP 80 HTTP para activar la redirección. 2. Verificar la lista blanca de sondeo de Apple: Asegúrate de que captive.apple.com NO esté en la lista blanca en el walled garden de preautenticación antes de la redirección; incluirlo en la lista blanca hace que iOS piense que el internet está abierto y suprima el portal. 3. Verificar HTTP 302 vs 307: Configura el mapa de parámetros webauth del WLC para devolver una redirección HTTP 302 Found con el FQDN del portal. 4. Desactivar la interceptación HTTPS: Asegúrate de que el tráfico HTTPS del puerto 443 se descarte o rechace en lugar de ser secuestrado con un certificado no confiable. 5. Implementar la Opción DHCP 114: Agrega option 114 ascii https://app.purplewifi.net/api/v1/capport al pool 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 del walled garden, iOS asume falsamente que hay internet abierto y nunca activará el WebSheet.

Un 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 el modal se vuelve a abrir solicitando el inicio de sesión nuevamente. ¿Cuál es la causa raíz y la solución?

  1. Seguimiento de sesión RADIUS: En iOS 17/18, las direcciones WiFi privadas utilizan direcciones MAC rotativas si están configuradas, o el dispositivo puede renegociar DHCP al salir del modal. 2. Configuración de RADIUS CoA: Verifica que el controlador procese la desconexión de cambio de autorización (CoA) de RADIUS según 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: Incrementa el tiempo de espera de la caché de desvío de autenticación MAC (MAB) a 1440 minutos (24 horas) con una ventana de gracia de arrendamiento de 15 minutos. 4. Recursos de OAuth en el Walled Garden: Verifica que todos los endpoints de OAuth (Google, Apple, Microsoft) y las fuentes/hojas de estilo estén en el walled garden para que la sesión termine de cargarse por completo antes de cerrar el 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 preautenticación a postautenticación cuando iOS envía su sondeo de verificación posterior al inicio de sesión.

Preguntas de práctica

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

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 puerta de enlace inalámbrica intenta interceptar el puerto 443 y ofrecer una redirección, el certificado SSL/TLS proporcionado por la puerta de enlace 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 debería una red de invitados empresarial manejar iCloud Private Relay para garantizar una redirección fluida de Captive Portal en dispositivos iOS?

Sugerencia: Revise la guía oficial de red de Apple con respecto a las respuestas DNS de mask.icloud.com.

Ver respuesta modelo

Los administradores de red deben configurar sus servidores DNS recursivos locales para devolver 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 canarios, muestra una alerta del sistema informando al usuario que la red no es compatible con Private Relay y recurre de manera limpia al manejo estándar de DNS y sondas HTTP.

Q3. ¿Cuál es la ventaja de implementar la API de Captive Portal RFC 8908 sobre 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 DHCP Option 114 o anuncios de enrutador IPv6. En lugar de interceptar el tráfico web del usuario, el sistema operativo del cliente consulta la API directamente sobre 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 administradores 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 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.

Leer la guía →

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.

Leer la guía →

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.

Leer la guía →

¿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.