# Captive Portal [[Captive Portal (Wikipedia)]] [[RFC 6585 (Additional HTTP Status Codes)#511 Network Authentication Required 8c7492]] ![[RFC 6585 (Additional HTTP Status Codes)#^615a1d]] ![[RFC 6585 (Additional HTTP Status Codes)#^521ac1]] ## Redirect Methods ### 1. WiFi Passpoint (Hotspot 2.0) ### 2. [HTTP Redirect](https://www.wikiwand.com/en/Captive_portal#/HTTP_redirect) When client device first connects, it makes an HTTP request to a special endpoint (what?); if the endpoint returns 200 or 204, then it assume unlimited internet. Otherwise, if it returns 302 (redirect) to the captive portal, the device will know that it needs to auth to gain access. Alternatively, ALL HTTP requests from the client are redirected until auth'ed. Problem: How does this work when the client is HTTPS only? #### ArubaNetworks Example [[ArubaNetworks Captive Portal]] #### HTTP 302 Redirect Example: ```http # Client request: GET /index.html HTTP/1.1 Host: www.example.com # Server response: HTTP/1.1 302 Found Location: http://www.iana.org/domains/example/ ``` #### HTTP 511 Example: ![[RFC 6585 (Additional HTTP Status Codes)#511 Captive Portal Example]] ### 3. ICMP Redirect TODO ### 4. DNS Redirect Use [DNS Hijacking](https://www.wikiwand.com/en/DNS_hijacking) to return IP of captive portal for all DNS requests until client is auth'ed. DNS response should use TTL=0 to avoid poisoning client's DNS cache. Problem: how does this work if the client has their own DNS server configured (e.g. 8.8.8.8)? Could do DNS packet rewriting I guess... Problem: when the client looks up `google.com`, what if their local DNS cache is already hot? They will never make a DNS request that we can rewrite.