cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2620
Views
15
Helpful
4
Replies

Catalyst 9800 WLC Mobility vAnchor Web Auth with iPhones

coolbreeze
Level 1
Level 1

We are experiencing inconsistent login prompt of captive portal for web authentication for WLAN, this is with Apple iPhones only.  Android, Windows, and macOS devices do not experience this issue.  This has been seen on Apple iPhones of various models and near-up-to-date or up-to-date iOS versions.

 

Environment is: all APs are associated to Foreign Controller with two virtual Mobility Anchor peers - one of those anchors handles the network traffic for this WLAN in question with the SSID requiring web authentication.  We are currently using the default Cisco login page in the configuration, not a custom web auth bundle.

 

We see joining iPhone devices to this SSID does not always prompt the user with the login portal to authenticate to the wireless network - sometimes it will launch the prompt for login creds for authentication, but usually it does not.  We have tested using multiple models of iPhone devices, testing behavior on Android as comparison (behaves expected so isolated to iPhones).  We tested ensuring or disabling the auto-join/auto-login options in Settings app, and/or tried forgetting the SSID then try joining again, tried "Resetting All Network Settings", as well as after iPhone resets (Erase All) or iPhone reboots for testing completion sake.

 

The complete lack of presentation of the captive portal login prompt is more typical rather than the successful prompting for authentication to the user.  The logs on the Anchor WLC just show No Client Response with failure to join network by client as a result.

 

The network does not allow authentication bypass so without this prompt, the network does not function for the end user.

Any one have any ideas?  I cannot seem to find much on this issue on the new Catalyst 9800 WLC environment.  Thanks!

1 Accepted Solution

Accepted Solutions

coolbreeze
Level 1
Level 1

Ok, resolved our issue.  We are running Amsterdam 17.3.3 currently until we can upgrade to 17.3.4a firmware.  It seems there is an issue (whether official bug or not, I am not sure) that we see changes in the GUI are not taking effect in the CLI/running configuration.  I also noticed a discrepancy in the redirect for-login config in the CLI of the foreign controller vs. the anchor, when the GUI options appeared the same.  Additionally we confirmed the paramter-map option "captive portal bypass" should NOT be present in the configuration in order for correct presentation of the webauth credential prompt on Apple iOS devices, as mentioned in other posts found in the forum on here.

 

So, again, the issue seemed to stem from inconsistencies and ineffective configuration application when performed through the GUI; I had not yet determined if it was to be applied under global or custom parameter map.  I noticed it on both, so did "no captive portal bypass" for both profiles, waited about 20 minutes for testing and the issue was fixed and behaving as expected.  Thank you for everyone's input.  Below is the current final configuration for both controllers and their configured global and custom profiles for web authentication.

 

foreign-wlc# show run | section webauth

!

parameter-map type webauth global
   type webauth
   secure-webauth-disable
   webauth-http-enable
parameter-map type webauth guest-net
   type webauth
   redirect for-login http://198.51.100.1
   redirect on-success https://google.com
   redirect portal ipv4 198.51.100.1
   max-http-conns 200
   logout-window-disabled
   success-window-disable
   cisco-logo-disable

 

 

anchor-wlc#  show run | section webauth

!

parameter-map type webauth global
   type webauth
   secure-webauth-disable
   webauth-http-enable
parameter-map type webauth guest-net
   type webauth
   redirect for-login http://198.51.100.1
   redirect on-success https://google.com
   redirect portal ipv4 198.51.100.1
   max-http-conns 200
   logout-window-disabled
   success-window-disable
   cisco-logo-disable

View solution in original post

4 Replies 4

Verify if ACL is present on client session.  Verify DNS resolution. If you are using CWA and ISE , make sure ISE is pushing the portal properly.

 

Arshad Safrulla
VIP Alumni
VIP Alumni

Since you are using LWA I assume that you must have configured the web auth parameter maps. It would be really helpful if you can post your current "parameter map type webauth". 

Also let us know whether you have both http and https servers enabled in the WLC?

 

Recommended webauth parameter map configuration

!

no ip http server
ip http secure-server

parameter-map type webauth global
 webauth-http-enable

!

Keep in mind that specifically for apple there was an issue when "no ip http server" is configured in WLC this created unstable Captive portal detection. So it was recommended that you keep the http server enabled (I know this creates a security risk, may be you can use ACL's to limit the exposure) However I have used the above configuration which I shared in couple of deployments where LWA is used without any issues noticed by Apple users.

Prince.O
Spotlight
Spotlight

What version of code are you running on your 9800 WLC ? 

 

Did you test opening up a browser and manually going to a site to see if you're redirected ? 

 

I would recommend taking a PCAP on the anchor WLC while reproducing the issue with the apple devices to better understand the issue since this involves layer 3 redirection

 

9800 PCAP guide:

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213949-wireless-debugging-and-log-collection-on.html#anc17

 

You can also enable radioactive traces on both WLCs for the client mac address:

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213949-wireless-debugging-and-log-collection-on.html#anc12

 

 

 

coolbreeze
Level 1
Level 1

Ok, resolved our issue.  We are running Amsterdam 17.3.3 currently until we can upgrade to 17.3.4a firmware.  It seems there is an issue (whether official bug or not, I am not sure) that we see changes in the GUI are not taking effect in the CLI/running configuration.  I also noticed a discrepancy in the redirect for-login config in the CLI of the foreign controller vs. the anchor, when the GUI options appeared the same.  Additionally we confirmed the paramter-map option "captive portal bypass" should NOT be present in the configuration in order for correct presentation of the webauth credential prompt on Apple iOS devices, as mentioned in other posts found in the forum on here.

 

So, again, the issue seemed to stem from inconsistencies and ineffective configuration application when performed through the GUI; I had not yet determined if it was to be applied under global or custom parameter map.  I noticed it on both, so did "no captive portal bypass" for both profiles, waited about 20 minutes for testing and the issue was fixed and behaving as expected.  Thank you for everyone's input.  Below is the current final configuration for both controllers and their configured global and custom profiles for web authentication.

 

foreign-wlc# show run | section webauth

!

parameter-map type webauth global
   type webauth
   secure-webauth-disable
   webauth-http-enable
parameter-map type webauth guest-net
   type webauth
   redirect for-login http://198.51.100.1
   redirect on-success https://google.com
   redirect portal ipv4 198.51.100.1
   max-http-conns 200
   logout-window-disabled
   success-window-disable
   cisco-logo-disable

 

 

anchor-wlc#  show run | section webauth

!

parameter-map type webauth global
   type webauth
   secure-webauth-disable
   webauth-http-enable
parameter-map type webauth guest-net
   type webauth
   redirect for-login http://198.51.100.1
   redirect on-success https://google.com
   redirect portal ipv4 198.51.100.1
   max-http-conns 200
   logout-window-disabled
   success-window-disable
   cisco-logo-disable

Review Cisco Networking for a $25 gift card