WiFi Landing Page vs. Splash Page: ¿Cuál es la diferencia?

Esta guía de referencia técnica aclara las diferencias arquitectónicas y funcionales entre las páginas de aterrizaje WiFi y las splash pages — dos términos frecuentemente confundidos tanto por los equipos de TI como por los departamentos de marketing. Proporciona a arquitectos de red, gerentes de TI y directores de operaciones de recintos estrategias de implementación accionables para optimizar el rendimiento del Captive Portal, asegurar el cumplimiento de GDPR y PCI DSS, y maximizar el ROI en recintos empresariales, incluyendo entornos de hostelería, comercio minorista y sector público.

📖 8 min de lectura📝 1,923 palabras🔧 2 ejemplos❓ 3 preguntas📚 9 términos clave

🎧 Escucha esta guía

Ver transcripción

Welcome back to the Purple Technical Briefing. Today we're tackling a question that comes up in almost every initial scoping call with CTOs and network architects: What exactly is the difference between a WiFi landing page and a splash page?

In the consumer world, people use these terms interchangeably. But when you're architecting an enterprise guest network across fifty retail locations, or a high-density stadium deployment, confusing the two can lead to compliance headaches, broken user journeys, and missed ROI.

So, over the next ten minutes, we're going to define the technical distinction, look at the architecture, discuss common implementation pitfalls, and finish with a rapid-fire Q and A. Let's get into it.

[SECTION: TECHNICAL DEFINITIONS]

First, let's define the terms. When we talk about a Captive Portal, we're referring to the entire walled-garden mechanism that intercepts HTTP and HTTPS traffic and forces a client device to authenticate before granting external network access.

Within that portal flow, the Splash Page is the gatekeeper. It is the very first screen a user sees when they connect to the SSID. Its primary technical function is authentication and authorisation. It's where the user accepts the Terms and Conditions, enters their credentials, or authenticates via an identity provider — perhaps using OAuth or a loyalty integration. From a compliance standpoint, this is where you handle GDPR consent and PCI DSS disclaimers if you're processing payments.

Now, contrast that with the Landing Page. The landing page is the destination after successful authentication. Once the RADIUS server sends the Access-Accept message and the client device is placed onto the active VLAN with internet routing, the walled garden drops. The controller then redirects the user's browser to the Landing Page.

Why does this distinction matter? Because the Splash Page exists in a highly constrained environment. The device doesn't have full internet access yet. It can only reach the specific IP addresses or hostnames you've whitelisted in your Walled Garden configuration. If you try to load heavy external scripts, dynamic video players, or complex third-party trackers on a splash page without proper whitelisting, the page will break, and the user gets stuck in a connection loop.

The Landing Page, however, sits on the open internet. The user is authenticated. Here, you can load full marketing experiences, dynamic app download links, interactive venue maps, and targeted promotions driven by the first-party data you just captured on the splash page.

[SECTION: IMPLEMENTATION AND PITFALLS]

Now let's talk about implementation and where I see deployments go wrong.

The most common mistake is overloading the Splash Page. I've seen marketing teams hand over a five-megabyte page with four different external tracking pixels and a background video, asking IT to make it the login screen.

When you do that, you have to add dozens of CDNs and third-party domains to your Walled Garden whitelist. Not only is this a nightmare to maintain as those IP ranges change, but it's a security risk. You are poking holes in your pre-authentication firewall. Furthermore, modern mobile operating systems — like iOS and Android — use a specialised mini-browser to render captive portals. These Captive Network Assistants, or CNAs, have limited functionality. They often block cookies, restrict local storage, and will automatically close if they detect external navigation before the internet connection is fully established.

The best practice? Keep the Splash Page lean, fast, and focused purely on data capture and legal consent. Use a cloud-based captive portal solution that optimises the HTML payload for these CNA browsers.

Once the user hits Connect, then redirect them to the rich, dynamic Landing Page. This is where you leverage your WiFi Analytics platform. Because you've already captured their profile, the Landing Page can be personalised. If they are a returning guest at your hotel, the landing page can welcome them by name and offer a one-click booking for the spa. If they are in a retail environment, it can show a heatmap-driven promotion based on their current zone.

