Captive Portal with https enabled does not work with Apple CNA (wifi assistant)



  • Notice after testing captive portal on 2.3.4_1 with https enabled and valid cert/CN that Apple devices do not pop up with the CNA splash page as they normally do with http enabled. Apple devices will show wifi icon as if authenticated and connected to internet, but will only redirect to portal if you open Safari and browse to an http URL.  Eventually the iOS device will simply try to associate with last known good WLAN.  Tried various captive portal and DNS resolver/forwarder tweaks with no luck.

    Android does not seem to have this issue.  The "Sign into (SSID)" notification will always appear on modern Android devices with either https or http enabled in captive portal.

    Would assume this has something to do with DNS queries resolving for un-authenticated iOS captive portal clients, possibly.


  • Netgate

    Completely up to the client what happens in that case.



  • @sluggo:

    Notice after testing captive portal on 2.3.4_1 with https enabled and valid cert/CN that Apple devices do not pop up with the CNA splash page as they normally do with http enabled. Apple devices will show wifi icon as if authenticated and connected to internet, but will only redirect to portal if you open Safari and browse to an http URL.  Eventually the iOS device will simply try to associate with last known good WLAN.  Tried various captive portal and DNS resolver/forwarder tweaks with no luck.

    Android does not seem to have this issue.  The "Sign into (SSID)" notification will always appear on modern Android devices with either https or http enabled in captive portal.

    Would assume this has something to do with DNS queries resolving for un-authenticated iOS captive portal clients, possibly.

    What iOS version ?

    I'm using the latest pfSense version (as you) and the latest iOS version 10.3.3. (test on an iPhone 5S and 7).

    When I chose a Wifi radio network that is attached to pfSense with Captive portal activated, I still see that the "CNA" use by my iPhone is doing this :

    
    08-24-2017	12:50:11	Local5.Info	192.168.1.1	Aug 24 12:50:15 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [24/Aug/2017:12:50:15 +0200] "POST /index.php?zone=cpzone1 HTTP/1.1" 200 634 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Mobile/14G60"
    
    08-24-2017	12:50:11	Local5.Info	192.168.1.1	Aug 24 12:50:15 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [24/Aug/2017:12:50:15 +0200] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-346.50.1 wispr"
    
    08-24-2017	12:50:11	Local5.Info	192.168.1.1	Aug 24 12:50:15 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [24/Aug/2017:12:50:15 +0200] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1552 "-" "CaptiveNetworkSupport-346.50.1 wispr"
    
    

    A simple http request to "http;//captive.apple.com/hotspot-detect.htm" as it's being doing the last several years.

    pfSense intercepts just fine, my captive portal login page pops up 2 seconds later.

    Their is another explanation : if "iDevices" did not work anymore with the pfSense Captive portal, this forum would be obliterated with posts right away ….. or, I see none.

    So, good news ! : You're wrong, it works ! Check your setup. That's the only thing that is different between your setup and mine.  ;)

    Btw : I'm using the https captive portal login, using a LetEncrypt certificate.



  • I tested with iPhone 6 iOS 10.3.3 and latest iPad with latest iOS.  Glad to see this works, then.  Just not obvious what I am doing wrong, though.

    I notice that your https enabled portal's subdomain "portal.brit-hotel-fumel.net" DNS does not resolve to an IP - maybe this indicates the misunderstanding on my part.

    Our server's WAN IP is pointed to by a subdomain using a valid wildcard certificate (CN = *.domain.com) for both GUI and portal.  I assumed PFsense host name (subdomain.domain.com) had to be a valid, internet accessible FQDN and had to be same as captive portal's "https server name" when using https portal.  Maybe the wildcard cert is the problem?

    Strange that iOS devices "think" that they have internet (as shown by WiFi icon) when they do not.  This would suggest that they are able to receive the CNA's GET request (from cached DNS?) while un-authenticated behind captive portal.



  • @sluggo:

    I notice that your https enabled portal's subdomain "portal.brit-hotel-fumel.net" DNS does not resolve to an IP - maybe this indicates the misunderstanding on my part.

    That's one of the good side effects when using certificats.
    Certificates have to have a "DNS" or host + qualified domain name - at least, those from Encrypt have.
    When visiting my portal, there can't be an IP like the 'http' access. The settings impose a "HTTPS server name" and this name must be part of the certificate.

    @sluggo:

    Our server's WAN IP is pointed to by a subdomain using a valid wildcard certificate (CN = *.domain.com) for both GUI and portal.  I assumed PFsense host name (subdomain.domain.com) had to be a valid, internet accessible FQDN and had to be same as captive portal's "https server name" when using https portal.  Maybe the wildcard cert is the problem?

    Remember : cert validation is done by the browser you use.
    I chose to use a cert for my portal for my clients  portal living on OPT1 or 192.168.2.1 and one for pfsense (192.168.1.1). Pfsense is handling the renewing

    @sluggo:

    Strange that iOS devices "think" that they have internet (as shown by WiFi icon) when they do not.  This would suggest that they are able to receive the CNA's GET request (from cached DNS?) while un-authenticated behind captive portal.

    Never have equipment think for you  ;)

    Apple devices throw out a GET "http;//captive.apple.com/hotspot-detect.htm" and this should return a "200" status code. Also known as "all is well - here is the page", and the page will be returned by the server at "apple.com". Then the device knows it has an connection- at least, using a 'random' WAN destination with the "80" port.

    You can see if your device is listed in the captive's portal firewall - which means: it can go through. See here : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
    Your device will be listed when you correctly identified yourself first. https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting is a bit technical, but very instructive.

    VERY IMPORTANT : many people break the functioning of the captive portal because DNS isn't working.
    Even when the captive portal blocks all communication, DNS should work for every device. Identified, or not.
    because, before even trying to hit "apple.com" (in this case) the "apple.com" has to be resolved to an IP. Then the GET is executed. If Apple.com isn't resolved, everything stops.
    This means that you probably should have a pass rule on the captiv's portal fGUI firewall that let DNS requests coming in - and that a DNS server is running on pfsense - the same interface. Normally, your DHCP server running on pfSense hands over the address of the DNS server your clients / visitors should use.

    Btw : the wifi icon on a iDevice doesn't mean you have a connection to the net.
    It means that there is a "radio connection" (== also called wifi connection) activated to an access point - and the iDevice obtained an IP. It doesn't mean at all that this AP gives you a connection to the net. Upstream the connection can be blocked, like a captive portal does at first.

    These explanations aren't just valid for apple device, but for all devices.