A captive portal is, for example, a public WiFi network name (ESS) which leads to an Internet connection which redirects all traffic to a specific login pages, until you log in the system.
Typical applications are: hotel, airport, park free wifi.
Captive portals disadvantages are:
- messing up with networking transparency through redirecting DNS and HTTP
- all users can usually see your unencrypted traffic and possibly redirect your login, too
WPA/RADIUS based authentication is much better but is often seen as more complicated for the end-user compared to captive portals, and require pre-arranged authentification. There is work in progress for standardizing the captive portal protocols.
How the captive portal's login is activated
Mobile phones (Android, iOS) will detect that the captive portal exists and automatically open a browser for the login.
This is not implemented in Debian GNU/Linux (to my knowledge). So, just after connecting to the wireless network, you should not immediately use e-mail, SSH or other application software requiring a full Internet connection, but you should launch a web browser and access the captive portal login page. However that login page's URL is usually unknown. In general, it is sufficient to start your Web browser and enter any non HTTPS URL, which will be redirected to the HTTP or HTTPS captive portal login page. You can also enter any IP address, in general.
What can fail on Debian GNU/Linux with recent Firefox browsers
With recent browsers such as Firefox, which support the HSTS local cache and will prevent any HTTP access if the site is to be accessed by HTTPS, a bug might happen: you type "google.com" in the web browser URL bar, and you get a security error. The work-around is to use any HTTP URL which is guaranteed to not use HSTS nor DNSSEC, or an IP address (such as the one from the default route as seen in netstat -rn | grep default)