Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Apple users does not get the popup

    Scheduled Pinned Locked Moved Captive Portal
    8 Posts 6 Posters 2.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      decibel83
      last edited by

      Hi,
      I configured a Captive Portal on pfSense 2.2.4 and users are able to surf the web authenticating themselves through the Captive Portal.
      But Apple users are not getting the popup when they connect to the Wi-Fi network.
      Connecting to http://www.apple.com/library/test/success.html redirects to the Captive Portal.
      I searched for some solutions but I didn't solve my problem.
      Could you help me please?
      Thank you very much!
      Bye

      1 Reply Last reply Reply Quote 0
      • M
        muswellhillbilly
        last edited by

        From the sound of it you need to check the security settings on your Mac users' browsers. They might be blocking pop-ups.

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by

          Whatever is happening it is completely up to the client.

          In my experience Apple devices are pretty reliable in automatically checking for access and bringing up a mini browser on the portal page.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 0
          • J
            joefreezy
            last edited by

            I've had tons of problem with Apple devices not liking the CP.  Most of this has to do with the redirect to the CP as far as i've been able to understand.  Lots of older iOS versions are very protective and don't like the methods of the redirects as they seem to view them as a malicious action.  I usually pass the MAC of most of these devices and they function well.  iOS 9.0 devices seem to be doing better than their predecessors as far as i've noticed.  iPhones seems to have problems about 5-10% of the time and iPad around 20%.  Usually this is pop-up blockers and the Safari browser in general.  If they use Chrome (or Firefox now thank God) they seem to get the portal page to open without errors.  Like most of the previous posters have stated, this is 99% of the time a client problem.

            1 Reply Last reply Reply Quote 0
            • GertjanG
              Gertjan
              last edited by

              @joefreezy:

              I've had tons of problem with Apple devices not liking the CP.  Most of this has to do with the redirect to the CP as far as i've been able to understand.  Lots of older iOS versions are very protective and don't like the methods of the redirects as they seem to view them as a malicious action.  I usually pass the MAC of most of these devices and they function well.  iOS 9.0 devices seem to be doing better than their predecessors as far as i've noticed.  iPhones seems to have problems about 5-10% of the time and iPad around 20%.  Usually this is pop-up blockers and the Safari browser in general.  If they use Chrome (or Firefox now thank God) they seem to get the portal page to open without errors.  Like most of the previous posters have stated, this is 99% of the time a client problem.

              Strange.
              When I first tested the Captive Portal (pfSense), Apple devices handled the 'link up with the Wifi Captive Portal of pfSense' quiet well. This was back in the good old iOS 4 or 6 days (2007 !?!). It worked good since.
              On of the good (and also bad) things is that Apple device user can't "mess up" the way the connection is build.

              When a Apple device user (iPhone, iPad) accepts a (new) Wifi connection, the radio link is setup first.
              Then, a DHCP request is send, and IP/Gateway/DNS (among others) are retrieved.
              Then, the iOS magic kick in. It choses among a couple of hundreds of internally stored URL one URL, and makes a basic 'http' (non-https) request.
              This page request should result in 'Ok' or 'Connect'. If so, no more questions, your are connected. This is typical when your are 'at home' (no captive portal from pfSEnse).
              Without this answer, iOS presumes a captive portal is present (it knows that a direct Internet connection isn't there yet), and opens up a special, stripped down browser (NOT your installed navigator App like Firefox, or the build in navigator Safari !!) and makes a page request.
              This will show captive portal login page.
              You can login.

              I'm using an iPad and iPhone myself, so I tested a lot with these devices. Never hand any troubles (except me fckng up when building my own login page ;) ).
              From what I can see, even Android ans M$ devices are login in just fine.

              All works fine and without surprises, as long as the user didn't activate or use some restriction on his own device.

              Important : I always use the latest pfSense with very few 'personal' settings. Most settings are 'by default'.
              I did add a certificate for https support on the captive portal - and although it is more complicated to setup, I tend to say that captive portal authentication works even better.
              https://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html
              I'm using the Local User Manager.

              Btw: this can matter : I'm using Cisco/Linksys AP's, flashed with the DD-WRT firmware. They are all running in "simple AP mode" (for example, local DHCP server turned off, etc), Wifi-Isolation activated - and all AP's BLOCK inter-user (client) communication (users can form their own "LAN" on my pfSense LAN segment).

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                My experiences exactly.

                This page request should result in 'Ok' or 'Connect'. If so, no more questions, your are connected. This is typical when your are 'at home' (no captive portal from pfSEnse).

                The test pages return 'Success' when a portal is not present.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • The Computer GuyT
                  The Computer Guy
                  last edited by

                  I tend to put www.apple.com in as a host name passthrough. Works fine then.

                  1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan
                    last edited by

                    @The:

                    I tend to put www.apple.com in as a host name passthrough. Works fine then.

                    This could be one of the ten or hundred different URL's hard-coded in iOS.
                    When you have the change the random "www.apple.com" is used, the iOS thinks it is connected to the net …. and the pfSense Captive portal will still block the portal client to visit any other site

                    Just wire-shark your portal connection, you probably will not even find a "www.apple.com" (DNS) request .... so why allowing it ?

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.