Good day team, I have the same problem as the above, I am not good with Mikrotik devices or configuration, and not sure how to resolve the above issue, I will appreciate your help, my client is not in a good mood since the apple devices cannot be directed to the landing page.
We have this problem ONLY on iOS 14.Our client has an iOS 13 and all Android devices work perfectly. There was also an update patch iOS 14.1. It was listed as an issue connecting to Unifi, but did not fix the issue with the page loading. Any iOS 14 device simply gets a blank screen. Any help would be appreciated. Thank you.
Do you have anything in the walled garden menu?
Yes we do. Everything has 0 hits.
Everything has been disabled. Same problem, blank page shows up. Kindly advise, and thanks in advance!
Hey Normis, do you have any other suggestions? Thank you.
Export the full config of the device with hide-sensitive.
OK, do I email to support@mikrotik.com?
Thank you.
Post it here, if you want to get feedback.
I appreciate that. However the client does not want their config posted. We have setup a ton of Hotspot Managers, I was just hoping someone else knew of the existing iOS14 issues.
Thanks.
Hi,
There are no “existing iOS14 issues”. I’ve tested iOS 14 clients and have zero issues with them seeing the hotspot login page. It always comes up automatically.
Hello, the customer also has access to their router, so maybe there is something wrong with the config. This problem ONLY happens with iOS 14 clients. Everything else is fine. Funny thing, we only have the one customer with this issue. Thanks.
Hi,
As normis explained, the devices try to fetch the captive portal detection page (in this case, captive.apple.com) on connection. If they get the expected result, they know that they can get online, otherwise they know they are behind a captive portal and trigger the detection of the captive portal page. So the only way this can happen is either with walled garden settings or ip firewall settings that allow customers access to outside resources without having to go through the captive portal. Those outside resources need not include the actual captive.apple.com site, but can instead include sites that are served from the same IP address as captive.apple.com, which can be a large number of sites potentially if it is served from a CDN. The result is that you have to be very very careful whenever you give unauthenticated users access to anything outside as you can easily break captive portal detection in the event that something is allowing traffic from the hotspot client to that IP prior to authentication.
iOS 14 also has a new feature where you can tell iOS that it is behind a captive portal via DHCPv4 option 114:
https://developer.apple.com/news/?id=q78sq5rv
Please note that you shouldn’t have to use that option to correct this issue, your issue is certainly caused by allowing unauthenticated hotspot users access to some outside resource, and access to that outside resource is making the device think it isn’t actually behind a captive portal and it doesn’t show the login page as a result.
Awesome! Thanks for your help, I really appreciate the information.
We just setup a hotspot on 6.47.10 and Windows, iOS and Android clients all detect that they’re behind a captive portal and immediately show a popup/login screen for authentication with the hotspot. However, tested it with a Macbook running Big Sur and no CNA was shown. If I bring up a fresh Chrome browser, I get the portal login screen. However, if Safari is already running and I try to reload a previously loaded site in a tab, it just spins and then fails the load the page (no login screen is offered).
The walled garden is empty and captive.apple.com is not reachable (which is expected and should result in the CNA being shown). Should Big Sur and the hotspot reliably show the CNA login?
Isolated the problem a little. OS X isn’t able to resolve the hostname of our hotspot. Windows/Android/iOS resolve it.
The format of the hostname I’m using is
routername.wifi
nslookup on Windows reports that it’s a non-authoritative answer coming from the router. Are non-authoritative answers a problem for OS X?
could be Apple bug/feature, as per this post here:
http://forum.mikrotik.com/t/mdns-repeater-feature/148334/48
Interesting. Thanks for the pointer to that discussion.
From reading that thread and the web on mDNS, isn’t the Apple Bonjour (mDNS) only search limited to .local? If so, shouldn’t my hostname
router.wifi
be exempt from that bug/feature? Or are they doing this for multiple domain suffixes and not just .local?
The DNS error was user error on my part. The iMac had an ethernet cable plugged in and chose not to check the Mikrotik to help resolve the router DNS address. I unplugged it and the CNA popped up (but it was blank). Also, connected a Macbook and it didn’t even show the CNA popup. Both were able to resolve/ping the router. I then noticed that all https requests weren’t being redirected to the portal in browsers but http requests were being redirected. So it appears like this issue can be traced back to some failure intercepting and redirecting https requests.
Checked Windows and it also fails to redirect https requests (but that doesn’t matter as much since there’s an immediate login browser window shown).
Edit: Found the instructions to enable https redirection.