Solved: Captive web portal question on WLC2006

alanmunter · ‎10-12-2006

I have 6 1231G access points that I have converted to LWAPs and a shiny new WLC2006. I am trying to get the internal web login page to work, but it fails when it tries to redirect to the "virtual" interface on the WLC. I read the Deployment Guide: Cisco Guest Access Using the Cisco Wireless LAN Controller, but I didn't understand everything that they recommended.

We have a few network ports coming from our routers statically configured by our central IT to be on a "visitor" VLAN. All of them share one "visitor" subnet. Previously we just had an open wireless network and let people on that visitor subnet, but now we would like to use this WLC2006 to serve as a password-protected gateway to the visitor subnet. We have an existing DHCP server and DNS server on that subnet that we give out to wireless clients that connect.

I configured the "management" and "ap-manager" interfaces with VLAN of 0 and addresses in this subnet and connected one LWAP to it. It is seen and activated by the controller. I also configured the address of our DHCP server in the "management" interface. I then enabled Web Policy/Authentication for the Layer 3 security of the visitor wlan I set up. The "virtual" interface has an ip address of 1.1.1.1 (not routable).

So now when I try to associate the DHCP traffic goes through. I get an address on the subnet. I open up a web browser and it does get the initial Cisco page which contains nothing but a META redirect to https://1.1.1.1/login.html?redirect=google.com which never completes. I assume that this is because there is no route to 1.1.1.1 since I am giving it a real route on our network from the domain controller.

What should I do? I tried assigning the "virtual" interface to a real one on the network, but it doesn't seem to let me assign one that is in the same subnet as the management interface. I don't think I will be able to talk the central IT folks into reconfiguring their wired routers for me, so I would like to do any setup just on the WLC and on our DHCP/DNS servers if that is possible.

Thanks,

Alan

ethiel · ‎10-12-2006

Ok, I am too late to edit my last post. It occured to me I messed up one part.

The client sends its DNS query to its DNS server (let's say 10.10.10.10), and the controller intercepts it. When the controller proxies the connection it sends the DNS query to the same server (10.10.10.10), but it sources it from the Manager or AP-Manager interface (I forgot which one). It has been a while, but as I recall one of those addresses had to be allowed to talk to the DNS server assigned to the client. In my situation, the IPs were not allowed out through the firewall, so when guests tried querying the external DNS server before getting the splash, the controller was not allowed to access them, and the clients timed out waiting for a response.

-Eric

View solution in original post

alanmunter · ‎10-12-2006

I got it working, but now I don't understand why. I haven't changed anything on our router, but what I did was supply a legitimate router address via our DHCP server.

Since I was doing my setup on a protected, but live, network I had configured the dhcp server to send a bogus gateway address so that no traffic could leave the network. I figured that since I was only talking to IP addresses on that subnet (and to the fake one at 1.1.1.1 that presumably the WLC knew how to handle) it wouldn't need to talk to the actual router.

As soon as I reset the DHCP back to the real router the redirect worked even though it knows nothing about 1.1.1.1.

What gives?

Stephen Rodriguez · ‎10-12-2006

The WLC knows about 1.1.1.1 since it's one of it's interfaces. So having a routable address there is not necessary. But the WLC does do a DNS query when the client goes to connect. If the WLC cannot contact the DNS server and verified that the requested page is valid the controller halts, and drops. If the WLC contacts the DNS and gets a valid ressponse, then it offers the login page, and once the user has authenticated will then pass the traffic thru.

HTH,
Steve

------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered

alanmunter · ‎10-12-2006

I can't find anywhere to configure a DNS address on the WLC. Does it sniff it out of the DHCPOFFER messages that it passes along or something?

I didn't change the DNS server in the DHCPOFFER to get it to work. I just changed the router to a real one. The management, ap_manager, LWAP, DHCP server, and DNS are all on the same subnet, so I am still confused about why the invalid gateway would affect the DNS lookups. Which interface does the DNS request? Is it the virtual one, 1.1.1.1?

I sniffed the wireless traffic and have some ethereal dumps. I will sniff the wired traffic coming from the WLC next to see what else is going on.

ethiel · ‎10-12-2006

Ok, so here's how it works:

When the client gets on the network, the controller contacts the DHCP server and hands the client back its IP (as with any helper address).

In order for web auth to work, you need to open a browser on the client.

When you go to a page (say www.google.com) your browser does a DNS query for the IP address of the site (www.google.com), the controller intercepts the query.

Since you have not been authenticated yet, the controller does not allow the query directly, but it proxies the query to the DNS server you were trying to resolve against. It sources this query from its interface that is on the VLAN the SSID your client is on maps to.

That reply is proxied back to your computer, and then your browser does its normal request to Google?s IP.

The controller then intercepts that request, and sends a reply back redirecting the browser to the controller login page (usually https://1.1.1.1).

Once you log into the web page, you will be redirected back to your original page (www.google.com).

I hope I explained it well. If I wasn't clear, please let me know.

-Eric

ethiel · ‎10-12-2006

Ok, I am too late to edit my last post. It occured to me I messed up one part.

The client sends its DNS query to its DNS server (let's say 10.10.10.10), and the controller intercepts it. When the controller proxies the connection it sends the DNS query to the same server (10.10.10.10), but it sources it from the Manager or AP-Manager interface (I forgot which one). It has been a while, but as I recall one of those addresses had to be allowed to talk to the DNS server assigned to the client. In my situation, the IPs were not allowed out through the firewall, so when guests tried querying the external DNS server before getting the splash, the controller was not allowed to access them, and the clients timed out waiting for a response.

-Eric

alanmunter · ‎10-13-2006

OK. I had been feeding a bogus router address through the DHCPOFFER. When I switched the bogus router address to an IP address that still wasn't our router, but did have a live host on it the thing worked.

So that works now. And now I am going to try to figure out what "External (Redirect to an External Server)" does because the documentation on that is pretty sparse as well.

ethiel · ‎10-13-2006

External basically allows you to put your own HTML page up on an external web server to do the user auth. The benefit is you can make the page much more complex, as long as you include the template for the actual user auth section. In this case the controller redirects your client to talk to the external web page before you are authenticated. We use this when we want a more custom web auth page, and in my current deployment we are doing it primarily to take load off of the controllers, which will be fairly heavily burdened already.

- Eric

alanmunter · ‎10-13-2006

You say:

"as long as you include the template for the actual user auth section"

What does this entail, actually?

Would I just copy the html source from the page that the WCS internal web auth gives into a page on my own server and add any additional fields that I want them to enter and the WCS is somehow smart enough to figure it out?

ethiel · ‎10-13-2006

Sorry, check the following url for info about the code you need to include in the HTML. It refers to it as login_template.

http://www.ciscosystems.com/en/US/products/ps6366/prod_release_note09186a00807156db.html#wp132251

Also, while looking for the link I stumbled across a TAC case collection item that finally acknowledged the issue I described as a bug, and I guess it was fixed in 4.0. Now the DNS query from the controller is supposedly sent from the VLAN interface that corresponds with your SSID. So my first post was actually right, even though I didn't know it. :)

The description is at:

http://www.ciscotaccc.com/kaidara-advisor/wireless/showcase?case=K74851445

-Eric