Arquitectura de Captive Portal: Un análisis técnico en profundidad

This technical reference guide provides a comprehensive architectural breakdown of captive portal systems for enterprise guest WiFi deployments. It examines how network-level redirection, RADIUS authentication, access node policy enforcement, and walled garden configuration interact to create a secure and scalable access control framework. Designed for IT managers, network architects, and venue operations directors, this guide delivers actionable implementation guidance, real-world case studies, and compliance-aligned best practices that directly support deployment decisions in hospitality, retail, events, and public-sector environments.

📖 6 min read📝 1,321 words🔧 2 examples❓ 3 questions📚 9 key terms

🎧 Listen to this Guide

View Transcript

Hello, and welcome to the Purple Technical Briefing. I'm a Senior Technical Content Strategist at Purple. Today, we're taking a deep dive into a foundational piece of guest WiFi: the captive portal architecture. For any IT manager or network architect responsible for public-access networks in hotels, stadiums, or retail spaces, getting this architecture right is critical. It's the core mechanism that balances seamless user onboarding with robust security and compliance. In the next ten minutes, we'll dissect how these components fit together at a network level, providing the clarity you need to design and deploy a high-performance, secure, and scalable guest WiFi solution.

So, let's get straight into the mechanics. How does a user's device, which isn't yet authenticated, get redirected to a login page? This is the central magic of the captive portal. It all starts at the Access Node — this is your Wireless Access Point or network switch. When a new device connects, the Access Node is configured to intercept all outbound web traffic, typically on port 80 for HTTP and port 443 for HTTPS.

Initially, the user is in a digital quarantine. The Access Node, in conjunction with a gateway or firewall, enforces a restrictive policy. Any attempt by the user to access an external website results in one of two primary redirection methods. The most common is an HTTP 302 redirect. The user's browser requests, say, 'google.com', but the network gateway intercepts this and responds with a temporary redirect to the captive portal's URL. The user's browser automatically follows this redirect, and the login page appears. The second method is DNS redirection, where the network's DNS server is configured to resolve all external hostnames to the IP address of the captive portal server, until the user is authenticated.

This brings us to the core components. First, the Access Node we mentioned. Its job is to control the 'on' or 'off' switch for the user's internet access. It doesn't make the decision itself; it acts on instructions. The decision-maker is often a RADIUS server. RADIUS — which stands for Remote Authentication Dial-In User Service — is an industry-standard protocol for centralized Authentication, Authorization, and Accounting, or 'triple-A'. When a user submits their credentials on the portal page — perhaps a social login, an email address, or a room number — the captive portal server packages this information into a RADIUS Access-Request packet and sends it to the RADIUS server.

The RADIUS server checks the credentials against its database, or proxies the request to another identity source like a hotel's Property Management System or an enterprise Active Directory. If the credentials are valid, it sends back a RADIUS Access-Accept message to the Captive Portal, which then signals the Access Node to open the gate for that user's device, identified by its MAC address. The RADIUS server can also send specific policy instructions, like bandwidth limits or session duration, through RADIUS attributes. This is how you can offer tiered access — a free basic service and a paid premium one, for example.

Now, what about the 'walled garden'? This is a crucial concept. Before authentication, you might need to allow users to access specific websites. For example, a hotel guest might need to access the hotel's own website, or a payment gateway to purchase premium access. The walled garden is a set of firewall rules that whitelists the IP addresses or domain names of these approved services, while blocking everything else. This is a critical feature for compliance and user experience. For instance, if you use social logins, you must add the domains for Facebook, Google, or LinkedIn to the walled garden, otherwise the user won't be able to load their login pages to authenticate.

So, to recap the flow: a user connects, their traffic is intercepted, they are redirected to the captive portal, they submit credentials, the portal validates these with a RADIUS server, and upon success, the RADIUS server instructs the access node to grant full internet access. It's a well-defined, robust, and standards-based architecture.

