Problem:Apple CNA takes around 1-2 minutes to change the cancel button to Done after passing successfully captive portal authentication.
Diagnostics:When an iOS device connects to an open SSID, it automatically tries to establish a http/https session with 'captive.apple.com'.
When captive portal is configured for the SSID, traffic to port 80 & 443 would be hijacked by the controller and will be redirected to the captive portal landing page.
Since traffic to captive.apple.com is redirected, we see the CNA popup displaying the captive portal page.
Once the device passes successfully captive portal authentication/ Acknowledgement, the cancel button on the top right changes to Done.
On clicking Done, the client device would be connected to the wireless and would have access to the network.
In some case, we might see issues with cancel button never changes to Done or taking a long time to change.
Below are few reasons which might cause this behavior:
- Post auth role denying access to 'captive.apple.com'.
- Routing not enabled between Client subnet and IP CP redirect address.
- Post auth role denying access to controller "IP CP-redirect address" when using internal captive portal and 'webserver IP" when using external captive portal.
SolutionThe cancel button will change to Done on successful communication with the captive.apple.com. If the device is not able reach the apple server, the done button will not appear.
- Post auth role denying access to 'captive.apple.com'.
During the captive portal process, the iOS devices continuously tries to communicate with captive.apple.com.
In the pre-auth role, their would be never a successful connection between the Apple server and client devices due to the ACL's in place.
On successful authentication, the client falls into the post auth role, where they have access to get to the internet.
We need to make sure the client has reachability to the apple server in the post auth role.
- Post auth role denying access to controller "IP CP-redirect address" when using internal captive portal and 'webserver IP" when using external captive portal / Routing not enabled between Client subnet and IP CP redirect address
In the pre-auth role, ACL's are configured to DST NAT all HTTP & HTTPS traffic to port 8080/8081 of the controller. The webserver on the controller listing in those ports would redirect the client to the captive portal page(Internal/External).
user any svc-http dst-nat 8080
user any svc-https dst-nat 8081
On receiving the page the client accepts the terms and conditions / submits the user credentials. An auth request would be sent to the controller also at the same time the client device tries to communicate with captive.apple.com.
Since both of these sessions are simultaneous, the traffic to apple server might hit the pre-auth role and authentication would be still in phase.
On hitting this scenario, the controller would again send a 302 redirect with captive portal URL.
(Note: This is a background task on the client device. No additional popup will be seen nor the page will refresh/reload. This communication is used to check the connection with apple server and to validate the completion of the captive portal process)
Since authentication happens in seconds, the client will be moved to the post auth role where it still continues with the redirection which happened for session to apple server.
Once the background redirect is complete, the client will again try to initiate a session with apple server which should be allowed in the Post auth role. On successful connection, the Cancel button will change to Done.
If the post auth role has ACL's to deny access access to the captive portal webserver (external CP) / ip cp redirect address (internal CP), the client would be stuck at loading the redirect page.
The client would continuously try to get to the captive portal page where it takes around 1 - 2 min to complete the retransmission and initiate a new session to apple server.
