How Captive-Portal Hotspot Systems Work: Interception, DNS, and RADIUS

When a user connects to a public wireless network at an airport, hospitality venue, university campus, or retail facility, web browsers automatically present a login splash screen before granting internet access. Commonly known as a captive portal or Wi-Fi hotspot gateway, this technology is ubiquitous in public access environments [2].

However, traditional captive portals rely on network interception methods that conflict directly with modern web security protocols such as HTTPS, DNS-over-HTTPS (DoH), and HSTS [1, 2]. In this technical guide, we examine the underlying mechanics of captive portals, compare legacy interception against standardized IETF protocols (RFC 8908 and RFC 8910), and analyze backend RADIUS authentication and accounting integration [1, 3].

1. The Anatomy of a Captive Portal Session

A captive portal is an access-enforcement mechanism implemented on a network gateway or router that blocks outbound internet access for unauthenticated client devices, redirecting their initial web requests to an authorization portal [2].

A standard user session unfolds across four operational stages:

1. Network Attachment & Addressing: The client connects to an open Wi-Fi SSID and receives an IP address, subnet mask, and DNS server via DHCP.
2. Access Detection: The client operating system attempts to connect to a known HTTP validation URL (such as Android's connectivitycheck.gstatic.com or Apple's captive.apple.com/hotspot-detect.html).
3. Redirection & Authorization: The gateway intercepts the connection and presents the portal login page. The user authenticates (via voucher code, SMS OTP, or user credentials).
4. State Elevation: The gateway marks the client's MAC and IP address as authorized in its firewall filter tables, allowing normal outbound traffic [2].

2. Legacy Interception Methods and Why They Break Modern Security

Historically, captive portals operated by intercepting network traffic without the client's explicit cooperation.

Method A: DNS Hijacking

In early hotspot deployments, the gateway intercepted all outbound UDP port 53 DNS queries from unauthenticated clients. Regardless of whether the client queried example.com or bank.com, the gateway's rogue DNS resolver returned the IP address of the local captive portal server.

• Why it breaks today: With the widespread adoption of DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNSSEC, modern operating systems detect DNS tampering. If a client attempts to resolve an encrypted query and receives a fabricated response, the connection fails with a severe security warning.

Method B: HTTP 302 Interception (The HTTPS Problem)

Under standard HTTP interception, unauthenticated clients attempting to load http://example.com have their TCP port 80 connection intercepted by the router's local firewall. The router returns an HTTP 302 Moved Temporarily response pointing to the portal URL (https://hotspot.local/login).

• Why it breaks today: More than 95% of modern web traffic utilizes HTTPS on port 443. When a router intercepts a TLS handshake to inject a redirect, the client's browser verifies the cryptographic certificate. Because the router cannot generate a valid certificate for the requested third-party domain (e.g., google.com), the browser displays an alarming "Your connection is not private / SSL Certificate Error" screen, completely blocking the redirect [2].

3. The Modern Standard: RFC 8908 and RFC 8910 Captive-Portal Architecture

Recognizing that legacy network interception was fundamentally broken by TLS and encrypted DNS, the IETF ratified RFC 8908 and RFC 8910 to standardize captive portal detection natively [1, 2].

DHCP Option 114 and IPv6 Router Advertisements

Rather than forcing routers to tamper with packets on the wire, the access gateway explicitly announces the presence of a captive portal during initial IP address assignment [1]:

