Solved: Web Authentication failure??

rguzman.plannet · ‎03-14-2012

Hello!

I am having a problem with web authentication it just quit working.

The problem is that once I open a broswer it does not redirects me to the login page (virtual interface) thus not getting authenticated.

I wonder if there is a way to restart the service in the WLC or I have to restart the WLC?

Thanks in advance!

daviwatk · ‎03-14-2012

You should check a few things first.

1. Do you have an IP address?

2. From the WLC, what "state" does your client show to be in once you have connected but not yet passed through the WebAuth page. You should be in a "WEBAUTH_REQD" policy state. Found in the WLC GUI (MONITOR > Clients > %yourclientMAC%)

3. Perform nslookup from you client and attempt to resolve an internet domain name. (ie. www.google.com). Does this work? If not, what DNS addresses are you providing? Have you tried any other public DNS servers instead? If nslookup is not working, you should verify that a wired client placed in to the same VLAN as these guests can actually get a name resolved.

If all of the above is met, you have an IP, you are in WEBAUTH_REQD state, and you "can" successfully return DNS. You should "try" the following.

1. Have you tried more than 1 client to verify it is not a "client" issue?

2. Have you tried multiple browsers? IE, Firefox, Chrome, Safari?

3. Can you navigate to the page directly using the virtual IP of the WLC? (ie. https://1.1.1.1/login.html as an example)

Is this a "custom" web-auth page or just the default internal page? If it is "custom", try using the "internal" page, and verify you have the same behavior.

View solution in original post

daviwatk · ‎03-14-2012

You should check a few things first.

1. Do you have an IP address?

2. From the WLC, what "state" does your client show to be in once you have connected but not yet passed through the WebAuth page. You should be in a "WEBAUTH_REQD" policy state. Found in the WLC GUI (MONITOR > Clients > %yourclientMAC%)

3. Perform nslookup from you client and attempt to resolve an internet domain name. (ie. www.google.com). Does this work? If not, what DNS addresses are you providing? Have you tried any other public DNS servers instead? If nslookup is not working, you should verify that a wired client placed in to the same VLAN as these guests can actually get a name resolved.

If all of the above is met, you have an IP, you are in WEBAUTH_REQD state, and you "can" successfully return DNS. You should "try" the following.

1. Have you tried more than 1 client to verify it is not a "client" issue?

2. Have you tried multiple browsers? IE, Firefox, Chrome, Safari?

3. Can you navigate to the page directly using the virtual IP of the WLC? (ie. https://1.1.1.1/login.html as an example)

Is this a "custom" web-auth page or just the default internal page? If it is "custom", try using the "internal" page, and verify you have the same behavior.

rguzman.plannet · ‎03-14-2012

Hi David,

I had to act quickly so I deleted the "guest" interface as well as the WLAN and created it again and it worked!! But thanks a lot for your suggestion I'll take it in mind for the next time.

By the way, the WLC is the DHCP server for the gust wlan and it was delivering IP addresses to all devices but browser was never redirected to login web page.

Thanks again!

daviwatk · ‎03-14-2012

Hey, whatever works Glad you got it going, although it's tough to say exactly "what" the issue was. My instructions were to just take you through each step.

1. If you don't have an IP; you wont be able to perform an NSLOOKUP and your client will not be in WEBAUTH_REQD state

2. If you have an IP and are in WEBAUTH_REQD state but can't NSLOOKUP properly, you may not have any "internet" access at all; or that DNS server is not responding (manually navigating to virtual IP is a good test of this)

3. If you can't ever NSLOOKUP, then you will never generate an HTTP request for the WLC to hi-jack and redirect you to the webauth/virtual IP

Again, glad it's working!

rguzman.plannet · ‎03-15-2012

Hi

I am still having some issues with web auth but this time the service is so intermitent.

I get this log msg:

*Mar 15 14:28:43.840: %PEM-1-WEBAUTHFAIL: pem_api.c:4721 Web authentication failure for station a8:e0:18:32:26:8b

I wonder if someone has seen this before and knows what that means?

Kind regards!

rwegner · ‎05-10-2012

We have found a solution to our web-auth 'authentication failure' problem.

In WCS:

1. go to Configure, Controllers and make sure you only have controllers listed that are 'Reachable'. Delete any controllers that are not reachable. (we had some offline test controllers that we had to delete out of our list)

2. go to Configure, Controller Template Launch Pad, Security, Guest Users. Look at the column 'Apply User account to' and note that each user name may be pointed to a slightly different list of controllers.

This is where our problem began. When we had some test controllers online (and properly added to our controller list and reachable), we could successfully select a large number of user names (using the check boxes) and then do a 'Save guest accounts on device'. However, when we took some of our test controllers offline but DID NOT remove them from the Configure, Controller list, we would try to push out user names and strange things would happen.

It appears that having some controllers offline but still in the controller list is confusing to WCS. Problems take place when you try to push out user names. You must make sure the Configure, Controller list only has entries for controllers that are reachable.

After we cleaned up our Configure, Controller list, we did a delete on some user names, then rebuilt the user names and they were pushed out with no problem.

PS As you add/delete controllers, you also have to do housekeeping on your 'Lobby Admin' user accounts. Go to Administration, AAA, Users and click on one of your 'lobby admin' user names. Click on the tab 'Lobby Ambassador Defaults'. If you use the Apply to, controller list drop down menu item, you will see a list of controller names and IP addresses. Check to see if you have check all the boxes you want checked. If you have added a controller recently, it will not be checked yet...