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.