[SECTION: CASE STUDIES]

Let me give you two concrete case studies that illustrate this perfectly.

First, a five-hundred-room hotel resort. They were experiencing high drop-off rates on their guest WiFi login. The marketing team had added a four-megabyte promotional video and a complex interactive map to the initial connection screen. The fix was straightforward: replace the connection screen with a lightweight Splash Page under one megabyte, focused solely on room number and last name authentication plus Terms and Conditions acceptance. The video and map were moved to the post-authentication Landing Page. Connection rates improved by over forty percent within the first week.

Second, a retail chain with fifty locations. They wanted to offer seamless WiFi access to returning loyalty members without forcing them to log in every time. The solution was MAC Authentication Bypass integrated with the loyalty database. When a returning device associates with the SSID, the controller queries the RADIUS server, identifies the MAC address, and immediately returns an Access-Accept without presenting the Splash Page. The user is redirected to a personalised Landing Page with their loyalty status and a targeted offer. The result: a thirty percent increase in loyalty app engagement across the estate.

[SECTION: RAPID-FIRE Q&A]

Now, let's move to our Rapid-Fire Q and A. These are the top three questions I get from network engineers.

Question one: Can I bypass the Splash Page entirely for returning users?

Yes. This is called MAC Authentication Bypass, or seamless login. The controller recognises the device's MAC address from a previous session and automatically authorises them, taking them straight to the Landing Page or their original destination. Just ensure your privacy policy covers persistent device tracking.

Question two: Why is my Splash Page showing a certificate error?

This usually happens when you try to intercept HTTPS traffic without a valid SSL certificate on the controller, or if you're using a self-signed certificate. Always use a publicly trusted certificate for your captive portal hostname, and ensure your controller supports modern HTTPS redirection standards like RFC 8908.

Question three: Should the Landing Page be hosted locally on the controller or in the cloud?

Always in the cloud. Hosting on the controller limits your ability to update content dynamically, run A/B tests, or integrate with external CRMs. A cloud-based architecture separates the network control plane from the user experience layer, which is exactly what enterprise deployments require.

[SECTION: SUMMARY AND NEXT STEPS]

To summarise: The Splash Page is the secure, constrained gatekeeper for authentication and consent. Keep it lightweight — under one megabyte, no external dependencies, optimised for the Captive Network Assistant. The Landing Page is the post-authentication destination for engagement, marketing, and ROI generation. It operates on the open internet with full browser capabilities.

Understand the constraints of the Walled Garden and the Captive Network Assistant, and you'll avoid ninety percent of the support tickets associated with guest WiFi deployments.

The three key rules to take away: Splash for Security, Landing for Loyalty. The Walled Garden is a sandbox, not a playground. And always — Authentication before Animation.

Thanks for joining this technical briefing. If you want to dive deeper into configuring cloud-based captive portals, check out the full reference guide on the Purple website. Until next time, keep your networks secure and your users connected.

Conclusiones clave

✓The Splash Page is the pre-authentication gatekeeper operating within the restricted Walled Garden — its sole purpose is identity verification and legal consent.
✓The WiFi Landing Page is the post-authentication destination operating on the open internet — its purpose is marketing engagement, personalisation, and ROI generation.
✓The Captive Network Assistant (CNA) renders the Splash Page in a sandboxed mini-browser that blocks cookies, restricts JavaScript, and limits external resource loading.
✓Overloading the Splash Page with marketing assets is the leading cause of guest WiFi connection failures and elevated support ticket volumes.
✓MAC Authentication Bypass (MAB) eliminates the Splash Page for returning devices, redirecting them directly to a personalised Landing Page — improving experience for repeat visitors.
✓A cloud-based captive portal architecture separates the network control plane from the user experience layer, enabling centralised management, dynamic content updates, and CRM integration.
✓Measurable ROI from guest WiFi is generated primarily through the Landing Page — via direct revenue attribution, loyalty engagement, and first-party data capture feeding into WiFi Analytics.

