Guest WLAN and Web Auth?

Hi Guys,
Maybe someone can help me out?

I just finished setting up a trial "Cisco Virtual Wireless Controller" with nearly the same configuration as our Physical "Cisco Wireless Controller" with the exception of having 2 ports.  Anyhow, I managed to get everything working except for the WEB AUTH on the Guest WLAN.  When a client connects, he gets a DHCP address from our ASA but when we try to get to a website, we never reach the WEB AUTH page.

What I tried so far is..

add a DNS Host Name to the virtual interface and assign it to our internal DNS server.
        dns name was resolving but we were unable to ping 1.1.1.1

changed the virtual ip from 1.1.1.1 to 2.2.2.2 and modified the DNS entry
        dns name resoved but still could not ping 2.2.2.2(I think this is normal)

changed the virtual IP to a private address of 192.168.102.1 and modified the dns entry
        same result


I've attached some screenshots of our configuration.
WLAN.JPG
WLAN-Security-Layer3.JPG
WLAN-Advanced.JPG
Management-Interface.jpg
Guest-Interface.jpg
Virtual-Interface.JPG
Web-Authentication-Certificate.JPG
sthubertAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Craig BeckCommented:
Firstly, give the Virtual interface an address like 1.1.1.1 - something completely non-routable by your internal network.

Second, you need to ensure that clients can resolve DNS hostnames BEFORE they authenticate.  Therefore you need to create a pre-authentication ACL on the WLC to allow unauthenticated clients (ie. Before they see the Web-Auth page) to resolve external hostnames, then select that ACL in the WLAN Security -> Layer3 page.
0
sthubertAuthor Commented:
I had it at 1.1.1.1 from the start and as I mentioned once we connect to the WLAN the DNS resolution works fine.  Will this pre-authentication ACL help at all?
0
sthubertAuthor Commented:
I tried your suggestion anyway but it didn't work.  I don't even see any hits on the counters but from my client I am able to resolve 1.1.1.1 to guestwifi.domain.com.
0
Challenges in Government Cyber Security

Has cyber security been a challenge in your government organization? Are you looking to improve your government's network security? Learn more about how to improve your government organization's security by viewing our on-demand webinar!

Craig BeckCommented:
Your config screenshots show a different address to what you said the virtual address is.
0
sthubertAuthor Commented:
I changed it to 1.1.1.1 since it was suggested.
0
Craig BeckCommented:
Ok, so if you type in http://1.1.1.1/login.html or https://1.1.1.1/login.html can you see the page once you're connected to the Guest WLAN?
0
sthubertAuthor Commented:
No I do not, nor can I ping it.
0
Craig BeckCommented:
Ok, check the client's gateway address is correct.  The client needs to be able to route to the DNS server to actually resolve the hostname.  The client should be trying to get to a HTTP site (not HTTPS) in order for the WLC to intercept the client's web-traffic and redirect to the login page.

If you have any ACLs configured for the interface that the Guest WLAN is using, remove them and try.
0
sthubertAuthor Commented:
craigbeck, I checked and the gateway is correct which is our ASA.

Let me give a bit more details.

Since the Virtual WLC no longer supports DHCP, we redirected the DHCP requests to our ASA which has one of it's ports in our GUEST VLAN.  The Virtual controller is setup in VMWARE with its port configured in a TRUNK and it's controller interfaces tagged in the appropriate VLANs.  Perhaps this scenario has something to do with my it's not working?  Maybe because the 1.1.1.1 request is a broadcast and the ASA is disregarding it?
0
Craig BeckCommented:
No I doubt it's the ASA not allowing access to 1.1.1.1 - the WLC intercepts traffic to any destination as long as it's via the HTTP protocol, then redirects it to 1.1.1.1 instead (internally before it gets to the ASA).

If you're getting an IP address via DHCP I'd say your trunk is working correctly.  You could turn off DHCP proxy if you want to send DHCP requests to the ASA directly.  This would prove 100% that the trunk works as desired.
0
sthubertAuthor Commented:
DHCP Proxy is already disabled.
0
sthubertAuthor Commented:
My TRUNK passes through multiple different switches to get from all sources.  Can it be that there is a Cisco command that blocks broadcasts so that the WLC is never able to intercept the 1.1.1.1 request?
0
sthubertAuthor Commented:
Hmmmm... I forgot to mention that we still have our Physical WLC in the same VLAN but I tested disabling the Guest WLAN and it didn't work either.  Can it be that the Physical WLC which is plugged into our main switch tries to repond to the request even if the Guest VLAN with WEB_AUTH is disabled?
0
Craig BeckCommented:
Ah so it is!

So the trunk works then if clients can send a broadcast to the DHCP server.

It must be an ACL issue, either on the ASA or WLC.
Can the ASA ping the guest interface IP on the WLC?

Can you test from a wired client on the Guest VLAN?
0
Craig BeckCommented:
The physical WLC won't intercept the Guest's HTTP request from a different WLC as it will never get there.  The WLC doesn't forward requests when the guest isn't authenticated.

As long as traffic can pass through the WLC (you've proved it can by obtaining an IP address directly from the ASA) the 1.1.1.1 connection will work.

I'd try creating a new self-signed cert for the WLC as I remember you saying you'd changed the Virtual IP address.
0
sthubertAuthor Commented:
Turns out it was a known bug with the version of the controller we had.  I installed the latest AES and it works like a charm.  Thanks for your help.

See attachment.
bug-vwlc.jpg
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Craig BeckCommented:
I did not know that!
0
sthubertAuthor Commented:
craigbeck was very helpful but the issue was a bug in the version we had.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Wireless Networking

From novice to tech pro — start learning today.