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!