http://connectivitycheck.gstatic.com/generate_204 error with https login
-
Hi all.
I just configured pfsense with captive portal. If i enable https login i have a problem with mobile phones. These device stuck connection on http://connectivitycheck.gstatic.com/generate_204 and not working. I don't have a problem with laptop. If i disable https login work fine.
Thanks. -
Hi,
"https login" : where did the certificate came from ? Self signed ? From Letsencrypt (== acme package) ?
=> Self signed certs should not be used on a captive portal, except if you want to guide every user every time you're whole live - and you probably wont. Use "real" certs, or stay away from "https" login mode.Your are mentioning "mobile phones" but can you be more specific ? iOS (iPad - Iphone , etc ) ? Anfroid ? (and so, which age / generation, etc) ?
All recent devices, even the Micorosft OS's like "10" (and 8 and 7) and "Server", etc will throw out a "hidden http://..." (like your http://connectivitycheck.gstatic.com/) request to see if a known answer comes back. You can see for yourself : http://captive.apple.com/hotspot-detect.html : it return a simple "Success" word. This URL is used by Apple devices.
If the reply is any different as "Success" then the device (the OS, actually) assumes a portal, and launches abrowser for you, so the end user ( == you) can interact what might be a portal.I presume that your device (== OS) throws out " http://connectivitycheck.gstatic.com/generate_204 " to detect the presence of a portal, but something didn't worked out well.
I've some good - and bad news : this isn't probably not a pfSense problem ^^ (try an iPhone, it will work right away ^^). -
Hi. I imported a public wild card in pfsense and i created in dns forwarder a dns override for https hostname. This host name is pfsense address.
-
So, when the portal login page comes up, you have the "green lock", right ?
edit : Btw : I checked my captive portal (pfsense) log files.
I found many, many URL like " http://connectivitycheck.android.com/generate_204 " because many of my users - portal visitors - use android devices (or what they are actually - I can't tell). It works for me ... sorry, them.You use the derfault built in login page ? If not, activate it to test drive.
-
On laptop i view verified certificate but on mobile phone i receive a warning.
-
Humm.
I tend to say : the mobile phone does not "contain" the correct list with trusted certificates. This will provoke a big "https == No-go" in this case.Options :
Install / use a corticate that your mobile phone trusts.
Or :
If it can be done : upgrade your mobile phone (OS's, when upgrading, also upgrade their trusted certs lists - these change constanly).
Or :
Do not use your mobile phone on your portal. -
I insert all crl server and connectivitycheck.android.com server in allowed host on captive portal configuration. Now work fine with https login and mobile phone.
Thanks.
-
Adding "connectivitycheck.android.com" to the allowed host list doesn't seem a good idea to me.
This URL is probably member of the http challenge page that the OS is using to check if a portal is present.
When white listing this URL (an IP) the OS will conclude no portal is present, and a direct connection to the net is available. The user will get directed the the captive portal login page when another http request to somewhere else passes by.See also https://android.stackexchange.com/questions/123129/how-does-wifi-in-android-detect-if-the-device-has-to-sign-in-or-not
