OSX wifi using dot1x (ise 1.3) error, related to posture ACL

[ben.posner]

I am currently testing ISE 1.3 in our Lab enviroment.  On our production 1.2 cluster I had an issue with Macs connecting to our dot1x enabled SSIDs where the endpoint would get an error just after connnecting, before posturing takes place, and then afterward sometimes not get the CoA for the VLAN change. I thought this was an incompatibility between Yosemite and our behind-patches 1.2 setup. But the issue is still presenting in my 1.3 Lab environment as well. attached is a screenshot of the endpoints desktop when connecting to the test SSID I have running. During this time the endpoint has a temporary IP and is supposed to be postured by the OSX CCAAgent. But the agent doesn't launch until you acknowledge the errors. during this time you have NO access outside of your local lan.

We apply a POSTURE ACL to clients during this phase of connection that allows DNS, FULL IP to the ISE Policy Nodes, ICMP, etc. If i add a 'permit any any IP' rule to the end, the error for the end user disappears, leading me to believe this is a connectivity issue during posturing, but since you cannot get any detailed logging for a WLC ACL i'm kind of stumped. anyone have any ideas?

here is the POSTURE acl we are using. note that the only ISE node relevant for this Lab is the 10.5.11.50 host, the others are the PRODUCTION policy nodes running 1.2:

 

and here is an example endpoint desktop just after connecting, posturing has NOT occured yet and wouldn't until the user acknowledges the error joining the SSID by clicking okay and closing the middle window that popped up after connecting to the SSID:

[ben.posner]

I believe I have resolved my own issue. The error users are seeing seems to be related to Apple devices and their attempt at detecting a captive web portal on any connection to any ssid, regardless of whether it is necessary.

I found this document (http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/116041-solution-apple-osx-00.html) explaining how the Apple Captive Network Assistant works on OSX and iOS 7.1 and above and surmised that my POSTURE ACL was denying the OSX workstations from accessing the success page on apple's web site. hence why everything worked fine when i applied an any any IP rule to the end of my POSTURE ACL in troubleshooting.

to rectify the issue i added the following line to my POSTURE ACL: 

This allows any host connecting and using the POSTURE ACL to make an HTTP request inbound to the WLC and satisfies the operating system. I have tested it several times today and it works so far.

[nspasov]

Hi Ben-

Good job on resolving your own problem! Also, thank you for taking the time to come back and post the solution here (+5 from me). 

I do have one question: Did you have the following command on your controller:

config network web-auth captive-bypass enable

I have faced this issue in the past and enabling that command on the WLCs fixed the issue for me, however, it did force the users to manually open a browser and try to navigate to a page. 

Thank you for rating helpful posts!

[ben.posner]

I was about to go down that road when I had my epiphany. If I had I'd have plenty of upset iOS users on my hands. Glad I was able to work around that particular issue.

[nspasov]

Yeah, I know what you mean :) Again, the important part is that you found a resolution. 

Since your issue is resolved, please mark the thread as "answered" :)

Thank you for rating helpful posts!

[ben.posner]

i can't mark it answered because i answered it! i don't have the option to say my reply is the correct answer. that is annoying.