stuck in webauth_reqd

[ron.wilkerson]

An interesting issue (I think).

If a new client joins the WLAN, WPA and webauth works fine and the client is able to access the network.

Webauth is using LDAP (active directoy).                  

The same client returns the next day and he is unable to use webauth.

The WLC has the state of webauth_reqd but the client never sees the login screen.

This behavior happens with all WLANs and clients.

We did a packet caputre and we saw that the client sends out the HTTP request (to start the web auth) but the DNS response never makes it back to the client.  Thus, the web auth doesn't kick in as the DNS conversation doesn't get completed.

We're running 7.4.100 on a 2504.

[David Watkins]

There's some issues with your statement.  A client will not send an HTTP request when it hasn't determined an IP address, via DNS, to form a TCP handshake with.  Once the TCP handshake completes, "then" the client will generate an HTTP request.

When in webauth_reqd, your client will do the followign

1. Open browser

2. Client generates DNS query to defined DNS servers obtained through DHCP or manually configured

3. Get DNS response (which you're saying isn't workign, so this is where you need to focus)

4. Client Send TCP Syn to IP address resolvd

5. WLC will hijack and send TCP SYN ACK with "it's" MAC address.

6. Client will ACK

7. Client will generate HTTP request (which is going to be delivered to the virtual IP through the mac hi-jack from step 5)

8. WLC sends HTTP response with content or redirect.

I agree it's weird that you say this works, then the next day it doesn't.  When the client is in it's "problem state" on the 2nd day, you need to verify that your client can perform a DNS query properly.  When the client is IP'd and in webauth_reqd, open a command prompt and issues "nslookup".  Type a URL, like "www.google.com" and verify you are getting responses.

If you're not, then we will will need some additional info on your deployment, such as if this is local/flex and switching method, etc.  Generally, you would want to just place a "wired" client in the same VLAN this wireless client would be using, and verify DNS.

Can you confirm if this is Local Web Authentication or External Web Authentication, or perhaps CWA using ISE?

[ron.wilkerson]

We saw the HTTP reuests as we are using a MAC and those things automatically try to connect to apple.com.

We're using LDAP for authentication.

And DNS from the cmd promt doesn't work, the DNS request goes out but never comes back.

I've opened a TAC case and they want to run some packet captures, so we'll see.

Was hoping someone else out there had experienced the same issue.

[David Watkins]

for an http request, the client would need to have formed a tcp connection with the web server.  in order to do that it needs to know the ip, via dns.  I won't split hairs on what you saw on the MAC, but if DNS is not working, then webauth will not work.

I've experienced this issue hundreds of times when working with customers in Wireless TAC for several years.

If DNS is not resolving, you need to find out why.  You can take captures if you want, but the easiest first test will be to place a wired client in the same VLAN this guest client is using and see if you can query DNS.  If you "can", then you can start the captures, if you can't, then you need to focus on that issue as it wouldn't be related to the wireless.

[David Watkins]

If you want to verify that the WLC's "webauth" feature is working or not, you can simply manually navigate to the web portal

https:///login.html

This will let you hit the portal without having to worry about DNS.  Again, DNS is the key here to make this work properly, but if you want to see that the web portal page is reachable and working properly, you can just manually navigate while in webauth_reqd, then focus on the DNS problem.

[ron.wilkerson]

Thanks for the replies Dave.

Yes, we are focused on the DNS aspect and we'll test again early next week and run packet captures.

The part I can't make sense of is why the client works when it first connects.

It fails on the subsequent connections.

[George Stefanick]

I would just add .. Make sure your guest name resolves to your virtual address ..

I had issues where 2 DNs servers had two different ips for the same a record ..



Sent from Cisco Technical Support iPhone App

[Nolan Herring]

You ever find out a solution by working with TAC on this yet? Running into the same problem myself.

[Abhishek Abhishek]

Hello Ron,

As per your query i can suggest you the following solution-

Web Authentication on WLCs

Web authentication is a Layer 3 security feature that causes the controller to not allow IP traffic, except DHCP-related packets/ DNS-related packets, from a particular client until that client has correctly supplied a valid username and password with an exception of traffic allowed through Pre-Auth ACL. Web authentication is the only security policy that allows the client to get an IP address before Authentication. It is a simple Authentication method without the need for a supplicant or client utility.Web authentication can be done either locally on a WLC or over a RADIUS server. Web authentication is typically used by customers who want to deploy a guest-access network.

Web authentication starts when the controller intercepts the first TCP HTTP (port 80) GET packet from the client. In order for the client's web browser to get this far, the client must first obtain an IP address, and do a translation of the URL to IP address (DNS resolution) for the web browser. This lets the web browser know which IP address to send the HTTP GET.

When web authentication is configured on the WLAN, the controller blocks all traffic (until the authentication process is completed) from the client, except for DHCP and DNS traffic. When the client sends the first HTTP GET to TCP port 80, the controller redirects the client to https:1.1.1.1/login.html for processing. This process eventually brings up the login web page.

For more information refer to the link-

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080a38c11.shtml

Hope this will help you.