How Captive Portals Work: The Complete Technical Guide

By

Captive portals are the invisible gatekeepers of public WiFi, intercepting user traffic and redirecting them to a login page before granting internet access. Understanding the technical mechanics helps network administrators implement secure, efficient WiFi systems.

The Core Architecture

A captive portal system consists of four main components:

1. Access Point (AP)

The wireless router that connects user devices to the network. It handles:

  • Signal transmission (2.4GHz/5GHz radio)

  • Device authentication (WPA2/WPA3)

  • Basic traffic forwarding

2. Firewall/Routing Layer

The network device that enforces access control:

  • Traffic interception: Blocks all internet traffic except port 80 (HTTP)

  • Port redirection: Forces HTTP requests to captive portal server

  • ACL (Access Control Lists): Defines which users get access after authentication

3. DHCP Server

Assigns IP addresses to connecting devices:

  • Dynamic IP assignment: 192.168.1.100 → 192.168.1.101 → etc.

  • DNS server propagation: Tells devices which DNS to use (often the firewall's IP)

  • Gateway configuration: Sets the router as the default gateway

4. Captive Portal Server

The web server hosting the login page:

  • Authentication logic: Validates credentials against database

  • Session management: Creates user sessions with time limits

  • Policy enforcement: Applies bandwidth rules and content filtering

The Authentication Flow (Step-by-Step)

Step 1: Device Connection

text
User Device → WiFi SSID → AP → DHCP Request

User selects network name (SSID), access point responds, DHCP server assigns IP address.

Step 2: DHCP Assignment

text
DHCP Server → User Device: IP=192.168.1.105, DNS=192.168.1.1, Gateway=192.168.1.1

Device receives IP, knows to send all traffic to gateway (router).

Step 3: Traffic Interception

text
User Device → Browser → HTTP Request (google.com) → Firewall → BLOCKED

User opens browser, tries to visit website. Firewall blocks traffic on all ports except port 80.

Step 4: HTTP Redirect

text
HTTP Request (port 80) → Firewall → Redirect Rule → Captive Portal Server (IP:80)

Firewall detects HTTP request, redirects to captive portal server IP address.

Step 5: Portal Display

text
Captive Portal Server → User Browser → Login Page (HTML/CSS/JS)

Browser displays login page: email input, social buttons, terms checkbox.

Step 6: User Authentication

text
User → Enter Email → POST Request → Captive Portal → Database Check

User submits credentials, portal validates against database (or social API).

Step 7: Access Grant

text
Database → "Valid" → Firewall → Update ACL → Allow Internet Access

Firewall updates ACL, grants user device internet access under defined policies.

Step 8: Session Start

text
Captive Portal → Session Database → User ID + Start Time + Expiration

Session created with time limit (e.g., 1 hour).

Packet-Level Details

TCP Connection Flow

text
Client SYN → Firewall → DROP (port 80 exception)
Client SYN → Captive Portal → SYN-ACK → ACK → HTTPS Connection

HTTP Header Manipulation

Firewall modifies HTTP headers to force redirect:

text
Original: GET http://google.com/
Modified: GET http://captive-portal-ip/login.php
Header: Location: http://captive-portal-ip/login.php

Authentication Methods Explained

Email Authentication

  • Form submission: POST email to server

  • Database insert: Store email in user table

  • Token generation: Create unique access token

  • Session ID: Link token to user device MAC address

Social Login (OAuth 2.0)

text
Client → Click "Login with Facebook" → Redirect to Facebook OAuth
Facebook → Validate User → Return Access Token → Portal Server
Portal → Exchange Token for User Data → Create Session → Grant Access

Password/Voucher

  • Pre-generated: Admin creates password in database

  • Time-based: Voucher valid for specific duration (e.g., 24 hours)

  • Usage tracking: Database records when voucher was first used

Session Management

Session Table Structure

text
user_id | mac_address | ip_address | start_time | expiration | bandwidth_limit
--------|-------------|------------|------------|------------|----------------
1001 | 00:1A:2B:3C | 192.168.1.105 | 14:30:00 | 15:30:00 | 5 Mbps

Session Expiration

  • Timer-based: Countdown from start_time

  • Checkpoints: Firewall checks session table every 30 seconds

  • Auto-disconnect: When expiration reached, remove ACL entry

Security Considerations

HTTPS Pirouette

  • Initial HTTP: User connects via HTTP (port 80)

  • Redirect to HTTPS: Portal redirects to HTTPS (port 443)

  • Benefit: Encrypts credentials during login

MAC Address Binding

  • Session tied to MAC: Prevents credential sharing

  • Limitation: MAC spoofing possible (advanced users)

IP Address Tracking

  • DHCP lease time: Typically 24 hours

  • Session renewal: User must re-authenticate after lease expires

Common Implementation Platforms

Platform Type Strengths
Mikrotik RouterOS Built-in hotspot manager, voucher system
Ubiquiti UniFi AP + Controller Cloud-based management, analytics
OpenWRT Firmware Customizable, open-source
Powerlynx Cloud SaaS Multi-location, payment integration

Bottom Line

Captive portals work through interception, redirection, authentication, and release. The firewall blocks traffic, redirects HTTP to the portal, validates credentials, then grants access. This "Catch and Release" mechanism ensures only authorized users consume bandwidth while capturing valuable data for marketing and analytics.

Related Posts

Scroll to Top