We have a DMZ based anchor WLC for a guest WLAN. I have this WLAN configured for central web authentication using ISE 1.2, this works correctly and can login using the guest portal.
However, after logging when browsing to a website everything is redirected to the local web authentication page and the policy manager state for the client goes in to a WEBAUTH_REQD state. I currently don't have any layer 3 security configured for this WLAN, so from my understanding it should just be using the central authentication provided by ISE.
Thanks for your help.
What is the WLC code you are running?
Please uese the below config. guide
We're using ISE 1.2 and 220.127.116.11 for the WLC.
I used that guide to create the WLAN in the first place and have just deleted the WLAN to recreate it using the guide again.
Unfortunately once the authentication with ISE is completed, the client goes in to WEBAUTH_REQD state for the policy manager and gets redirected to the WLC.
Make sure that the authorization part does not match the central web authentication profile again. Otherwise, there will be a redirection loop. For more detail you can see the below link
Thanks for the response. I don't believe a redirection loop is occurring. Below is an image of our authorisation rules for Guest access. Once the user has authenticated they are correctly matching the Guest Web Access rule instead of the Guest Web Redirect rule.
Any further ideas?
Apologies I thought I had posted the solution already. The issue ended up being that we had AAA for accounting for the WLAN enabled for both the foreign and anchor controller.
To resolve this, on the foreign controller for the WLAN we have the AAA accounting method configured but on the anchor controller in the DMZ the AAA accounting method is not configured.
Let us know how you go and if needed I will post screenshots for you.
We're also having the same problem here, though our FC is a 3850 switch. If I disable the Accounting on the Anchor 5508, the client just keeps going back through CWA, which suggests that for me the COA needs accounting to be active. I've tried disabling the Accounting on the FC but I still get the LWA page from the Anchor.
If Accounting is turned on, then I can follow the AuthZ session through the ISE and it returns the correct policy to the 5508 Anchor, but it overrides it with LWA.
Any chance you can post some screenshots so I can compare?
I should clarify my set up since my original post. We have a 3850 acting as a mobility agent (and access switch) and in this scenario too is the foreign anchor. The guest WLAN is then anchored to the DMZ WLC which is a 5507.
Attached are screenshots of the AAA for the WLANS on the foreign and anchor controller. As you can see on the anchor controller, the accounting servers are not enabled. On the foreign controller, I have a method set for both authentication and accounting. The "default_authe_dot1x" and "default_accou_ident" lists refer to a radius group called ISE and this contains the two ISE policy nodes.
Let me know if that helps.
Thanks - that looks very similar to ours, though I'm doing the 3850 via the CLI as the web UI keeps dying when I click into things.
I've realsed that I unticked the Authentication servers box instead of the Accounting as I miss-read the WLC page, however while the LWA no-longer kicks in, I'm unable to pass anything except DNS traffic. The Anchor says that the client is in "Webauth" state so it looks like it's expecting something, but ISE says it's all ok and I can see the 3850 traffic going through the process flow.
If I attach an AP to the WLC directly and have the accounting box ticked, then it all works exactly as I'd expect - this is just, well, odd....
I'm interstate today, but tomorrow I'll confirm that on my anchor whether it stays in "webauth" state or not after joining. My first thought is to ensure that ISE is seeing the successful auth and assigning the policy you expect it too. Then make sure that the details in that policy is correct.
Once the guest has authenticated here we assign an open access policy to them (see attached) with no access list. This is because they're isolated in the DMZ and can only exit our network.