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


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy