A captive portal is a web page which is displayed to newly connected
users before they are granted broader access to network resources.
Captive portals are commonly used to present a landing or log-in page
which may require authentication, payment, acceptance of EULA/accepted
use policies, or other valid credentials that both the host and user
agree to adhere by. Captive portals are used for a broad range of
mobile and pedestrian broadband services - including cable and
Wi-Fi and home hotspots. A captive portal can
also be used to provide access to enterprise or residential wired
networks, such as apartment houses, hotel rooms, and business centers.
The captive portal is presented to the client and is stored either at
the gateway or on a web server hosting that page. Depending on the
feature set of the gateway, websites or
TCP ports can be white-listed
so that the user would not have to interact with the captive portal in
order to use them. The
MAC address of attached clients can also be
used to bypass the login process for specified devices.
2.1 HTTP redirect
2.2 ICMP redirect
2.3 Redirect by DNS
3 Circumvention of captive portals
5 See also
7 External links
Captive portals are primarily used in open wireless networks where the
users are shown a welcome message informing them of the conditions of
access (allowed ports, liability, etc.). Administrators tend to do
this so that their own users take responsibility for their actions and
to avoid any legal responsibility. It is discussed whether this
delegation of responsibility is legally valid. 
Often captive portals are used for marketing and commercial
communication purposes. Access to the Internet over open
prohibited until the user exchanges personal data by filling out a
registration form. The online form either automatically opens in a
device's browser, or appears when the user opens their browser and
tries to visit any webpage. In other words, the user is "captive" -
unable to browse freely until they accept the terms and conditions.
This allows the provider of this service to display or send
advertisements to users who connect to the WiFi access point. This
type of service is also sometimes known as social WiFi, as they may
ask for a social network account to login (such as Facebook). Over the
past few years, such Social WiFi captive portals have become
commonplace with various companies such as
marketing centered around WiFi data collection.
The user can find many types of content in the captive portal, and
it's frequent to allow access to the Internet in exchange for viewing
content or performing a certain action (generally providing personal
data to enable commercial contact); thus, the marketing use of the
captive portal is a tool for lead generation (business contacts or
There is more than one way to implement a captive portal.
A common method is to direct all web traffic to a web server, which
returns an HTTP redirect to a captive portal.  When a modern,
internet-enabled device first connects to a network, it sends out an
HTTP request and expects an HTTP status code of 204. If the device
receives a HTTP 204 status code, it assumes it has unlimited internet
Captive portal prompts are displayed when you are able to
manipulate this first HTTP message to return a HTTP status code of 302
(redirect) to the captive portal of your choice.
Client traffic can also be redirected using ICMP redirect on the layer
Redirect by DNS
When a client requests a website, DNS is queried by the browser. In a
captive portal, the firewall will make sure that only the DNS
server(s) provided by the network's DHCP can be used by
unauthenticated clients (or, alternatively, it will forward all DNS
requests by unauthenticated clients to that DNS server). This DNS
server will return the IP address of the captive portal page as a
result of all DNS lookups.
In order to perform redirection by DNS the captive portal uses DNS
hijacking to perform an action similar to a man-in-the-middle attack.
To limit the impact of DNS poisoning, a TTL of 0 is typically used.
Circumvention of captive portals
Captive portals have been known to have incomplete firewall rule
sets. In some deployments the rule set will route DNS requests from
clients to the Internet, or the provided DNS server will fulfill
arbitrary DNS requests from the client. This allows a client to bypass
the captive portal and access the open Internet by tunneling arbitrary
traffic within DNS packets.
Some captive portals may be configured to allow appropriately equipped
user agents to detect the captive portal and automatically
authenticate. User agents and supplemental applications such as
Portal Assistant can sometimes transparently bypass
the display of captive portal content against the wishes of the
service operator as long as they have access to correct credentials,
or they may attempt to authenticate with incorrect or obsolete
credentials, resulting in unintentional consequences such as
accidental account locking.
A captive portal that uses MAC addresses to track connected devices
can sometimes be circumvented by connecting a router that allows
setting of the router MAC address. Router firmware often calls this
MAC cloning. Once a computer or tablet has been authenticated to the
captive portal using a valid username and valid password, the MAC
address of that computer or tablet can be entered into the router
which will often continue to be connected through the captive portal
as it shows to have the same
MAC address as the computer or tablet
that was previously connected.
Some of these implementations merely require users to pass an SSL
encrypted login page, after which their IP and
MAC address are allowed
to pass through the gateway. This has been shown to be exploitable
with a simple packet sniffer. Once the IP and MAC addresses of other
connecting computers are found to be authenticated, any machine can
MAC address and IP of the authenticated target, and be
allowed a route through the gateway. For this reason some captive
portal solutions created extended authentication mechanisms to limit
the risk for usurpation.
Captive portals require the use of a browser; this is usually the
first application that users start, but users who first use an email
client or other application may find the connection not working
without explanation, and will then need to open a browser to validate.
It is however sometimes possible to use email and other facilities
that do not rely on DNS (e.g. if the application specifies the
connection IP rather than the web address). A similar problem can
occur if the client uses
AJAX or joins the network with pages already
loaded into its browser, causing undefined behavior when such a page
tries HTTP requests to its origin server.
HTTPS connections cannot be redirected (at least not
without triggering security warnings), a browser that only attempts to
access secure websites before being authorised by the captive portal
will see those attempts fail without explanation (the usual symptom is
that the intended website appears to be down or inaccessible).
Platforms that have
Wi-Fi and a
TCP/IP stack but do not have a web
browser that supports
HTTPS cannot use many captive portals. Such
platforms include the
Nintendo DS running a game that uses Nintendo
Wi-Fi Connection. Non-browser authentication is possible using WISPr,
an XML-based authentication protocol for this purpose, or MAC-based
authentication or authentications based on other protocols.
It is also possible for a platform vendor to enter into a service
contract with the operator of a large number of captive portal
hotspots to allow free or discounted access to the platform vendor's
servers via the hotspot's walled garden. One such example is the 2005
deal between Nintendo and Wayport to provide free WiFi access to
Nintendo DS users at certain
McDonald's restaurants. Also, VoIP SIP
ports could be allowed to bypass the gateway to allow phones to work.
Wi-Fi Hotspots and Liability Concerns - Maiello Brungo &
Maiello". Maiello Brungo & Maiello. 2007-04-09. Retrieved
^ "Myths and Facts: Running Open Wireless and liability for what
others do". Open Wireless Movement. 2012-08-07. Retrieved
^ Wippler, Andrew J. (2017-04-07). "Captive
Portal Overview". Andrew
Wippler's Sketchpad. Retrieved 2017-05-18.
^ Wippler, Andrew J. (2016-03-11). "WiFi Captive Portal". Andrew
Wippler's Sketchpad. Retrieved 2017-05-18.
Portal Detection - The Chromium Projects".
www.chromium.org. Retrieved 2017-05-18.
^ "Lessons from DEFCON 2016 – Bypassing Captive Portals". Secplicity
- Security Simplified. 2016-08-26. Retrieved 2017-05-18.
^ "Nintendo And Wayport Join Forces To Bring Free U.S.
Wi-Fi Access To
Nintendo DS Users". gamesindustry.biz. Retrieved 24 November
RFC 7710 Captive-
Portal Identification Using DHCP or Router