Resumen Ejecutivo

Para los equipos de TI empresariales que gestionan recintos de alta densidad — desde propiedades de Hostelería hasta propiedades de Comercio Minorista — los términos "splash page" y "landing page" se confunden con frecuencia. Tratarlos como intercambiables en la arquitectura de red conduce a experiencias de usuario deficientes, vulnerabilidades de seguridad y oportunidades perdidas de captura de datos.

A un nivel fundamental, la Splash Page es el guardián de preautenticación. Existe dentro del entorno restringido de un Walled Garden, responsable de la verificación de identidad, la autenticación MAC y el consentimiento legal bajo GDPR y PCI DSS. La WiFi Landing Page es el destino post-autenticación. Opera en internet abierto, aprovechando los datos capturados durante el inicio de sesión para ofrecer experiencias personalizadas, impulsar descargas de aplicaciones y generar un ROI medible a través de integraciones de Guest WiFi .

Esta guía detalla las especificaciones técnicas, metodologías de implementación y modos de fallo comunes asociados con el diseño de Captive Portal — permitiendo a los arquitectos de red construir redes de acceso para invitados robustas, conformes y generadoras de ingresos en cualquier tipo de recinto.

Análisis Técnico Detallado

La Arquitectura del Captive Portal

Un Captive Portal intercepta el tráfico HTTP/HTTPS de clientes no autenticados y los redirige a una interfaz web designada. Este mecanismo se basa en una combinación de secuestro de DNS, redirección HTTP 302 y autenticación RADIUS — con implementaciones modernas que adoptan cada vez más el RFC 8908 (Captive Portal Identification in DHCP and Router Advertisements) para permitir el descubrimiento de Captive Portal a nivel de sistema operativo nativo sin una frágil intercepción HTTP.

Dentro de esta arquitectura, la Splash Page y la Landing Page cumplen roles fundamentalmente diferentes en distintos puntos del ciclo de vida de la autenticación.

1. La Splash Page (Estado de Preautenticación)

Cuando un dispositivo se asocia con un SSID, el controlador inalámbrico lo coloca en una VLAN no autenticada. Todo el tráfico saliente es interceptado y redirigido al nombre de host del Captive Portal. El Captive Network Assistant (CNA) del sistema operativo — un pseudo-navegador especializado y en entorno aislado integrado en iOS, Android y Windows — detecta el Captive Portal y renderiza la Splash Page.

Restricciones Técnicas del Entorno CNA:

El CNA no es un navegador completo. Opera con restricciones significativas que impactan directamente lo que se puede implementar en una Splash Page:

Las cookies y el almacenamiento local a menudo están bloqueados o severamente limitados
Los frameworks complejos de JavaScript pueden fallar al ejecutarse
Los recursos externos (fuentes, scripts, imágenes) solo pueden cargarse si sus dominios están en la lista blanca del Walled Garden
El CNA se cerrará automáticamente si detecta que el dispositivo ha obtenido acceso a internet antes de que el usuario haya completado la autenticación
La persistencia de la sesión tras el cierre del CNA no es fiable

Funciones Principales de la Splash Page:

Dadas estas restricciones, la Splash Page debe diseñarse exclusivamente para: autenticación (inicio de sesión social a través de OAuth, SMS OTP, credenciales basadas en formularios o integración de programas de lealtad); aceptación de Términos y Condiciones; captura de consentimiento GDPR; y registro de dirección MAC para futuros inicios de sesión sin interrupciones.

Recomendación de Carga Útil: Mantenga la Splash Page por debajo de 1MB. Use CSS en línea, evite bibliotecas de fuentes externas y minimice JavaScript. Cada dependencia externa requiere una entrada correspondiente en la lista blanca del Walled Garden — cada una de las cuales representa tanto una carga de mantenimiento como una posible exposición de seguridad.

2. La Landing Page (Estado Post-Autenticación)

