A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Thursday, August 6, 2009

Wireless Guest Access common issues

You probably know the Wireless Guest Access feature, by which wireless clients use a Web interface to enter credentials before being allowed to access the network. There are several common issues that you may be facing, and here a re a few suggested solutions...
First, let's verify the process:
Client detects the guest SSID, sends a Authentication request and receives an authentication success reply (authentication is typically open in this type of network).
Client sends an association request, and receives the association reply with AID, nothing special here.
At this stage, the client is associated and can send two types of traffic: DHCP and DNS (warning: except if you setup a preauthentication ACL! In this case, make sure that your ACL does allow DNS and DHCP traffic!). So the client can get an IP address, obtain DNS server information, open a Web browser and try to open an URL. Upon doing so, the DNS server is queried to resolve the URL IP address. Upon seeing the DNS answer, the controller redirects the browser to the authentication page.

In a real or lab network, you may face several issues:

1. No DNS server. Your network is internal, and not DNS server is available to resolve the URLs. Of course, if no DNS server can be queried by your client, the process stops and the Web browser returns a "Cannot open page" message, as the browser does not know how to get to the URL you ask.
Two solutions here:
- Ask your clients to open directly the Web authentication page, typically in the form https://1.1.1.1/login.html.
- Play with your client hosts file! If your client is a Windows client, this file is located under %windir%\system32\drivers\etc\. In Linux, it is typically under /etc. The hosts files contains the DNS entries that your client can know without asking an external DNS server. Insert a line in this file in the form "1.1.1.1 https://mynicepage.com", then ask your clients to use mynicepage.com/login.html as their default page.

2. Special port: you want to authenticate your clients on your WLC, but not on the default port 80. By default, the controller redirects queries on port 80 to the Web Authentication page, but all other ports (apart from DNS and DHCP) are blocked. What if you need to redirect them when they open, say, port 5000?
Go to your controller CLI, and enter: config network web-auth-port 5000.
Then ask your clients to open their browser with the relevant port, in the form http://www.cisco.com:5000 (this supposes of course that you solved the "no DNS" issue).

3. Default proxy: this is a classic one. Many clients say "hey, all of my clients are configured to use the proxy 10.10.10.10. When I open the browser, they are redirected to the proxy, no matter what, and they never get the Web Authentication page.
Just configure their browser not to proxy for 1.1.1.1... this configuration is commonly under the options of the browser, in the section where you configure proxy settings. There is often an "Exceptions" or "Advanced" button where you can say that when the address is 1.1.1.1, do not use the default proxy.

Feel free to add other issues you see in your deployments/labs!

7 comments:

  1. Thanks for the proxy tip! So simple a solution, but you can't imagine how many people were stumped by this problem (and now feel a bit stupid, including myself!). :)

    ReplyDelete
  2. I am having a strange problem with a customer where they have 2 local WLCs(wisms on cat6k) and one anchor 4402 controller. webauth works fine and guest are able to browse some websites, but not all ! ping and tracert to those sites work fine without any delay from guest laptop while it takes forever to load the http page !! Moreover, a laptop connected 'wired' to the dmz switch in the same guest vlan is able to browse all sites without any issue.... anything i am missing here ? Everything was working fine till this time and this issue started a week back ! no config changes were made though..

    ReplyDelete
  3. Strange... I would check the controller logs... did you change the controller code recently? Change the Web redirect port? It may be a controller related issue, but also a client related issue (where clients would try to use their wired interface first for cached sites, even if this interface is not connected). Trying while looking at a WLC debug client mac on the WLC is the best way to know where the problem is located... tell us more when you have time to do that!

    ReplyDelete
  4. Thanks for the response Jerome. Nothing was changed, no code change no config change... as i mentioned, some sites do work perfectly fine.. webauth works fine etc... not a client related issue cos all of the guest users (more than 20 ) have this problem and only on the guest ssid, corporate users are working fine. ... as you mentioned "clients using their wired interface even if they are not connected" , is that a possibility ? we tried clearing cache and tested with no results..... yes i am planning to do a debug client mac on the guest wlc... thanks for the help ! will keep you posted...

    ReplyDelete
  5. Jerome,

    Hi! How do you go about mobile devices like iPad and iPhone? We have been experiencing issues with them like they could not cache in the username and password they have entered during the first login on the Web Auth on the browser. Could you recommend a solution? We are currently using the NAC guest server as radius server for the guest users.

    Thanks

    ReplyDelete
  6. There is no easy solution for Ipad and Iphone (apart from maxing the session timeout), unless you use ISE, where you can recognize those devices and basically send a profile back that sets a very long session timeout...

    ReplyDelete
  7. Jerome, user timeouts, and session timeouts are all set to 36000 seconds... Yet users complain of discos every 5 minutes. Is there a hidden setting somewhere - or it just the fault of the device roaming from AP to AP & needing to re-auth?

    ReplyDelete