Now for some key implementation recommendations. First, centralise your RADIUS and captive portal servers where possible, especially for multi-site deployments like a retail chain. This simplifies management and ensures consistent policy enforcement. Second, ensure your architecture is scalable. A conference centre with five thousand attendees hitting the portal simultaneously is a very different scenario from a small café. Your portal and RADIUS servers must be able to handle the authentication load without falling over. A common pitfall here is under-provisioning the servers, leading to slow logins and a poor user experience.

Another critical point is security. Ensure all communication between the captive portal and the RADIUS server is secured using IPsec or RADIUS over TLS. And always, always use HTTPS for your captive portal page to protect user credentials in transit. Failing to do so is not just bad practice; it can violate data protection regulations like GDPR.

Let's move to a rapid-fire Q&A. First question: How does this relate to IEEE 802.1X? They are two different approaches to network admission control. 802.1X is a port-based authentication mechanism that happens at a lower network layer, before an IP address is even assigned. It's more secure but requires a supplicant on the client device, making it great for corporate devices but less so for public guest access. Captive portals operate at the application layer, making them universally compatible with any device that has a web browser.

Second question: Can I use my existing firewall for the walled garden? Yes, absolutely. Most enterprise-grade firewalls can be configured with the pre-authentication rules needed to create a walled garden. The key is integrating it with your access nodes so that users can be moved to a different, less restrictive firewall policy post-authentication.

To summarise, a successful captive portal architecture hinges on the seamless interaction between the Access Node, the Captive Portal Server, and the RADIUS server. Your design must prioritise scalability, security, and a positive user experience. By using standards-based protocols and carefully planning your redirection methods and walled garden policies, you can build a guest WiFi network that is both welcoming to users and a powerful asset for your business.

For a much deeper dive into the specific configurations, vendor-neutral best practices, and detailed troubleshooting guides, I encourage you to read our full technical reference guide. Thank you for listening to the Purple Technical Briefing.

Resumen ejecutivo

Esta guía ofrece un análisis técnico en profundidad de la arquitectura de Captive Portal, diseñada para directores de TI, arquitectos de redes y directores de operaciones. Desglosa los componentes principales, desde el nodo de acceso hasta el servidor RADIUS, explicando cómo funcionan al unísono los mecanismos de redirección, autenticación y control de acceso a nivel de red. Al explorar estándares como 802.1X, el papel del walled garden y escenarios de implementación reales, este documento dota a los profesionales tecnológicos de alto nivel de los conocimientos prácticos necesarios para diseñar, implementar y gestionar una red WiFi para invitados segura, escalable y de alto rendimiento que ofrezca tanto una experiencia de usuario fluida como un sólido retorno de la inversión.

Análisis técnico en profundidad

Un Captive Portal es la puerta de enlace al WiFi para invitados, pero su aparente simplicidad oculta una arquitectura sofisticada. Comprender esta arquitectura es fundamental para implementar una solución segura, escalable y que cumpla con las normativas. Este análisis en profundidad examina el recorrido de un usuario desde la conexión hasta la autenticación, detallando el papel de cada componente a nivel de red.

La conexión inicial y la redirección

El proceso comienza cuando el dispositivo de un usuario (el suplicante) se asocia a un nodo de acceso (AN) inalámbrico, normalmente un punto de acceso (AP) WiFi. En esta etapa, el dispositivo tiene una conexión de Capa 2, pero no tiene acceso a la red en general. El AN, que funciona en conjunto con una puerta de enlace de red o un firewall, está configurado para interceptar todo el tráfico web saliente de los usuarios no autenticados.

El principal desafío es forzar al navegador web del usuario a ir a la página de inicio de sesión del Captive Portal. Se utilizan dos métodos principales:

Redirección HTTP: Cuando el usuario intenta acceder a un sitio web HTTP, la puerta de enlace de la red intercepta el paquete TCP SYN. En lugar de reenviarlo, la puerta de enlace completa el protocolo de enlace TCP (handshake) con el cliente y, al recibir la solicitud HTTP GET, devuelve una respuesta HTTP/1.1 302 Found o 307 Temporary Redirect. Esta respuesta contiene un encabezado Location que apunta a la URL del Captive Portal. El navegador del cliente, en cumplimiento con el RFC 2616, navega automáticamente a la página del portal.

