What is a captive portal

A captive portal is the web page that hotel, airport, cafe, and conference Wi-Fi networks present before letting you reach the open internet. You connect to the SSID, open a browser, and the network redirects you to a login form, terms-of-service page, or paid-access gateway. Until you submit, the network refuses to forward your packets.

The technique is defined loosely in RFC 8908 and RFC 8910, which standardise how the network can advertise the portal URL via DHCP option 114 or IPv6 Router Advertisements. Most legacy portals predate these RFCs and rely on traffic interception instead.

How interception works

Two mechanisms are common.

HTTP redirect. The gateway routes all traffic on TCP port 80 to its own web server, regardless of the destination IP. Your browser asks for http://example.com, the gateway answers with a 302 Found to the portal URL. This works only for plain HTTP. HTTPS sites cannot be redirected this way without triggering a certificate warning, which is why operating systems probe specific known HTTP endpoints (Apple uses captive.apple.com, Microsoft uses www.msftconnecttest.com, Android uses connectivitycheck.gstatic.com) to detect a portal before launching a browser tab.

DNS interception. The gateway returns its own IP for every DNS query, so any hostname resolves to the portal. This is more aggressive, breaks DNSSEC, and trips encrypted DNS clients (DoH/DoT) into failure modes. Networks that intercept DNS often also block UDP/53 to upstream resolvers.

Once you authenticate, the gateway adds your MAC address (or device fingerprint) to an allow-list and stops intercepting your traffic.

Why captive portals break VPNs

A VPN tunnel needs to reach its server. If the captive portal is intercepting all traffic, the tunnel can't establish: the portal's gateway answers the VPN handshake instead of forwarding it. Any kill switch configured to block non-VPN traffic will then block the portal page itself, leaving the user stuck.

The chicken-and-egg problem: you cannot connect the VPN until you finish the portal, but a kill switch may block the portal until you connect the VPN. Most VPN clients solve this by detecting the captive-portal probe response and temporarily relaxing the kill switch in a "captive portal mode" until authentication succeeds.

Security considerations

The portal page itself is served by the network operator, often over plain HTTP. That gives the operator (or anyone close to the operator's infrastructure) the ability to inject scripts into the page. The same trust assumption applies to the operator's DNS resolver, certificate handling for any HTTPS the portal uses, and the WPA2/WPA3 layer underneath.

Three risks are practical:

• Pre-VPN exposure. Any traffic your device sends between joining the SSID and finishing the portal is visible to the operator. macOS and iOS launch the captive-portal browser in a sandboxed view that does not share cookies with Safari, which limits the blast radius. Older Windows and most Android versions use the default browser and full session.
• Spoofed portals. A rogue access point can imitate a hotel's SSID and serve a fake portal that harvests credit card numbers or social logins.
• Persistent script injection. Some hotel networks inject ads or tracking scripts into HTTP pages even after authentication. HTTPS-only browsing defeats this.

Practical guidance

Connect to the network. Let the OS detect the portal and open it. Complete the portal in the OS-provided browser tab if available. Then start the VPN. Avoid logging in to email, banking, or anything sensitive between joining the SSID and connecting the VPN. If the VPN client offers a "captive portal detected" prompt, prefer that flow over manually disabling the kill switch.