Tras una autenticación exitosa, el servidor RADIUS devuelve un mensaje de Access-Accept. El controlador inalámbrico actualiza la sesión del cliente, migrando el dispositivo a una VLAN autenticada con enrutamiento completo a internet. El Walled Garden se desactiva. El controlador — o la plataforma de Captive Portal basada en la nube — emite una redirección HTTP 302 a la WiFi Landing Page.

En este punto, el dispositivo opera con un navegador completo y acceso a internet sin restricciones. La Landing Page puede aprovechar el conjunto completo de capacidades del desarrollo web moderno:

Contenido dinámico y personalizado impulsado por el perfil de usuario capturado en la Splash Page
Instrumentación completa de análisis (Google Analytics, píxeles de seguimiento personalizados, webhooks de CRM)
Contenido multimedia enriquecido, incluyendo video, mapas interactivos y paneles de lealtad
Solicitudes de descarga de aplicaciones con enrutamiento de enlaces profundos
Promociones dirigidas basadas en datos de WiFi Analytics , incluyendo frecuencia de visita, tiempo de permanencia y zona del recinto

Funciones Principales de la Landing Page: Compromiso de marketing, visualización de programas de lealtad, promociones dirigidas, navegación del recinto y llamadas a la acción orientadas a la conversión.

Flujo de Autenticación: De Principio a Fin

La siguiente secuencia ilustra el flujo completo desde la asociación del SSID hasta la entrega de la Landing Page:

El dispositivo cliente se asocia con el SSID de invitado
El controlador asigna el dispositivo a una VLAN no autenticada
El cliente intenta una solicitud HTTP; el controlador intercepta y emite una redirección 302 a la Splash Page
El CNA carga la Splash Page (activos servidos solo desde dominios en la lista blanca del Walled Garden)
El usuario completa la autenticación y acepta los Términos y Condiciones
La plataforma del Captive Portal envía una Access-Request al servidor RADIUS
RADIUS devuelve Access-Accept; el controlador recibe un mensaje de Change of Authorization (CoA)
El controlador migra el cliente a la VLAN autenticada
La plataforma del Captive Portal emite una redirección 302 a la WiFi Landing Page
El navegador del cliente carga la Landing Page completa a través de internet abierto

Esta clara separación de responsabilidades — autenticación en la Splash Page, la interacción en la Landing Page — es la base arquitectónica de cada implementación de WiFi para invitados bien diseñada.

Guía de Implementación

Implementar una solución de WiFi para invitados escalable y de nivel empresarial requiere separar el plano de control de la red de la capa de experiencia del usuario. Los siguientes pasos proporcionan un marco de implementación neutral en cuanto al proveedor, aplicable a la infraestructura de Cisco Meraki, Aruba, Ruckus y Ubiquiti.

Paso 1: Configuración del Walled Garden

Configure su Controlador de Red de Área Local Inalámbrica (WLC) para incluir en la lista blanca solo los dominios y rangos de IP estrictamente necesarios para que la Splash Page funcione. Esto suele incluir:

El nombre de host de la plataforma de Captive Portal (por ejemplo, portal.purple.ai)
Dominios de proveedores de identidad para inicio de sesión social (por ejemplo, accounts.google.com, graph.facebook.com)
Dominios de pasarelas SMS si se utiliza autenticación OTP
Cualquier activo CDN utilizado por la propia Splash Page

Evite la inclusión excesiva en la lista blanca. Cada entrada adicional aumenta la superficie de ataque de su red de preautenticación y complica el mantenimiento continuo a medida que cambian los rangos de IP.

Paso 2: Gestión de Certificados SSL

Configure el WLC con un certificado SSL válido y de confianza pública para el nombre de host de redirección del Captive Portal. Los certificados autofirmados activarán advertencias de seguridad del navegador en el CNA, lo que provocará que los usuarios abandonen el proceso de conexión. La caducidad de los certificados es una causa principal de interrupciones del WiFi para invitados; implemente la renovación automatizada a través de Let's Encrypt o su plataforma de gestión de certificados.

Paso 3: Optimización del CNA