Redirección DNS: En este modelo, el servidor DNS de la red está configurado para resolver todos los nombres de host externos solicitados por usuarios no autenticados a la única dirección IP del servidor del Captive Portal. Cuando el navegador del usuario intenta resolver un dominio como purple.ai, recibe la dirección IP del portal. A continuación, el navegador inicia una conexión con el portal, que muestra la página de inicio de sesión. Este método puede resultar problemático con clientes modernos que utilizan DNS sobre HTTPS (DoH) o que tienen entradas DNS en caché.

El papel del servidor RADIUS

Una vez que el usuario envía sus credenciales (por ejemplo, correo electrónico, inicio de sesión social, código de cupón) en el portal, el servidor del Captive Portal organiza el proceso de autenticación. Por lo general, no almacena las credenciales del usuario por sí mismo. En su lugar, actúa como cliente de un servidor centralizado de Autenticación, Autorización y Contabilidad (AAA), utilizando casi universalmente el protocolo Remote Authentication Dial-In User Service (RADIUS), tal como se define en el RFC 2865.

El flujo es el siguiente. Primero, Autenticación: el servidor del portal empaqueta las credenciales del usuario y la información de identificación (incluida la dirección MAC del cliente) en un paquete RADIUS Access-Request que se envía al servidor RADIUS. Segundo, Autorización: el servidor RADIUS valida las credenciales frente a su base de datos interna o redirige la solicitud a una fuente de identidad externa: el sistema de gestión de propiedades (PMS) de un hotel, Microsoft Active Directory o un proveedor de identidad social a través de OAuth. Si la autenticación se realiza correctamente, el servidor RADIUS devuelve un mensaje Access-Accept que contiene atributos RADIUS cruciales que definen la política de sesión del usuario, incluidos Session-Timeout, Idle-Timeout y los atributos de ancho de banda WISPr. Tercero, Contabilidad (Accounting): al recibir el mensaje Access-Accept, el servidor del portal indica al nodo de acceso o a la puerta de enlace que permita el tráfico del usuario y, simultáneamente, envía un paquete RADIUS Accounting-Request (Start) para iniciar el registro de la sesión, lo que permite un seguimiento detallado del uso para el cumplimiento normativo y el análisis.

El Walled Garden: Acceso previo a la autenticación

Un componente fundamental de la arquitectura es el walled garden (entorno cerrado). Esto se refiere a un conjunto específico de direcciones IP, nombres de dominio o protocolos a los que un usuario no autenticado tiene permiso para acceder. Se implementa mediante reglas de firewall o listas de control de acceso (ACL) en la puerta de enlace de la red.

Los casos de uso habituales del walled garden incluyen proveedores de identidad de inicio de sesión social (Google, Facebook, LinkedIn), pasarelas de pago (Stripe, PayPal), propiedades web de la marca y recursos de servicios de emergencia. La configuración adecuada del walled garden es un punto de fallo frecuente en las implementaciones. Una lista incompleta puede interrumpir los flujos de trabajo de autenticación, mientras que una lista demasiado permisiva puede crear vulnerabilidades de seguridad.

Guía de implementación

La implementación de una arquitectura de Captive Portal sólida requiere una planificación cuidadosa en varios dominios.

Paso 1 — Diseño de red y selección de componentes: Seleccione AP de nivel empresarial que admitan WPA3 y ofrezcan capacidades de integración sólidas con servidores RADIUS para solicitudes de cambio de autorización (CoA) (RFC 5176), que permiten actualizaciones dinámicas de políticas a mitad de sesión. Asegúrese de que su puerta de enlace de red tenga la flexibilidad necesaria para implementar reglas sofisticadas de redirección y walled garden. Para implementaciones en múltiples ubicaciones, como una cadena minorista, un servidor RADIUS centralizado alojado en la nube proporciona coherencia y simplifica la gestión.

