To access the Internet, I have to log in at my ISP-provided login page which is a private IPv4 address (192.168.xx.xx). If I open Firefox without logging in to that account, Firefox shows this notification saying "You must log in to this network before you can access the Internet" with a "Open Network Login Page" button. That button opens up the ISP login page. Here is a screenshot of that notification:


So, my question is how can Firefox know that login page address?


3 Answers 3


So, my question is how can Firefox know that login page address?

It doesn't, actually.

Your ISP uses a technology known as a Captive Portal. Captive portals work by "somehow" hijacking the browser's HTTP request and re-directing it to the login portal.

This "somehow" can be achieved in different ways, for example

  • HTTP Redirect
  • ICMP Redirect
  • DNS Hijacking

Your browser, in turn, tries to detect this "hijacking" by trying to retrieve a well-known web page and checking whether the response they get back is the response they are expecting or something else. Here are some examples of pages that such "hijacking detection systems" use:

The Google one gives a hint as to how it works: The webserver will respond with an HTTP 204 No Content status code. A captive portal, however, will return content (otherwise it would be useless) and therefore never answer with a 204 status code. Most likely, it will use a 307 Temporary Redirect to tell the browser to fetch a different URI (the URI of the captive portal login page).

The other ones use a small document with well-known content instead (e.g. Apple's simply contains the word "Success").

The hijacking detection doesn't have to be performed by the browser, actually. Most modern devices will automatically run this "captive portal hijacking detection" automatically whenever they connect to an open WiFi and automatically pop up a dialog allowing you to go to the captive portal, without you having to explicitly open up your browser and visit some web page.

The reason for this is that in the modern Internet world, a browser is not necessarily the first app a user would be trying to use the Internet with. It could be the Facebook client, WhatsApp, or email client, for example.

Note that I used the term "hijacking" deliberately. These techniques are actually basically performing a Man-in-the-Middle attack. (The difference being that a "real" attacker would try to redirect you to a website that looks exactly like the one you wanted to visit and trick you into entering your username and password on the fake website.) Hence, these techniques only work as long as you are trying to visit an "insecure" website, i.e. a website that does not use SSL/TLS (i.e. no https://), does not use HTTP Strict Transport Security (HSTS), and the likes.

This is starting to become a problem, because more and more websites are only accessible through HTTPS (TLS). Modern browsers remember whether a website supports HTTPS and will use the HTTPS version, regardless of what you enter in the URI bar. Techniques such as HSTS ensure that browsers will always use the encrypted version of a website. Newer versions of the HTTP protocol such as HTTP/2 and HTTP/3 don't strictly require encryption, but all major browser vendors have decided to only implement them for HTTPS connections.

If you try to visit Facebook or SuperUser, for example, your browser will automatically use an encrypted, authenticated connection, and when the captive portal tries to redirect the browser to the login page, the browser will detect this manipulation and throw an error. Normally, this is exactly what you want, but in this case, it will prevent you from logging into the captive portal and thus from using the Internet.

If you ever run into problems where you are connected to the WiFi, but your apps show errors or load indefinitely, the reason is almost certainly that for some reason you are not logged into the captive portal. Maybe you didn't see the notification popup, maybe the detection failed, there can be many reasons.

In this case, you can solve the problem by visiting a website that you know is "insecure", i.e. doesn't use HSTS, SSL/TLS, or HTTP/2 (the standard specifies both HTTP and HTTPS, but browser vendors have decided that they will support only HTTPS for HTTP/2 going forward). The above-mentioned URIs should do the trick, but there is actually a website which some nice people have put up that serves exactly this purpose, and whose URI is easy to memorize: http://neverssl.com/.

NeverSSL does exactly what its name suggests: it is simply a completely useless website whose sole purpose is to never use SSL/TLS, HSTS, HTTP/2, QUIC or anything other than un-encrypted, un-authenticated, insecure, plain HTTP/1.1, so that the captive portal can intercept the request and redirect to its login page.

  • 6
    @RuiFRibeiro: there usually is a DNS hijacking being performed by captive portals, with all queries returning the captive portal IP address until passed. Note that you using doesn't protect you from a MITM that goes after UDP packets to port 53.
    – Ángel
    Commented Oct 7, 2019 at 1:00
  • 1
    On all devices I have, the captive portal is opened using, I guess, a "browser view" rather than the regular browser. I some cases where I have to enter login details to get access, I would prefer to use a regular browser that remembers passwords but, especially on phones, it is hard or impossible to copy the URL (or even see the full address) for use in a regular browser. Is there a way around this?
    – d-b
    Commented Oct 7, 2019 at 7:17
  • 1
    What is ICMP Redirect? I’ve never heard about that before in the context of a captive portal.
    – jornane
    Commented Oct 7, 2019 at 8:19
  • 2
    For a long time, I have estabilished a practice for myself to enter http://www.example.com after connecting to public wifi exactly because the Captive portal wouldn't work for HTTPS pages, like superuser.com. Commented Oct 7, 2019 at 10:24
  • 6
    @TomášZato: NeverSSL employs another neat trick that example.com doesn't: it uses ECMAScript to redirect to a randomly generated subdomain, that way, when you see the website in your browser, you know that web surfing is working, as it is highly unlikely to be a cached copy. Commented Oct 7, 2019 at 10:54

The feature is called Captive Portal Detection. Firefox will try to fetch http://detectportal.firefox.com/success.txt and if record the answer. If there's a redirect, it knows that there is a login page and will pop up the warning.

A quick writeup that explains the feature and shows how to disable it if needed is at http://support.moonpoint.com/network/web/browser/firefox/detect_portal/

  • 10
    Android does this by default as well, not just in the system webview but with its own service
    – cat
    Commented Oct 5, 2019 at 22:07
  • 24
    Apple uses captive.apple.com. The fact that all these are non-https sites is important.
    – Tim
    Commented Oct 6, 2019 at 0:03
  • 5
    Note that the explanation given to disable it will not turn off the feature on the router which is where it's managed. It just turns off Firefox's automatic detection but if they then go to any Internet page they will just be redirected to that portal login again. (The page also doesn't really explain what it is or how it works, which was a major part of OP's question.) Commented Oct 6, 2019 at 1:16
  • Redirects are a part of the equation, however might not be enough to activate the captive page, especially in Apple devices. There is something else. Commented Oct 6, 2019 at 7:36

Besides the very complete @JörgWMittag answer, captive portals also implement the WISPr protocol, defined by the Wifi Alliance, which should be understood by any client/router/AP implementing captive portals.

It is present in the captive portals implementation of major vendors, namely Cisco and Aruba, and also in the captive portal implementation in PfSense.

Firefox does too understand it, and WISPr in itself triggers the famous automatic Apple authentication restricted browser (CNA). (afair from my tests, redirects alone are not enough to trigger those windows, at least in Apple equipments)

The actual WISPr is present in the main page the client is redirected to as HTML tags, and defines URLs for the login, logout, and abort pages. It also defines status codes for the pages generated by those URLs.

As in:

<!-- WISPr message -->^M
<span class="displayNone"><!--<?xml version="1.0" encoding="UTF-8"?>^M
<WISPAccessGatewayParam xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.acmewisp.com/WISPAccessGatewayParam.xsd">^M

For more details (and clues) about how to implement/deal with captive pages, see my other answers:

Getting WISPr tags from a FON authentication portal

Implementing a Captive portal using Apache

Captive portal detection, popup implementation?


Disabling CNA in MacOS

How use a captive portal when in text mode?

PS Interestingly enough, some CPEs/cable modems are (ab)using WISPr to show to customers, in their browsers, error messages in the absence of an Internet connection/when booting.

  • 1
    Thanks, I was about to add a section about WISPr, you saved me the work! Commented Oct 6, 2019 at 8:57
  • 1
    @JörgWMittag Well, thanks too, you saved me a lengthy introduction to the theme. Commented Oct 6, 2019 at 9:02
  • 4
    To any editor: ^M are part of the WISPr message, please do not edit them out. Commented Oct 6, 2019 at 9:08
  • @RuiFRibeiro The ^M is a visualization of the line-endings the WISPr payload. They're not necessary for it to function.
    – Tom Lint
    Commented Oct 7, 2019 at 13:28
  • @TomLint I would swear when I implemented this in a FreeBSD captive portal, that they were and had to put them there, the tests without them did not work afair. It was a bit while ago...Will try to find some time to test it out. Commented Oct 7, 2019 at 13:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .