Web Auth using an external server (ISE) was working with no issues until I installed the 7.5 version on the 5508 WLC because I wanted to test Bonjour protocol with SP and users on different VLANs using MDNS.
I am not getting the URL Redirect configured in the WLC when I am connected to the corresponding SSID and the connection is stuck. I can get an IP and access the Redirect URL from the laptop by copying/paste the URL directly in the browser.
Any ideas about this issue??. the service was working perfectly with version 7.3 but I had to configure multicast and connect all the Apple devices connected to the same SSID/Subnet (limitation on that version).
Solved! Go to Solution.
If your having issue with the captive portal bypass with CWA using ISE, that is a known issue with v7.4 and v7.5. TAC might have a patch for v7.5 as they do for v7.4.
Sent from Cisco Technical Support iPhone App
Hi Scott, thanks for answering.
I forgot to mention that this issue is affecting as well any connection using Win 7 Laptops. I mean, on WLC version 7.3, I can connect with no issues using Apple, Android, Samsung and Win 7 devices over CWA. As soon as I changed it to WLC version 7.5 (only for managing Bonjour Protocol in a different way to the current one), I could not connect (URL Redirect did not work).
I did it. The TAC Engineer asked me to change the URL Redirect using the ISE (like a CoA) but I told him that all the functionalities on the WLC should be the same no matters if you change the Software Version. Thanks Scott, I will let you know the end result of this case.
With respect to this case the following that I found after some additional testing. I found the problem but I need more clarification regarding the PREAUTH ACL OPERATION in the WLC because now it checks DNS Traffic to allow the redirect on version 22.214.171.124
Final Findings and conclusions:
1.-This week I was testing HA SKU N+1 on version 126.96.36.199 and the URL Redirect was not working with the ALLOW AAA OVERRIDE enabled or not so I decided to do more testing and finally I realized that the initial issue has nothing to do with the ALLOW AAA OVERRIDE enabled/disabled.
2.-When I was running version 188.8.131.52 or 184.108.40.206 the PREAUTH ACL in the WLC did not include the DNS Subnet and the URL Redirect worked fine. As soon as I upgraded the WLC to 220.127.116.11, the URL Redirect does not work and I noticed that by adding the DNS Subnet in the PREAUTH ACL, everything worked fine. Apparently there is a change on the NEW WLC Version for the PREAUTH ACL Operation which now checks DNS transactions before allowing the URL Redirect to be applied or sent to the end user that is connecting. If you check on the link: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080bf7d89.shtml, you will see that PREAUTH ACL is only considered between ENDUSER and EXTERNAL WEB SERVER (in our case ISE) and it does not mention anything about DNS connectivity permission required. That’s why I need to check again this part of the Authentication Process indicated next (included in the link mentioned previously):
3.-Once I changed the PREAUTH ACL in the WLC and included the entry for the DNS Subnet (permit condition), I could connect and be redirected properly to the ISE Authentication Webpage with the ALLOW AAA Override enabled or not in the WLC SSID’s (I tested on both situations and worked fine the URL Redirect and I could connect and navigate).
See next screenshots showing our tests with the version 18.104.22.168, using or not ALLOW AAA OVERRIDE on the SSID’s but with the difference on the PREAUTH ACL being applied in the WLC.
ALLOW AAA OVERRIDE ENABLED FOR STAFF SSID
ALLOW AAA OVERRIDE DISABLED FOR STUDENT SSID
ON VERSION 7.5.102.WE SEE THE FOLLOWING FOR THE INITIALLY CONFIGURED PREAUTH ACL (currently running in production environment for WLC version 22.214.171.124):
ALL THE TRANSACTIONS HITTING THE DENY RULE SO THE URL REDIRECT DID NOT WORK, EVEN THOUGH I DID NOT HAVE ENABLED THE ALLOW AAA OVERRIDE FOR STUDENT SSID
NEW PREAUTH ACL “TEST” CONFIGURED IN THE WLC RUNNING 7.5 version and APPLIED to both SSID’s (STAFF and STUDENT). ALLOW AAA OVERRIDE WAS STILL DISABLED FOR STUDENT SSID AND ENABLED FOR STAFF SSID
WE CAN SEE NOW THAT ALL THE RULES ARE BEING HIT. THE URL REDIRECT WORKED FINE FOR THE
VERSION 126.96.36.199 ONCE I CHANGED THE PREAUTH ACL AND I COULD NAVIGATE ON THE WEB
FINALLY, THE NEXT SCREENSHOTS CORRESPONDS TO THE WLC’s in PRODUCTION ENVIRONMENT RUNNING 188.8.131.52 WITH THE PREAUTH ACL CONFIGURED WHICH ALLOWS TRAFFIC ONLY FROM ENDUSER TO EXTERNAL WEB SERVER (ISE DEVICE). YOU CAN SEE ALL THE HITS ON THE RULES OF THE PREAUTH ACL. IMPORTANT TO MENTION THAT “ALLOW AAA OVERRIDE” IS ENABLED FOR ALL THE SSID’s IN THE WLC. URL REDIRECT WORKS FINE ON PRODUCTION FOR THE 184.108.40.206 WLC VERSION.
One more detail that I checked about this topic from the link:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080a38c11.shtml (see screenshots next):
Basically , I should have gone to the basic troubleshooting so I would have realized about the following. In fact, I am going to put back the PREAUTH ACL in the WLC running 7.5 and see if the NSLOOKUP in the CMD Window from the ENDUSER already connected and associated to the WLC works. If not, the new WLC 7.5 version noW requires to add another entry in the PREAUTH ACL for the DNS (to solve the URL Redirect) “or” is a BUG in the 7.5 WLC Version.
I post the results later today.
Here is the bug (CSCuj18674) information if it is CWA bypass issue with iOS7. Yes you have to get engineering release if you want to stay 7.5 & fix this bug.
Current issue may not be this as per the information.
When attempting to access the Guest Portal with an Apple iOS 7 device while the WLC "Captive Portal Bypass" feature is enabled, the web sheet on the device still appears, preventing the user from continuing the flow.
The Apple device is running Apple iOS 7.
In the ACL on the WLC used for captive portal redirection and exemption of special traffic for the Guest Portal, add exemptions for the IP resources that resolve from "www.appleiphonecell.com" and "captive.apple.com" FQDNs.
IMPORTANT NOTE: These IP addresses are associated with the FQDNs of "www.appleiphonecell.com" and "captive.apple.com" and are subject to change by the entities hosting those domains. If the IP addresses do change, the ACL would need to reflect that.
Known Affected Releases:
Known Fixed Releases:
**** Pls rate all useful responses ****
Thanks for your note, but this case has nothing to do with GUEST PORTAL and APPLE DEVICES however could be indirectly correlated.
FINAL CONCLUSION OF THIS CASE:
Based on the troubleshooting and information indicated in the link: http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080a38c11.shtml, DNS should be allowed BY DEFAULT on the WLC but on version 7.5 is BLOCKED. In fact, only by configuring an additional entry in the PREAUTH ACL for the DNS subnet is when the URL Redirect works on that version 7.5.
See next screenshots with the sequence of the tests and final results. I am going to check with Cisco TAC is this is a Bug because on version 220.127.116.11, DNS traffic/communication was allowed by default.
1.-Old Version 18.104.22.168 in the WLC:
2.-PREAUTH ACL applied to the SSID's
3.-Content of the PREAUTH ACL
4.-ENDUSER connected to SSID and can apply NSLOOKUP for version 22.214.171.124 in the WLC.
5.-END User redirected to External Login Webpage, authenticated and navigating in the Web (Version 126.96.36.199)
6.-New Version uploaded to the Controller
7.-Getting an IP and Associated to the AP, but NSLOOKUP on Version 7.5 does not work like 7.3 WLC Version showed in the Cisco Link above.
8.-Opening the Browser and pointing to ESPN.COM but not being redirected on version 7.5
9.-Applying another PREAUTH ACL called "TEST" into to the SSID's in order to test again URL Redirect on version 7.5
10.-Reconnecting to SSID on version 7.5 and verifying that PREAUTH ACL = TEST with the ADDITIONAL RULE allowing DNS Traffic now resolves the NSLOOKUP from the ENDUSER CMD window.
11.-Connected to STUDENT SSID, URL Redirect working fine and accessing ESPN.COM