CP Redirect Problem



  • Hi,
    I have installed a custom captive portal in a pfsense but I am having some problems.
    Usually, when an user connects, the captive portal automatically shows after connecting, and the user is logged in without problems.
    However, there are some cases where the captive portal will not show at all until the user tries to access to a HTTP website. The captive portal does not show after connecting, and if the user tries to access a HTTPS website (aka most of the Internet nowadays), the connection is blocked and nothing happens.

    Is there any way to prevent this from happening, or to redirect the user to the captive portal page even if he is trying to access a HTTPS website?



  • Sadly, there is no way you can redirect to captive portal after an HTTPS request by the client ...
    Only way I can think of, you trust the clients' browsers an internal HTTPS certificate generated by Squid, by enabling HTTPS intercepting mode ... but YOU DON'T WANT THAT



  • @4rdorin said in CP Redirect Problem:

    However, there are some cases where the captive portal will not show at all until the user tries to access to a HTTP website. The captive portal does not show after connecting,

    It's somewhat the other way around.
    The captive portal will always work when the right conditions are met. That is :
    There is no Ethernet connection (wire or wifi) with the captive's portal network.
    The connection comes up (the user plugs in the cable or selects the wifi SSID that represents the captive portal).
    The OS in the device will always 'poll' the connection, right after it receives an IP/DNS/Gateway by DHCP running on pfSense. It does so using a OS-specific "http://" URL. The result - a page loaded, should contain a OS-specific result, of a simple text like "Success".
    Again : the OS checks if a portal is present. If so, the returned page will not be the expected word "Success", but the captive portal's login page, so it will launch a browser, with a same OS-specific "http://". The portal intercepts this request (again), and shows the login page to the user.
    And all is well.

    If you see a different behaviour, you have to check two things :
    Your device is very ancient. Update it - or assist it when accessing the portal.
    Or

    @4rdorin said in CP Redirect Problem:

    I have installed a custom captive portal

    you mean a self-made/written login page ?
    Remove it. Switch back to the default page. Problem solved.

    @zoro_2009 said in CP Redirect Problem:

    Sadly, there is no way you can redirect to captive portal after an HTTPS request by the client ...

    It's actually a good thing that https can't be redirected.
    And there is no need to redirect https ;)



  • Hi,
    Thanks for your answers!

    After investigating the issue, I found out something interesting: this problem only happens in Huawei and Xiaomi devices: the device "polls" the connection, it reveives IP/DNS/Gateway by DHCP, but it doesn't show the captive portal.
    The captive portal is working perfectly in any other device.



  • @4rdorin said in CP Redirect Problem:

    the device "polls" the connection

    Polls ? It's doing what ?
    Any modern OS, after LINKUP and receiving an IP/Gateway/DNS throws out a "known" http (not https) request.
    Example : Apple devices use this one http://captive.apple.com/hotspot-detect.html
    There should be a known answer back, it's the one-word "Success" - check it out yourself by clicking on the link.

    If the answer is anything else, a browser is fired up, using again the same URL.
    This time the answer is shown in the browser. It will be the captive portal logging page.

    To make a long story short : captive portal is actually an OS thing not pfSense ;)



  • @Gertjan
    I sadly don't have a Huawei or a Xiaomi device here to test, but I tried to see what is exactly the behavior of an Android that is working correctly and the behavior is what you said: it sends a HTTP request to connectivitycheck.gstatic.com/generate_204 (that is what i meant with "polls") and then the captive portal shows and everything works perfectly.

    However this is not the case in a lot of Huawei or Xiaomi devices, and I don't know what could be causing this behavior.
    I don't know if anyone else has had some captive portal problems with Xiami/Huawei devices or if I am doing anything wrong.



  • @4rdorin said in CP Redirect Problem:

    However this is not the case in a lot of Huawei or Xiaomi devices, and I don't know what could be causing this behavior.
    I don't know if anyone else has had some captive portal problems with Xiami/Huawei devices or if I am doing anything wrong.

    Well ... devices - OS's that is - that do not support captive portals will have to deal with not happy clients. That's their problem.
    It's not a 'pfSense captive portal' problem.

    I'm running the captive portal for a hotel, and these days it's very rare to have a client say : "doesn't work". If so, I take my device and show him it does. The client will ask : "what to do so it works for me ?" I'll say "Next time you choose a phone, add 'captive portal recognition' to your list - or call your support." Problem solved ^^


  • Rebel Alliance

    @4rdorin Are you talking about Xiaomi/Huawei phones that are coming from mainland china?

    Because of the chinese firewall, chinese phones (the ones without play store nor Google services) cannot use the captive portal detection system (
    connectivitycheck.gstatic.com is blocked in china)
    Because of that, Xiaomi and Huawei disabled the captive portal check on some phones and used other URLs on others ( http://connect.rom.miui.com/generate_204 , http://www.qualcomm.cn/generate_204 ).

    It could be the cause of your problems. There is two settings on Android (captive_portal_detection_enabled , captive_portal_mode) that enable/disable the check and give the URL used for test. Maybe you sould check these settings when an user complains?


Log in to reply