Diseñe la Splash Page específicamente para el entorno CNA. Utilice CSS en línea, evite los frameworks de JavaScript externos y realice pruebas en múltiples versiones de iOS y Android. El comportamiento del CNA de iOS, en particular, cambia entre las principales versiones del sistema operativo; mantenga una matriz de pruebas de regresión que cubra al menos las dos versiones principales más recientes de ambas plataformas.

Paso 4: Lógica de Redirección Post-Autenticación

Configure la redirección post-autenticación para admitir URLs dinámicas de Landing Page. El servidor RADIUS puede devolver atributos específicos del proveedor (VSAs) o la plataforma de Captive Portal puede usar el perfil de usuario autenticado para construir una URL personalizada. Esto permite la segmentación: un visitante por primera vez recibe una oferta de bienvenida, mientras que un miembro de lealtad con estatus Gold recibe un panel personalizado.

Paso 5: Integración de Analíticas

Instrumente la Landing Page con su pila de analíticas. Dado que el usuario ahora está en internet abierto con un navegador completo, las herramientas de analíticas estándar funcionan normalmente. Integre con su CRM para crear un perfil de cliente unificado que combine datos de sesión de WiFi con historial de compras, estado de lealtad y métricas de interacción de marketing.

Para una comparación detallada de las arquitecturas de Captive Portal basadas en la nube versus las locales, consulte Captive Portal Basado en la Nube vs. Local: ¿Cuál es el Adecuado para su Negocio? .

Mejores Prácticas

Desacoplar Autenticación y Marketing. La decisión arquitectónica más impactante es utilizar la Splash Page estrictamente para el acceso seguro y el consentimiento, y trasladar todos los activos de marketing a la Landing Page. Esto mejora las tasas de conexión, reduce los tickets de soporte y simplifica las auditorías de cumplimiento.

Aprovechar el MAC Authentication Bypass para Usuarios Recurrentes. Para dispositivos recurrentes, el MAC Authentication Bypass (MAB) elimina por completo la Splash Page, redirigiendo a los usuarios directamente a una Landing Page personalizada. Esto mejora drásticamente la experiencia del usuario para visitantes recurrentes en entornos de Hostelería y Comercio Minorista . Asegúrese de que su política de privacidad cubra explícitamente el seguimiento persistente de dispositivos.

Adoptar Arquitecturas Centradas en la Nube. Así como la industria de redes ha avanzado hacia la WAN definida por software para la gestión centralizada —como se detalla en Los Beneficios Clave de SD WAN para Empresas Modernas — las plataformas de Captive Portal deben estar alojadas en la nube. Esto permite la gestión centralizada en propiedades de múltiples ubicaciones, actualizaciones rápidas de contenido sin cambios de firmware del controlador e integración perfecta con CRMs externos y plataformas de automatización de marketing.

Implementar RFC 8908 para Compatibilidad con Sistemas Operativos Modernos. La detección nativa de Captive Portal a través de RFC 8908 reduce la dependencia de la intercepción HTTP, mejorando la fiabilidad en las versiones modernas de iOS y Android que cada vez más imponen la navegación solo HTTPS.

Mantener un Programa de Auditoría del Walled Garden. Revise las entradas del Walled Garden trimestralmente. Los rangos de IP para los principales proveedores de identidad cambian sin previo aviso. Las entradas obsoletas que ya no se resuelven crean fallos de autenticación; las entradas faltantes bloquean los flujos de autenticación legítimos.

Resolución de Problemas y Mitigación de Riesgos

El Bucle de Conexión. Si un usuario se autentica pero es redirigido repetidamente a la Splash Page, verifique que el mensaje RADIUS Access-Accept esté llegando al controlador y que el cliente esté recibiendo con éxito una concesión DHCP en la VLAN autenticada. También verifique que el puerto CoA (Change of Authorization) (UDP 3799) no esté bloqueado por un firewall intermedio.

Cierre Prematuro del CNA. Si el CNA se cierra antes de que el usuario pueda autenticarse, es probable que el dispositivo haya detectado acceso a internet prematuramente. Esto puede ocurrir si el Walled Garden es demasiado permisivo, permitiendo inadvertidamente el enrutamiento completo a internet antes de que se complete la autenticación. Revise las entradas del Walled Garden en busca de rangos CIDR excesivamente amplios.

Errores de Intercepción HTTPS. Los navegadores modernos aplican HTTP Strict Transport Security (HSTS). Si un usuario intenta navegar a un dominio precargado con HSTS antes de autenticarse, el navegador bloqueará la redirección del Captive Portal. Implemente RFC 8908 para habilitar el descubrimiento nativo del Captive Portal, o instruya a los usuarios a navegar a un dominio no HSTS para activar el CNA.

Fallos de Scripts de Terceros en la Splash Page. Si los equipos de marketing han añadido píxeles de seguimiento o scripts de análisis a la Splash Page, estos fallarán silenciosamente en el entorno CNA si sus dominios no están en la lista blanca. La resolución correcta es eliminar completamente estos scripts de la Splash Page y volver a desplegarlos en la Landing Page, donde funcionarán correctamente.

Brechas en el cumplimiento de GDPR. Asegúrese de que el mecanismo de consentimiento en la Splash Page cumple con los requisitos del Artículo 7 de GDPR — el consentimiento debe ser otorgado libremente, ser específico, informado e inequívoco. Las casillas de consentimiento premarcadas no cumplen con la normativa. Mantenga un registro de auditoría de consentimiento por un mínimo de tres años.

ROI e Impacto Comercial

Una arquitectura de Splash/Landing Page correctamente implementada transforma el WiFi para invitados de un centro de costos en un activo medible generador de ingresos. El caso financiero opera en tres dimensiones.

Captura de Datos e Inteligencia de Primera Parte. Al optimizar la Splash Page, los establecimientos aumentan las tasas de conexión y el volumen de datos de primera parte capturados. En entornos de Salud y Transporte , estos datos apoyan el análisis operativo — patrones de afluencia, tiempo de permanencia por zona y pronóstico de demanda máxima — lo que permite tomar decisiones de asignación de recursos con ahorros de costos medibles.

Atribución Directa de Ingresos. La Landing Page es la superficie de conversión principal. Una implementación en un estadio puede usar la Landing Page para promover pedidos de alimentos y bebidas en el asiento, correlacionando directamente el acceso a la red con los ingresos transaccionales. Un hotel puede ofrecer reservas de spa o mejoras de habitación. Un minorista puede ofrecer promociones específicas de zona impulsadas por datos de ubicación en tiempo real de WiFi Analytics .

Lealtad y Retención. Las experiencias personalizadas de la Landing Page — impulsadas por el perfil de usuario capturado en la Splash Page — aumentan la participación en el programa de lealtad. Los usuarios recurrentes que reciben una experiencia de bienvenida personalizada demuestran una duración de sesión y una frecuencia de visitas repetidas significativamente mayores en comparación con los usuarios a los que se les presenta una landing page genérica.

Los KPI medibles para una implementación de WiFi para invitados deben incluir: tasa de conexión WiFi (objetivo >70% de los visitantes del establecimiento), tasa de captura de datos (objetivo >85% de los usuarios conectados), tasa de clics en la CTA principal de la Landing Page y los ingresos directos atribuidos a las promociones impulsadas por WiFi.

Escuche el podcast completo de la sesión informativa técnica a continuación:

Términos clave y definiciones

Captive Portal

A web-based access control mechanism that intercepts network traffic from unauthenticated clients and redirects them to an authentication interface before granting broader network access.

The overarching system IT teams deploy to manage guest access, enforce acceptable use policies, capture user consent, and collect first-party data.

Splash Page

The initial authentication interface presented within the captive portal flow, operating within the restricted Walled Garden environment before the user has been granted internet access.

Where network architects must focus on lightweight design, identity verification, and legal consent. Incorrectly overloading this page with marketing assets is the leading cause of guest WiFi connection failures.

WiFi Landing Page

The post-authentication destination page loaded in the user's full browser after the device has been granted internet access by the RADIUS server.

