Captive Portal Architecture: A Technical Deep Dive

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.

Executive Summary

This guide provides a technical deep-dive into captive portal architecture, designed for IT managers, network architects, and operations directors. It deconstructs the core components—from the access node to the RADIUS server—explaining how network-level redirection, authentication, and access control mechanisms function in unison. By exploring standards like 802.1X, the role of the walled garden, and real-world deployment scenarios, this document equips senior technology professionals with the actionable insights needed to design, implement, and manage a secure, scalable, and high-performance guest WiFi network that delivers both a seamless user experience and a strong return on investment.

Technical Deep-Dive

A captive portal is the gateway to guest WiFi, but its apparent simplicity belies a sophisticated architecture. Understanding this architecture is fundamental to deploying a solution that is secure, scalable, and compliant. This deep-dive examines the journey of a user from connection to authentication, detailing the role of each component at the network level.

The Initial Connection and Redirection

The process begins when a user's device (the supplicant) associates with a wireless Access Node (AN), typically a WiFi Access Point (AP). At this stage, the device has a Layer 2 connection but no broader network access. The AN, operating in conjunction with a network gateway or firewall, is configured to intercept all outbound web traffic from unauthenticated users.

The primary challenge is to force the user's web browser to the captive portal login page. Two primary methods are used:

HTTP Redirect: When the user attempts to access an HTTP website, the network gateway intercepts the TCP SYN packet. Instead of forwarding it, the gateway completes the TCP handshake with the client and, upon receiving the HTTP GET request, returns an HTTP/1.1 302 Found or 307 Temporary Redirect response. This response contains a Location header pointing to the captive portal's URL. The client's browser, compliant with RFC 2616, automatically navigates to the portal page.

DNS Redirect: In this model, the network's DNS server is configured to resolve all external hostnames requested by unauthenticated users to the single IP address of the captive portal server. When the user's browser tries to resolve a domain like purple.ai, it receives the portal's IP address. The browser then initiates a connection to the portal, which serves the login page. This method can be problematic with modern clients that use DNS over HTTPS (DoH) or have cached DNS entries.

The Role of the RADIUS Server

Once the user submits their credentials (e.g., email, social login, voucher code) on the portal, the Captive Portal Server orchestrates the authentication process. It does not typically store user credentials itself. Instead, it acts as a client to a centralised Authentication, Authorisation, and Accounting (AAA) server, almost universally using the Remote Authentication Dial-In User Service (RADIUS) protocol, as defined in RFC 2865.

The flow is as follows. First, Authentication: the portal server packages the user's credentials and identifying information (including the client's MAC address) into a RADIUS Access-Request packet sent to the RADIUS server. Second, Authorisation: the RADIUS server validates the credentials against its internal database or proxies the request to an external identity source—a hotel's Property Management System (PMS), Microsoft Active Directory, or a social identity provider via OAuth. If authentication is successful, the RADIUS server returns an Access-Accept message containing crucial RADIUS attributes that define the user's session policy, including Session-Timeout, Idle-Timeout, and WISPr bandwidth attributes. Third, Accounting: upon receiving the Access-Accept message, the portal server signals the Access Node or gateway to permit the user's traffic and simultaneously sends a RADIUS Accounting-Request (Start) packet to begin the session record, enabling detailed usage tracking for compliance and analytics.

The Walled Garden: Pre-Authentication Access

A critical component of the architecture is the walled garden. This refers to a specific set of IP addresses, domain names, or protocols that an unauthenticated user is permitted to access. It is implemented via firewall rules or access control lists (ACLs) on the network gateway.

Common walled garden use cases include social login identity providers (Google, Facebook, LinkedIn), payment gateways (Stripe, PayPal), brand-owned web properties, and emergency services resources. Proper configuration of the walled garden is a frequent point of failure in deployments. An incomplete list can break authentication workflows, while an overly permissive list can create security vulnerabilities.

Implementation Guide

Deploying a robust captive portal architecture requires careful planning across several domains.

Step 1 — Network Design and Component Selection: Select enterprise-grade APs that support WPA3 and offer robust integration capabilities with RADIUS servers for Change of Authorisation (CoA) requests (RFC 5176), which allow for dynamic policy updates mid-session. Ensure your network gateway has the flexibility to implement sophisticated redirection and walled garden rules. For multi-site deployments such as a retail chain, a centralised cloud-hosted RADIUS server provides consistency and simplifies management.

Step 2 — Configuration of Authentication Flow: Configure the guest SSID on your APs. While open networks are common, using WPA3-Enhanced Open (OWE) provides individualised data encryption between each client and the AP, preventing passive eavesdropping. On your gateway, create the interception rules for unauthenticated clients. Meticulously document and implement the firewall rules for your walled garden, reviewing this list regularly as third-party services change their domain structures.

Step 3 — User Experience and Onboarding: The portal page must be responsive, fast-loading, and clearly branded, optimised for mobile devices. Offer multiple authentication methods—social logins, email capture, and voucher codes—aligned with the venue's business goals. The portal is a critical point for obtaining user consent under GDPR; ensure your privacy policy is clearly linked and that explicit consent is obtained for any data processing.

Best Practices

Use HTTPS for the captive portal page and encrypt all communication between the portal and RADIUS server using RADIUS over TLS or IPsec. In multi-site environments, centralise the captive portal and RADIUS infrastructure to ensure uniform policies, branding, and data collection. Implement robust logging and analytics to track authentication success/failure rates, session durations, and bandwidth usage. Design for failure: define a clear policy for whether the system should fail-open or fail-closed when the RADIUS server is unreachable, with clear error messaging for the user.

Troubleshooting & Risk Mitigation

Common Problem	Root Cause(s)	Mitigation Strategy
User is not redirected to portal	DNS issues (client-side caching, DoH); redirection rule misconfiguration; client using static IP.	Implement both HTTP and DNS redirection as fallbacks. Enforce DHCP. Use AP-level client isolation.
Social login buttons don't work	Incomplete walled garden; identity provider domains are being blocked.	Use browser developer tools to identify blocked domains and add them to the walled garden ACLs.
Slow login times	Under-provisioned RADIUS or portal server; high latency to external identity provider.	Load-test the authentication infrastructure. Use geographically distributed cloud services.
User gets disconnected frequently	Aggressive session or idle timeouts on the RADIUS server; poor WiFi signal causing re-association.	Review RADIUS session attributes. Conduct a wireless site survey to ensure adequate coverage.

ROI & Business Impact

A well-architected captive portal is more than a network utility; it is a business asset. The ROI is measured through several vectors. Data-Driven Marketing: capturing user data (with consent) enables targeted marketing campaigns and drives repeat business. For a retail chain, linking WiFi usage to in-store visits provides powerful attribution models. Enhanced Customer Experience: a seamless, fast, and secure login process improves guest satisfaction, directly impacting reviews and loyalty in hospitality. Operational Efficiency: centralised management reduces administrative overhead for IT teams, while analytics on footfall and dwell time can inform staffing levels and store layouts. Compliance and Risk Mitigation: a robust architecture ensures compliance with GDPR and PCI DSS, mitigating the risk of significant financial penalties.

By viewing the captive portal not as a cost centre but as an engagement platform, organisations can unlock significant business value from their guest WiFi infrastructure.

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.