Editing Captive portal (section)

==Limitations==

=== Security ===
Captive portals have been known to have incomplete firewall rule sets{{emdash}}such as outbound ports being left open{{emdash}}that allow clients to circumvent the portal.<ref>{{Cite web|last=Laliberte|first=Marc|date=August 26, 2016|title=Lessons from DEFCON 2016 – Bypassing Captive Portals|url=https://www.secplicity.org/2016/08/26/lessons-defcon-2016-bypassing-captive-portals/|access-date=2019-03-06|archive-date=2019-02-04|archive-url=https://web.archive.org/web/20190204065836/https://www.secplicity.org/2016/08/26/lessons-defcon-2016-bypassing-captive-portals/|url-status=live}}</ref>

==== DNS tunneling ====
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 protocol|tunneling]] arbitrary traffic within DNS packets.

==== Automatic submission ====
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 Apple's Captive 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.

==== MAC spoofing ====
A captive portal that uses MAC addresses to track connected devices can sometimes be circumvented by re-using the MAC address of a previously authenticated device. Once a device has been authenticated to the captive portal using valid credentials, the gateway adds that device's MAC address to its allowlist; since MAC addresses can easily be spoofed, any other device can pretend to be the authenticated device and bypass the captive portal. Once the IP and MAC addresses of other connecting computers are found to be authenticated, any machine can spoof the MAC address and [[IP address|Internet Protocol (IP) address]] 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.{{explain|date=November 2024}}

=== Require web browser ===
Captive portals often require the use of a web browser; users who first use an email client or other application that relies on the Internet may find the connection not working without explanation, and will then need to open a web browser to validate. This may be problematic for users who do not have any web browser installed on their [[operating system]]. 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 address rather than the hostname). A similar problem can occur if the client uses [[AJAX]] or joins the network with pages already loaded into its web browser, causing [[undefined behavior]] (for example, corrupt messages appear) when such a page tries HTTP requests to its origin server. 

Similarly, as HTTPS connections cannot be redirected (at least not without triggering security warnings), a web browser that only attempts to access secure websites before being authorized 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 (media)|walled garden]]. For example, in 2005 Nintendo and [[Wayport, Inc.|Wayport]] partnered to provide free Wi-Fi access to Nintendo DS users at certain [[McDonald's]] restaurants.<ref>{{cite web
| title=Nintendo And Wayport Join Forces To Bring Free U.S. Wi-Fi Access To Nintendo DS Users
| url=https://www.gamesindustry.biz/articles/nintendo-and-wayport-join-forces-to-bring-free-us-wi-fi-access-to-nintendo-ds-users
| date=2005-10-18
| access-date=2019-03-06
| archive-date=2019-05-04
| archive-url=https://web.archive.org/web/20190504093329/https://www.gamesindustry.biz/articles/nintendo-and-wayport-join-forces-to-bring-free-us-wi-fi-access-to-nintendo-ds-users
| url-status=live
}}</ref> Also, [[Voice over IP|VoIP]] and [[Session Initiation Protocol|SIP]] ports could be allowed to bypass the gateway to allow phones to make and receive calls.