Where marketing and operations teams deploy rich media, personalised content, loyalty integrations, and engagement campaigns. Operates without the constraints of the Walled Garden.

Walled Garden

A restricted network environment that allows unauthenticated users to access only a specific, explicitly whitelisted set of IP addresses or hostnames, blocking all other internet traffic.

The technical boundary within which the Splash Page must operate. Every external resource used by the Splash Page must have its domain or IP range added to the Walled Garden whitelist.

Captive Network Assistant (CNA)

A specialised, sandboxed pseudo-browser built into mobile operating systems (iOS, Android, Windows) that automatically detects and renders captive portal login pages.

The primary reason Splash Pages must be lightweight and avoid complex JavaScript, external cookies, or large media assets. CNA behaviour varies between OS versions and requires ongoing regression testing.

MAC Authentication Bypass (MAB)

A network access control technique that authenticates devices based on their hardware MAC address without requiring user interaction, enabling seamless login for returning devices.

Used to provide frictionless login experiences for returning guests or registered IoT devices. Requires integration between the RADIUS server and the venue's loyalty or device registry database.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol providing centralised Authentication, Authorisation, and Accounting (AAA) management for network access, defined in RFC 2865.

The backend server infrastructure that validates credentials submitted on the Splash Page, instructs the controller to grant access, and returns user attributes used to personalise the Landing Page.

RFC 8908

The IETF standard defining the Captive Portal API, enabling devices to discover and interact with captive portals natively through DHCP options and Router Advertisements rather than relying on HTTP interception.

A modern standard that improves captive portal reliability across iOS 14+ and Android 11+, reducing CNA-related connection failures caused by HTTPS interception issues.

Change of Authorization (CoA)

A RADIUS extension (RFC 5176) that allows the RADIUS server to dynamically modify an active network session — for example, migrating a client from an unauthenticated to an authenticated VLAN after successful login.

The mechanism by which the captive portal platform instructs the wireless controller to grant internet access after the user completes authentication on the Splash Page.

Casos de éxito

A 500-room hotel resort is experiencing high drop-off rates on their guest WiFi login. The marketing team recently added a 4MB promotional video and a complex interactive venue map to the initial connection screen. Connection rates have dropped from 68% to 31% since the update. How should the network architect resolve this?

The architect must decouple the authentication and marketing functions. Step 1: Replace the current connection screen with a lightweight Splash Page under 1MB, containing only the authentication form (room number and last name), a GDPR-compliant consent checkbox, and Terms and Conditions acceptance. Step 2: Remove all external script dependencies from the Splash Page and serve all assets from the captive portal platform's own CDN, which is already whitelisted in the Walled Garden. Step 3: Configure the wireless controller's post-authentication redirection to send the user to a newly created Landing Page hosted on the open internet. Step 4: Move the 4MB promotional video and interactive venue map to this Landing Page. Step 5: Instrument the Landing Page with the hotel's CRM integration to personalise the welcome message based on the authenticated user profile. Step 6: Implement MAC Authentication Bypass for returning guests to eliminate the Splash Page entirely on subsequent visits.

Notas de implementación: This approach resolves the drop-off issue by acknowledging the fundamental constraints of the Captive Network Assistant (CNA). The heavy assets were causing the CNA to time out or fail to render within the restricted Walled Garden environment. Moving them to the post-authentication Landing Page ensures they load correctly using the device's full browser capabilities over an established internet connection. The MAB implementation for returning guests further improves the experience for the hotel's most valuable repeat customers, while the CRM integration on the Landing Page creates a measurable revenue attribution pathway.

A retail chain wants to offer seamless WiFi access to returning loyalty programme members across 50 locations, bypassing the login screen while still displaying a personalised welcome offer and current loyalty points balance. What is the recommended technical architecture?