• DHCP Option 114 (Captive-Portal): When assigning an IPv4 address, the DHCP server includes Option 114 containing the URI of the captive portal API endpoint (e.g., https://portal.example.com/api/v1/captive).
• IPv6 Router Advertisement (RA): In IPv6 environments, the router includes the Captive-Portal RA option with the identical URI [1].

The Captive Portal API Flow

When the client device receives the API URI, the operating system executes a clean JSON query over HTTPS without touching the user's browser [2]:

GET /api/v1/captive HTTP/1.1
Host: portal.example.com
Accept: application/captive+json

The gateway's API responds with a structured payload:

{
  "captive": true,
  "user-portal-url": "https://portal.example.com/login?client_mac=aa:bb:cc:dd:ee:ff",
  "seconds-remaining": 0,
  "can-extend-session": false
}

Because the operating system explicitly understands that it is behind a captive portal, it immediately spawns a dedicated native WebSheet UI window pointing to the user-portal-url. There is zero DNS spoofing, zero certificate forgery, and zero browser warning screens [2].

4. Backend Authentication: The RADIUS Architecture

While the portal gateway handles local packet interception, enterprise user accounts, voucher inventories, and billing records reside on a centralized RADIUS server (Remote Authentication Dial In User Service / RFC 2865) [3].

The hotspot gateway functions as a Network Access Server (NAS), communicating with the central RADIUS backend using standard UDP messages (Authentication on port 1812; Accounting on port 1813) [3].

The AAA Workflow

1. Authentication: The subscriber enters their credentials or voucher code into the portal web page. The portal backend transmits an Access-Request packet to the RADIUS server containing:
   • User-Name and User-Password
   • NAS-IP-Address and NAS-Port
   • Calling-Station-Id (the client's MAC address)
2. Authorization: The RADIUS server verifies the credentials against its database. If valid, it returns an Access-Accept message containing standard vendor attributes:
   • Session-Timeout: Maximum allowed duration in seconds (e.g., 3,600s for a 1-hour session).
   • WISPr-Bandwidth-Max-Up / Down: Rate-limiting parameters pushed directly to the router's queue.
3. Accounting: Once the client begins transmitting data, the gateway sends periodic Accounting-Request (Interim-Update) packets reporting transmitted bytes (Acct-Input-Octets) and received bytes (Acct-Output-Octets). If a user consumes their allotted data quota, the RADIUS server instructs the gateway to terminate the session via a Disconnect Message (CoA / RFC 5176) [3].

Architectural Comparison: Interception vs RFC 8908/8910

Best Practices for Hotspot Network Engineering

1. Configure RFC 8908 DHCP Option 114: Update your core DHCP servers to broadcast the captive portal URI, ensuring modern iOS, Android, and Windows devices open the login window smoothly [1].
2. Implement Walled Gardens Carefully: Define explicit IP and domain whitelists (walled garden) allowing unauthenticated users to resolve DNS, download portal assets (CSS/images), and connect to payment gateways without getting redirected.
3. Deploy Centralized RADIUS Accounting: Never store voucher databases locally on individual edge routers. Use a resilient, centralized RADIUS cluster to enable unified cross-location roaming and real-time quota tracking [3].

Deploying secure, high-density public access infrastructure requires specialized integration between routing hardware and authentication backends. Explore our Customer Portal & Billing Engineering capabilities.

Key Takeaways

• Captive portals restrict network access until a client authenticates via a web interface.
• Legacy DNS and HTTP 302 interception methods are fundamentally incompatible with modern HTTPS and encrypted DNS.
• RFC 8908 and RFC 8910 standardize captive portal detection natively through DHCP Option 114 and JSON APIs.
• The RADIUS protocol (RFC 2865) centralizes authentication, session limits, and data accounting across distributed hotspot routers.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 8908: Captive-Portal Identification in DHCP and Router Advertisements (RAs)", 2020. URL: https://www.rfc-editor.org/rfc/rfc8908.html (Defines the standard DHCP Option 114 and IPv6 Router Advertisement options for declaring captive portal presence).

[2] IETF, "RFC 8910: Captive-Portal Architecture", 2020. URL: https://www.rfc-editor.org/rfc/rfc8910.html (Standard architectural framework detailing client discovery, API negotiation, and session state enforcement).

[3] IETF, "RFC 2865: Remote Authentication Dial In User Service (RADIUS)", 2000. URL: https://www.rfc-editor.org/rfc/rfc2865.html (Defines the standard protocol architecture for centralized AAA client-server communications).

Last reviewed: October 2026