I have spent a lot of time troubleshooting this and think I've narrowed down the problem. Here is the setup:
I've got two 4402 controllers running 22.214.171.124. The guest SSID is mapped to a dynamic interface (VLAN). The VLAN is trunked through one switch where it connects to a DSL modem. It's a Siemens DSL modem that does NAT. So essentially from the perspective of a guest user it is a flat network.
I have a DHCP scope set up on the WLCs. When a guest client connects, it receives an address. Then they open a web browser and say their homepage is http://www.google.com. It times out waiting for a DNS reply.
I did a sniffer trace on the port going to the DSL modem. I see the DNS query with a source IP address of the guest client PC and destination address of the DSL modem (which I guess gets NAT'd to the real DNS server). Then I see the DSL modem ARP for the MAC address of the guest client PC. But here's the kicker: nobody replies to the ARP request. And I believe that is why the guest client is timing out.
It works fine if I bypass the DNS capture by using https://126.96.36.199/login.html. Also once I authenticate, DNS from the client PC works great, so I know it's not an issue with NAT.
I'm guessing the WLC should be responding to the ARP request since the guest client PC cannot talk to the gateway at this point in the process. But why is it not answering?
I'd also like to point out that I first tried all of this on 188.8.131.52 but had the same issues.
Thanks for any help you can provide.
i have a similar problem,but with me i only have one 4402.the guest works fine until i enable web auth.with web auth enabled i still
get an ip address from the dhcp server which is my controller but the guest wlan will not ping the gateway.
I too am having the same issue. Same setup and problem. This is currently holding up our project and would like to know if anyone has seen a fix yet. I'd hate to run the TAC gauntlet and wait days for a response.
We had similar problems with quests connecting with webauth. We finally had to get them to disable their WinXP firewall in order for the webauth screen to prompt for username and password. I don't know if this is the same challenge but I hope this might help.
I finally got it working... at least it does for now. It appears the pre-authentication ACL was causing this. There's little to not documentation on this feature... and it lead me to believe that it limited network access before a user authenticates to the network. I tried allowing access to the DNS server... along with access to the subnet a guest registration server is on... but all traffic continued to be block. Is this proper use of the preauthentication ACL or am I getting it all wrong?
There is a bug in the pre-auth ACL (CSCse93986) but should not affect DNS. The webauth should work fine without a pre-auth ACL, but if you need to use one remember it's not statefull. You will need to allow for outbound and return traffic. I usually start with an ICMP rule to get the hang of the ACL, and then change to DNS. Bottom line you must be able to successfully run a NSLOOKUP to http://www.google.com or a site of your choice from the guest device, before you can get the Cisco Auth page.
Source Destination Source Port Dest Port
I Dir IP Address/Netmask IP Address/Netmask Prot Range Range DSCP Action
-- --- ------------------------------- ------------------------------- ---- ----------- ----------- ---- ------
1 In 10.0.0.0/255.0.0.0 184.108.40.206/255.255.255.255 17 0-65535 53-53 Any Permit
2 Out 220.127.116.11/255.255.255.255 10.0.0.0/255.0.0.0 17 53-53 0-65535 Any Permit
hey maybe you should help me...how come i dont have pre authentication ACL but stil my web auth wont work.my problem is that once i enable web auth from the guest vlan iam not able to ping the gateway and web auth doesnt work.
What version of code are you running? There was a bug (CSCsc68105) in older versions that sent DNS queries out the management interface.
You should be able to run NSLOOKUP www.google.com on the guest device's command prompt and resolve to an IP in an unauthenticated state. The browser must resolve the url to an IP and then attempt to access. The controller will see the HTTP traffic, intercept and redirect to the Cisco authentication page. Does https://18.104.22.168/login.html work for you?
i am running software version 22.214.171.124,if it is old how do i get the latest version.
in my current set up when i enter https://126.96.36.199/login.html from the guest vlan am not directed to the login page...so web auth does not work at all.
I'm posting this here because this post helped me resolve the same problem but on 6.0.188. Not sure how relevant it is but hopefully if anyone is having the same prob they will look up "Webauth not working" and find this.
When I looked at the redirect page on the bottom of my browser it referred me to https://dnsname.com/login.html?redirect=
Hope this helps someone...
Can you post your show run-config. Like to see how you have your WLC setup. If you create another SSID and point that to an internal interface and set that up for web-auth, does it work?