Captive Portal Strategies

Technical Support for Routers
1

I’ve had problems with captive portals, particularly with my Chromebooks (looking at you Delta), and I see others have had, so I thought I would put down a few notes in case it would be helpful.

  1. Some captive portals operate through a form of DNS poisoning. When you make a connection to a wifi router, you get an IP and a DNS server. Mobile devices, most modern OSs and browsers will immediately run a captive portal detection test by issuing a DNS request through port 80 for some identified server (Microsoft uses this, for example, with Windows to test connectivity every few seconds). The DNS server intercepts this request, checks the MAC (and sometimes the IP) against a whitelist file, and if it is not there responds with the address of the captive portal (which may be, for example, on the wifi router itself at a different port). The captive portal then handles authentication. The captive portal blocks any access until the device goes into the white list.
    2. So the first thing is you cannot, I think, specify a custom DNS server, because the DNS request goes nowhere without triggering the captive portal.–wrong
  2. The reason trying a site like http://cnn.com triggers the captive portal is because (a) it goes out as http rather than https, which is to say, over port 80 rather than 443 or 8080 (b) it isn’t in your browser cache, triggering the DNS lookup. Until you are in the whitelist, secure site lookups will fail silently because they do not allow redirects. If you have any tabs in a browser open, close them and restart the browser. Also, even if you try the http version of a site like nyt.com, the OS may remember it uses only https and go out over 8080 instead. That’s why neverssl.com might work. Also, a made up site that doesn’t exist might work.
  3. The reason making a connection with a smartphone and then spoofing its MAC address might work is because the MAC address is in the whitelist. It may be necessary to also set the static IP address the phone got.
  4. Captive portals can flush the white list at intervals. One can look at the nodogsplash manual for examples. This is why you may have to trigger the captive portal again after, say 24 hours.
  5. The dns rebind protection may be a problem because the first port 80 request returns one address, and after authentication returns a different address. If you have triggered the portal by going to a site you never visit, this may be a problem, but if it is triggered by the device going to its predefined connectivity address it will think it is being hijacked and shut down.
  6. A VPN client can also present a problem. If you set your travel router to automatically connect to a VPN site, it will be sending the DNS request down the tunnel, so it isn’t triggering the captive portal. But the tunnel isn’t established yet, so nothing happens. You have to disable the VPN client, clear the captive portal, and then re-establish the VPN client. After that you are good to go until your white list expires. This might be something the GL-Inet interface could do, but I think maybe only a warning on the client page would be desirable.
  7. For some devices, a travel router may be the only way to clear a captive portal without front desk intervention (to get in the whitelist). Nintendos, echos, etc.

Not sure all of the above is correct but it might help.

3 Likes
2

Another tip I might want to add:
Use a mobile/other device to find the url of the captive portal. That way you can sometimes go to the captive portal manually even when due to settings of the router the captive portal will not present itself.

3

As long as your have “DNS Rebind protection” disabled, setting a custom dns server does not matter.

4

yeah “DNS Rebind protection” disabled but still can’t connect to captive portal, gl team need to improve this experience.

5

It’s a hard time for captive portals.

DNSSec/DoH is getting more common and common, which will prevents captive portals from allowing them to change DNS responses.

Many and many sites have SSL with “HTTP Strict Transport Security” enabled. This makes it impossible to intercept requests to such sites to redirect to a captive portal. That’s why sites such as “http://neverssl.com” exist.

Also VPNs are more frequently used, which can also screw up captive portals.

Given all that and the issue that no captive portal is the same, makes it really hard for devs to do anything with it. That only thing I can think that they could do, is warn users if their current settings would cause issues with captive portals and possible make a wizard to temporary adjust these settings.

2 Likes