Paso 2 — Configuración del flujo de autenticación: Configure el SSID de invitados en sus AP. Aunque las redes abiertas son comunes, el uso de WPA3-Enhanced Open (OWE) proporciona un cifrado de datos individualizado entre cada cliente y el AP, lo que evita las escuchas pasivas. En su puerta de enlace, cree las reglas de interceptación para clientes no autenticados. Documente e implemente meticulosamente las reglas de firewall para su walled garden, revisando esta lista periódicamente a medida que los servicios de terceros cambian sus estructuras de dominio.

Paso 3 — Experiencia de usuario y onboarding: La página del portal debe ser adaptable, de carga rápida y con una imagen de marca clara, optimizada para dispositivos móviles. Ofrezca múltiples métodos de autenticación (inicios de sesión sociales, captura de correo electrónico y códigos de cupón) alineados con los objetivos comerciales del establecimiento. El portal es un punto crítico para obtener el consentimiento del usuario en virtud del GDPR; asegúrese de que su política de privacidad esté claramente enlazada y de que se obtenga el consentimiento explícito para cualquier procesamiento de datos.

Mejores prácticas

Utilice HTTPS para la página del Captive Portal y cifre todas las comunicaciones entre el portal y el servidor RADIUS utilizando RADIUS sobre TLS o IPsec. En entornos con múltiples ubicaciones, centralice el Captive Portal y la infraestructura RADIUS para garantizar políticas, imagen de marca y recopilación de datos uniformes. Implemente un registro y análisis sólidos para realizar un seguimiento de las tasas de éxito/fracaso de la autenticación, la duración de las sesiones y el uso del ancho de banda. Diseñe para los fallos: defina una política clara sobre si el sistema debe fallar en modo abierto (fail-open) o cerrado (fail-closed) cuando el servidor RADIUS sea inalcanzable, con mensajes de error claros para el usuario.

Resolución de problemas y mitigación de riesgos

Problema común	Causa(s) raíz	Estrategia de mitigación
El usuario no es redirigido al portal	Problemas de DNS (caché del lado del cliente, DoH); configuración incorrecta de la regla de redirección; el cliente utiliza una IP estática.	Implemente la redirección HTTP y DNS como alternativas. Fuerce el uso de DHCP. Utilice el aislamiento de clientes a nivel de AP.
Los botones de inicio de sesión social no funcionan	Walled garden incompleto; se están bloqueando los dominios del proveedor de identidad.	Utilice las herramientas de desarrollador del navegador para identificar los dominios bloqueados y añádalos a las ACL del walled garden.
Tiempos de inicio de sesión lentos	Servidor RADIUS o del portal con aprovisionamiento insuficiente; alta latencia hacia el proveedor de identidad externo.	Realice pruebas de carga en la infraestructura de autenticación. Utilice servicios en la nube distribuidos geográficamente.
El usuario se desconecta con frecuencia	Tiempos de espera de sesión o inactividad agresivos en el servidor RADIUS; señal WiFi deficiente que provoca la reasociación.	Revise los atributos de sesión RADIUS. Realice un estudio de cobertura inalámbrica (site survey) para garantizar una cobertura adecuada.

ROI e impacto comercial

Un Captive Portal bien diseñado es más que una utilidad de red; es un activo comercial. El ROI se mide a través de varios vectores. Marketing basado en datos: la captura de datos de los usuarios (con consentimiento) permite realizar campañas de marketing dirigidas y fomenta la repetición de negocios. Para una cadena minorista, vincular el uso del WiFi a las visitas a la tienda proporciona potentes modelos de atribución. Mejora de la experiencia del cliente: un proceso de inicio de sesión fluido, rápido y seguro mejora la satisfacción de los invitados, lo que repercute directamente en las reseñas y la fidelidad en el sector hotelero. Eficiencia operativa: la gestión centralizada reduce la carga administrativa de los equipos de TI, mientras que los análisis sobre la afluencia y el tiempo de permanencia pueden orientar los niveles de personal y la distribución de las tiendas. Cumplimiento y mitigación de riesgos: una arquitectura sólida garantiza el cumplimiento del GDPR y de la normativa PCI DSS, mitigando el riesgo de importantes sanciones económicas.

Al considerar el Captive Portal no como un centro de costes, sino como una plataforma de interacción, las organizaciones pueden desbloquear un importante valor comercial de su infraestructura de WiFi para invitados.

Key Terms & Definitions

Captive Portal

A web-based authentication mechanism that intercepts a user's HTTP or HTTPS traffic and redirects them to a login page before granting access to the broader network. It operates at the application layer (Layer 7) of the OSI model.

IT teams encounter this as the primary mechanism for controlling guest access to WiFi networks in hotels, retail spaces, stadiums, and public venues. It is the enforcement point for both security policies and business data-capture objectives.

Access Node (AN)

A network device—typically a Wireless Access Point (AP) or a network switch—that provides the physical or wireless connection point for end-user devices. In a captive portal architecture, the AN is responsible for enforcing the access policy dictated by the RADIUS server, either permitting or blocking a user's traffic based on their authentication state.

The AN is the 'gatekeeper' at the edge of the network. Its ability to support features like CoA (Change of Authorization) is critical for dynamic policy updates, such as upgrading a user from a free to a paid tier without requiring them to re-authenticate.

RADIUS (Remote Authentication Dial-In User Service)

A client-server networking protocol defined in RFC 2865 that provides centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to a network service. It uses UDP for transport (ports 1812 for authentication, 1813 for accounting) and a shared secret for message integrity.

RADIUS is the backbone of enterprise network access control. In a captive portal deployment, it is the authoritative source for user identity validation and session policy. IT teams must ensure RADIUS server redundancy and secure communication channels.

Walled Garden

A controlled network environment in which an unauthenticated user's internet access is restricted to a pre-defined set of whitelisted IP addresses, domain names, or services. It is implemented via firewall rules or ACLs on the network gateway.

