Captive portal only works on mobile or Chromebook not yet logged in

[MathiasMa]

Hello

I have set-up a Captive Portal and checked the troubleshooting page.
I have set-up these rules, I think the first one isn't really necesary. But it won't hurt either.

The point is, it works: On my Android device, the CP is shown and I can connect. When I do the same on my Chromebook (when on the login page), it also works.

But when I try it on a Windows device, or on the Chromebook when logged it, the browser is launched and the corresponding test url tries to load (e.g. on Chromebook: http://connectivitycheck.gstatic.com/generate_204) but never loads. Odd, because I have a rule that should pass this traffic, and I guess the same page is loaded in the background on the Android device and the Chromebook pre login?

Thanks for any guidance or tips on how to solve this!

[MathiasMa]

Edit: I noticed I forgot to allow TCP traffic in the DNS rule, so I changed that, but it doesn't make a difference.
Edit2: Just for the sake of it, I added an allow all rule, but no difference. The connectiviycheck.gstatic.com/generate_204 page is not loading, so no redirect if performed.

[Gertjan]

@MathiasMa

What if : Windows devices do also a ping == protocol "ICMP" to check for network connectivity ?
You don't allow 'ping' ^^

Rule 1 : not needed. And keep in mind that a UDP web server (port) '80' hasn't been invented yet.

When you start with the captive portal, use this 'one and only' rule to test :

Afterwards, if you want, you can add more restrictive rules. As soon as stuff start to break, you'll know where the issue is ^^

On the windows device, as soon as you are connected == received a DHCP lease, you should be able to do a

nslookup gstatic.com

or a

nslookup connectivitycheck.gstatic.com

This should return a :

C:\Users\Gauche>nslookup connectivitycheck.gstatic.com
........
Addresses:  2a00:1450:4007:81a::2003
          142.250.201.163

As soon as the PC gets this IP resolved from the 'test' URL, it will connect to it, using port TCP 80.
This (a typical http browser) request and will get intercepted by the portal firewall, and redirected to the web server running on pfSense that shows a "login page".

Most important rule : pfSense should do the DNS resolving for the portal clients.
This is normally always the case, as clients have to use the mandatory DHCP to get access to the portal network.

[stompro]

Hello, This is a slightly old topic, but I'm running into something similar.

But I suspect is is related to chromebooks locked down with the GoGuardian extension.

It seems like the GoGuardian extension might be trying to check the captive portal page to see if it is in their filter... but since the captive portal blocks the https connection it tries to make, the extension doesn't allow the page to render.

In my case there must be a 5 minute timeout for goguardian to check a url because the captive portal page will load after about 5 minutes.

Works fine if you connect to the captive portal page from the chromeos logon page, but stops working when logged into an account that is managed by an org that has goguardian setup. Log into a normal google account and it works fine again.

The device I'm testing with also has google developer mode disable so that makes it harder to test and I have no control over those settings.

[Gertjan]

@stompro said in Captive portal only works on mobile or Chromebook not yet logged in:

It seems like the GoGuardian extension might be trying to check the captive portal page to see if it is in their filter... but since the captive portal blocks the https connection it tries to make, the extension doesn't allow the page to render.

In my case there must be a 5 minute timeout for goguardian to check a url because the captive portal page will load after about 5 minutes.

It looks like that application is created for a world where there are no captive portals.
Ok, why not.
Use the app, and then don't bring your device to public networks, McDonald's, plains, trains, etc etc etc. Just use it 'at home' and you'll be fine

On the other hand, every OS created since ... not sure, 2012 ? is captive portal aware.
Connect any phone, pad, PC, whatever over a cable ( ! ) or wifi connection and you see that right after DHCP did it's work, the PC got a lease and knows in what network it is, it sends out a http (not https !) request.

Example : Apple device use this request : http://captive.apple.com/hotspot-detect.html - click on it and you'll see what happens.
If the reply on the http request wasn't 'Success', then the device knows it hasn't a direct Internet connection and a portal is presumed.
A browser will open, the same request will be repeated in that browser and the actual answer back will be ... the portal login page.

Using an app that does 'DNS' requests from the start and if it can't do them then blocks/locks up is .... then you can't use that if there is a portal.

On the other hand, some devices are not meant to be used behind a captive portal. A portal is there for the 'public' that wants to use an Internet connection, and don't want to use their own 3G/4G/5G device capabilities (or because it doesn't have a sim card, etc).