Implement MAC Authentication Bypass (MAB) integrated with the loyalty database via RADIUS. Architecture: (1) When a returning device associates with the SSID, the controller sends a RADIUS Access-Request containing the device MAC address. (2) The RADIUS server queries the loyalty database to match the MAC address to a loyalty profile. (3) If a match is found, the RADIUS server returns an Access-Accept with a vendor-specific attribute (VSA) containing a signed user token. (4) The controller grants immediate internet access and issues a redirect to the Landing Page URL, appending the signed token as a query parameter. (5) The cloud-hosted Landing Page decodes the token, queries the loyalty API for the user's current points balance and personalised offer, and renders a customised welcome experience. For new users or unrecognised devices, the standard Splash Page flow is presented, with an option to link the device to their loyalty account for future seamless access.

Notas de implementación: This solution correctly utilises MAB for network access control while leveraging the Landing Page for the marketing requirement. The signed token approach prevents URL manipulation and ensures the personalised content is served only to the authenticated user. The fallback to the standard Splash Page for unrecognised devices ensures that new customer acquisition is not compromised. This architecture demonstrates a mature understanding of decoupled captive portal design and is directly applicable to enterprise retail deployments across distributed venue estates.

Análisis de escenarios

Q1. A public sector organisation requires all guest WiFi users to accept a lengthy Acceptable Use Policy (AUP) before accessing the internet. The communications team also wants to display a dynamic feed of upcoming community events and a live social media wall. How should you architect this requirement across the captive portal flow?

💡 Sugerencia:Consider the constraints of the Captive Network Assistant (CNA) and the Walled Garden when deciding where to place each content element.

Mostrar enfoque recomendado

Place the Acceptable Use Policy (AUP) on the Splash Page to ensure legal compliance before authentication. The AUP should be presented as inline text or a scrollable div — not loaded from an external URL — to avoid Walled Garden dependencies. Once the user accepts the AUP and is authenticated, redirect them to the Landing Page to display the dynamic community events feed and social media wall. The social media wall in particular requires external API calls that cannot function within the Walled Garden, making the Landing Page the only viable location.

Q2. During a new deployment at a conference centre, users report that the login screen appears correctly but when they click 'Sign in with LinkedIn', the page times out and returns an error. The controller configuration and RADIUS server are both functioning correctly for email/password authentication. What is the most likely cause and resolution?

💡 Sugerencia:Think about what network access is required for a third-party OAuth identity provider to complete its authorisation flow during the pre-authentication phase.

Mostrar enfoque recomendado

The Walled Garden configuration is incomplete. LinkedIn's OAuth flow requires the client device to communicate with LinkedIn's authorisation servers (e.g., www.linkedin.com, api.linkedin.com) during the pre-authentication phase. These domains are not whitelisted, so the OAuth redirect fails. The resolution is to identify all IP ranges and hostnames used by LinkedIn's OAuth API and add them to the Walled Garden whitelist on the wireless controller. Note that LinkedIn (and other major identity providers) may use multiple CDN-hosted domains — review the OAuth documentation or use a packet capture to identify all required endpoints.

Q3. A retail client wants to track user behaviour on the initial WiFi login screen using Google Analytics 4 and a custom retargeting pixel from their advertising platform. The marketing team has provided a tag manager snippet to be added to the Splash Page. Why is this technically problematic, and what is the recommended alternative that preserves the marketing team's measurement requirements?

💡 Sugerencia:Evaluate the capabilities of the CNA mini-browser and the implications of adding external script domains to the Walled Garden.

Mostrar enfoque recomendado

This is problematic for two reasons. First, the CNA often blocks cookies and restricts JavaScript execution, rendering client-side tracking scripts ineffective or unreliable. Second, Google Tag Manager and advertising pixels load scripts from multiple external domains — adding all of these to the Walled Garden creates significant security exposure and ongoing maintenance overhead. The recommended alternative is a two-part approach: (1) Capture the authentication event server-side via the captive portal platform's API or RADIUS accounting logs, and push this event to Google Analytics 4 using the Measurement Protocol (server-side), which does not require client-side JavaScript. (2) Deploy the full Google Tag Manager container and retargeting pixel on the post-authentication Landing Page, where the full browser environment ensures reliable script execution and cookie-based tracking functions normally.