The walled garden is essential for enabling the authentication process itself (e.g., allowing access to social login providers) and for providing a degree of service before authentication (e.g., access to the venue's own website). Misconfiguration is a leading cause of captive portal authentication failures.

RADIUS Redirect

A mechanism by which the RADIUS server, within an Access-Accept response, includes a vendor-specific attribute (VSA) that instructs the Access Node or gateway to redirect the user's browser to a specific URL—typically the captive portal login page. This is an alternative to gateway-level HTTP interception.

RADIUS redirect is commonly used in architectures where the AP itself handles the redirection logic, rather than a separate gateway. It is supported by most enterprise-grade AP vendors and is particularly useful in distributed deployments where a centralised gateway is not present.

Change of Authorization (CoA)

An extension to the RADIUS protocol defined in RFC 5176 that allows the RADIUS server to dynamically modify an active user session. This enables the server to push new policy attributes (e.g., increased bandwidth) or terminate a session entirely, without requiring the user to re-authenticate.

CoA is the mechanism that enables tiered access models in real time. For example, when a hotel guest upgrades from a free to a paid WiFi tier, the payment system triggers a CoA request to the RADIUS server, which then pushes the new bandwidth policy to the Access Node instantly.

WPA3-Enhanced Open (OWE)

A WiFi security mode defined in IEEE 802.11 that provides opportunistic wireless encryption on open (no-password) networks. Each client device negotiates an individual encryption key with the AP, preventing passive eavesdropping by other users on the same network, without requiring a password.

OWE is the recommended security mode for guest WiFi networks that use a captive portal for authentication. It provides a significant security improvement over traditional open networks (which transmit all data in plaintext) while maintaining the seamless connection experience users expect from public WiFi.

AAA (Authentication, Authorization, and Accounting)

A security framework for controlling access to network resources. Authentication verifies identity, Authorization determines what the authenticated user is permitted to do, and Accounting records what the user did and for how long. RADIUS is the most common protocol implementing this framework.

The AAA framework is the conceptual foundation of all enterprise network access control. For venue operators, the Accounting component is particularly valuable, as it provides the audit trail required for regulatory compliance and the usage data needed for network capacity planning.

IEEE 802.1X

An IEEE standard for port-based Network Access Control (PNAC). It provides an authentication mechanism for devices wishing to attach to a LAN or WLAN, operating at Layer 2 before an IP address is assigned. It requires a supplicant (client software), an authenticator (the AP or switch), and an authentication server (typically RADIUS).

802.1X is the standard for corporate device authentication (e.g., employee laptops) and is distinct from captive portal authentication. IT teams should understand the difference: 802.1X is more secure but requires client-side configuration, making it unsuitable for guest devices. A well-designed network uses both — 802.1X for corporate devices and a captive portal for guests.

Case Studies

A 350-room international hotel brand is deploying a new guest WiFi system across its flagship London property. The CTO requires social login (Google and Facebook), email capture for the loyalty programme, PCI DSS compliance for a premium paid-access tier, and GDPR-compliant consent management. The existing network uses a mix of Cisco and Aruba access points. How should the captive portal architecture be designed?

The recommended architecture is a cloud-hosted captive portal platform (such as Purple) integrated with a centralized cloud RADIUS server. The deployment proceeds as follows:

SSID Configuration: Create two SSIDs — a guest SSID (WPA3-OWE) for the captive portal flow, and a management SSID (WPA3-Enterprise, 802.1X) for staff devices. Segment these into separate VLANs.
Redirection: Configure the gateway firewall with HTTP 302 redirect rules for the guest VLAN, targeting the cloud portal URL. Implement DNS redirection as a secondary fallback.
Walled Garden: Whitelist the following domain groups: accounts.google.com, *.googleapis.com (Google Login); *.facebook.com, *.fbcdn.net (Facebook Login); the hotel's own domain; the payment gateway's domains (e.g., *.stripe.com). This is critical for the social login flow to function.
RADIUS Integration: Configure the cloud portal to send RADIUS Access-Request packets to the centralized RADIUS server. Define two user groups: 'Free' (bandwidth-limited via WISPr attributes: 5 Mbps down, 2 Mbps up; 1-hour session timeout) and 'Premium' (unlimited bandwidth; 24-hour session timeout). The premium tier is unlocked after a payment transaction, with the RADIUS server dynamically updating the user's policy via a Change of Authorization (CoA) request per RFC 5176.
GDPR Consent: The portal landing page presents a clear, unbundled consent form. Users must actively tick a checkbox to consent to marketing communications — pre-ticked boxes are non-compliant under GDPR. The consent timestamp and method are logged and stored.
PCI DSS: The payment page is hosted on the payment gateway's domain (within the walled garden), ensuring that card data never transits the hotel's network infrastructure, significantly reducing the PCI DSS scope.

Implementation Notes: This solution correctly addresses the multi-layered requirements. The key architectural decision is using a cloud-hosted portal and RADIUS, which provides scalability and removes the burden of on-premise server maintenance. The separation of the payment flow to the gateway's domain is a critical PCI DSS scoping decision — many operators make the mistake of building a custom payment page on their own infrastructure, dramatically increasing their compliance obligations. The dual-SSID approach cleanly separates guest and staff traffic. The walled garden configuration, particularly the inclusion of CDN domains like `fbcdn.net`, is a detail that is frequently overlooked and causes social login failures in production.

A national retail chain with 280 stores wants to deploy a unified guest WiFi platform. Each store has between 2 and 8 access points. The business objective is to capture customer email addresses and link WiFi sessions to in-store purchase data from the EPOS system. The IT team is small and cannot manage per-store configurations. How should the architecture be structured for scale?

A centralised, cloud-managed architecture is the only viable approach at this scale. The deployment model is as follows:

Centralised Management: Deploy a cloud-managed WiFi platform where all 280 stores are managed from a single dashboard. Access nodes at each store are zero-touch provisioned — they connect to the cloud controller on first boot and receive their full configuration automatically. No per-store manual configuration is required.
Standardised SSID and Portal Template: Define a single SSID template and a single branded portal template that is pushed to all stores. Any changes to the portal design or authentication policy are made once and propagated to all 280 locations simultaneously.
Centralised RADIUS: All authentication requests from all stores are directed to a pair of redundant, cloud-hosted RADIUS servers. This provides a single point of policy management and a unified data store for all user sessions.
EPOS Integration: The WiFi platform's API is integrated with the EPOS system. The customer's email address (captured at WiFi login) is used as the matching key. When a customer makes a purchase, the EPOS system queries the WiFi platform's API to check if a WiFi session was active for that email address within the store's geographic boundary, creating an attribution record.
Walled Garden: A single, centrally-managed walled garden policy is applied to all stores, covering the email validation service and any social login providers used.

Implementation Notes: The critical insight here is that the architecture must be designed for operational efficiency, not just technical correctness. A per-store configuration model would be unmanageable for a small IT team. Zero-touch provisioning and centralised policy management are non-negotiable at this scale. The EPOS integration is the key business value driver — it transforms the WiFi system from a utility into a customer intelligence platform. The use of email as the matching key is pragmatic, though the solution architect should note that this requires robust data governance to ensure GDPR compliance, particularly around data retention and the right to erasure.

Scenario Analysis

Q1. A stadium with a capacity of 60,000 is deploying guest WiFi for a major sporting event. The network team expects 40,000 concurrent device connections, with a peak authentication burst of approximately 8,000 logins per minute at kick-off. The venue's IT director wants to use a social login (Google/Facebook) captive portal. What are the three most critical architectural decisions the network architect must address to ensure the authentication system does not become a bottleneck?

💡 Hint:Consider the load on each component in the authentication chain: the portal server, the RADIUS server, and the external identity provider. Also consider the network-level implications of 40,000 concurrent DHCP leases and ARP tables.

Show Recommended Approach

The three most critical architectural decisions are: (1) RADIUS Server Scalability: A single RADIUS server instance will be unable to handle 8,000 authentication requests per minute. The architect must deploy a horizontally scaled cluster of RADIUS servers behind a load balancer, with session state shared via a distributed cache (e.g., Redis). The RADIUS server's database connection pool must also be sized appropriately. (2) Captive Portal Server Scalability: Similarly, the portal server must be horizontally scaled. A cloud-hosted portal platform with auto-scaling capabilities is strongly recommended over on-premise servers, which cannot be rapidly provisioned. (3) Walled Garden and External Identity Provider Latency: Social logins introduce a dependency on external services (Google/Facebook). Under high load, the round-trip time to these providers can increase significantly. The architect should consider offering a faster, lower-friction alternative (e.g., a simple click-through or SMS OTP) as the primary authentication method for the mass audience, reserving social login for users who specifically prefer it. Additionally, the DHCP server must be configured with a large enough pool for 40,000+ leases, and the network gateway must be capable of maintaining state for 40,000 concurrent sessions without exhausting its connection table.

Q2. A large NHS hospital trust is evaluating a guest WiFi deployment for patient and visitor use. The information governance team has raised concerns about GDPR compliance, specifically around data retention, the right to erasure, and the lawful basis for processing patient data. The proposed portal design captures email addresses and allows social logins. What changes to the architecture and portal design are required to achieve compliance?

💡 Hint:Consider the distinction between patients (a potentially special category of data subject under GDPR Article 9) and general visitors. Also consider the lawful basis for processing — is consent the appropriate basis, or could legitimate interest apply? What are the implications of each?

Show Recommended Approach

Several architectural and design changes are required. First, Lawful Basis: For a public-sector body, consent is typically the most appropriate lawful basis for processing guest WiFi data. However, the trust's Data Protection Officer (DPO) must confirm this. The portal must present a clear, unbundled consent request — separate checkboxes for 'access to WiFi' and 'marketing communications', with the former not conditional on the latter. Second, Data Minimisation: The portal should only capture the minimum data necessary. For a hospital environment, capturing email addresses may be justifiable for service notifications, but social logins (which can expose additional profile data) should be evaluated carefully. Consider whether a simple click-through with IP logging (for network security purposes) is sufficient. Third, Right to Erasure: The backend system must support a data erasure workflow. When a user submits a right-to-erasure request, all associated data (email, session logs, usage data) must be deleted within 30 days. This requires a clear data map of where user data is stored across the portal, RADIUS, and analytics systems. Fourth, Data Retention Policy: Define and enforce a clear retention period for session logs. Retaining data for longer than necessary is a GDPR violation. A 90-day rolling retention window for session logs is a common and defensible policy. Fifth, Special Category Data: The trust must ensure that the WiFi system does not inadvertently capture or infer health-related data. The portal must not ask questions about the user's reason for visiting the hospital.

Q3. A network engineer is troubleshooting a captive portal deployment at a conference centre. Attendees report that they are successfully connecting to the WiFi and reaching the portal login page, but when they attempt to log in using their LinkedIn credentials, the social login button appears to load briefly and then fails silently. Email/password login works correctly. What is the most likely cause, and what is the diagnostic process?

💡 Hint:The fact that the portal page loads correctly and email login works rules out issues with the portal server itself and the RADIUS integration. The problem is specific to the LinkedIn OAuth flow. Consider what network resources the LinkedIn login process requires that the email login does not.

Show Recommended Approach

The most likely cause is an incomplete walled garden configuration. The LinkedIn OAuth flow requires the user's browser to make requests to multiple LinkedIn domains and CDN resources. If these domains are not whitelisted in the pre-authentication firewall rules, the browser will silently fail to load the necessary JavaScript or complete the OAuth redirect. The diagnostic process is as follows: (1) Open the browser's developer tools (F12) on a device connected to the guest WiFi but not yet authenticated. (2) Navigate to the portal page and attempt the LinkedIn login. (3) In the 'Network' tab of developer tools, filter for failed requests (status 0, ERR_CONNECTION_REFUSED, or similar). (4) Identify the specific domains that are being blocked. Common LinkedIn domains that must be whitelisted include www.linkedin.com, platform.linkedin.com, static.licdn.com, and media.licdn.com. (5) Add the identified domains to the walled garden ACLs on the network gateway. (6) Re-test. If the issue persists, repeat the diagnostic process to identify any remaining blocked domains. This is a methodical process — use the browser's network inspector as your primary diagnostic tool for walled garden issues.

Key Takeaways

✓Captive portal architecture is a five-component system: Guest Device, Access Node, Gateway/Firewall, Captive Portal Server, and RADIUS Server — each with a distinct and interdependent role in the authentication flow.
✓Network-level redirection is achieved via HTTP 302 redirects (gateway intercepts TCP and returns a redirect response) or DNS redirection (all hostnames resolve to the portal IP). Modern deployments should implement both as fallbacks.
✓The walled garden is a pre-authentication whitelist of IP addresses and domains that must be meticulously configured to include all social login provider domains, payment gateways, and brand assets — incomplete walled gardens are the most common cause of authentication failures.
✓RADIUS is the authoritative AAA engine: it validates credentials, returns session policy attributes (bandwidth, timeout), and supports dynamic policy updates via Change of Authorization (CoA, RFC 5176), enabling real-time tier upgrades without re-authentication.
✓For deployments exceeding 10 sites, a cloud-hosted, centrally managed architecture is the only operationally viable approach — zero-touch provisioning and centralised policy management are non-negotiable for small IT teams managing large estates.
✓GDPR and PCI DSS compliance must be designed into the architecture from the outset, not retrofitted: the portal is the primary consent-capture point, and the payment flow must be scoped to the payment gateway's domain to minimise PCI DSS obligations.
✓A well-architected captive portal delivers measurable ROI through customer data capture, marketing attribution, and enhanced guest experience — it should be positioned as a business intelligence platform, not merely a network access utility.