External Web Authentication - HTTP Redirect or Proxy?

[Nigel Bowden]

I've been reading all of the information I can find about the use of authentication of guest users using an external web server, rather than the native portal provided by a WLC. I've looked at the configuration examples and configuiration guides.

My question is this: when the WLC redirects the client to the external web server, is it a true http redirect (i.e. a http redirect sent to the client) or does the WLC act as a proxy (via its virtual address  - usually 1.1.1.1), altering the http headers as it does when re-directing requests to its internal web portal ?

This is important as I need to understand if it is the client that has to be able to connect to the external web server, or whether it is the WLC that has to be able to connect to the external web server.

The WLC for the solution I am working on is in a highly secure DMZ area, so it is imprtant to know which devices need to talk to which.

[grabonlee]

It is the WLC that connects to the Web server and not the client. Using an external web server is the same as the internal web authentication page provided by the WLC. All the external web server does is to provide the web page. The controller still authenticates the clients through either a local account on the WLC or through a Radius server.

[Nigel Bowden]

Osita,

Thanks for the information - that's great.

So, the http packet that arrives at the external web server has its destination IP address re-written to point to the web server, but what is the source address of the http packet? Would it be the client IP address, WLC virtual address or maybe the WLC management interface?

Thanks

Nigel.

[daviwatk]

I think this explanation will provide the detail you are looking for.

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008076f974.shtml#external-process

To answer your question; it's a bit of both.  The client will indeed be making the HTTP request to the external server; once the redirect occurs; it's not passing "through the WLC" (thus the preauth ACLs necessary to make this wokr).  The redirect aciton_url will provide information to the external server on where to send the information collected; thus sending the info back to the WLC for authentication in order to pass through the WEBAUTH_REQD policy state.

The steps describing your questions are 5 throught 10

[Nigel Bowden]

David,

Thanks for getting back to me on this.

I had reviewed the doc you referred me, but was a little confused by the line:

"8. Because external web authentication is enabled, the WLC redirects the client to the external web server." - it probably needs to be a little more specific.

So, to be clear, it is the WLC that needs connectivity to the external server or the client device? Does the client communicate directly with the external web server, or will it direct its http requests to 1.1.1.1, which will then be proxied by the WLC to the external web server?

Thanks

Nigel.

[daviwatk · Accepted solution]

So, to be clear, it is the WLC that needs connectivity to the external server or the client device? 

Both devices need to communicate to the external web server.  The WLC will need to communicate with the external server since it will be expecting a return of information from that server to process the l3 authentication.  The client will need to reach it as the WLC is going to redirect it to that site (reason for pre-auth acl). 

Does the client communicate directly with the external web server, or will it direct its http requests to 1.1.1.1, which will then be proxied by the WLC to the external web server?

Again this is both; So the client will lookup/resolve a site and initiate some HTTP traffic, so it starts a TCP SYN for to the real web server it is trying to reach, the WLC will see this request; hijack the IP of the destination server and reply back to the client(pretending to be the "internet" server) The WLC redirects the client to it's virtual IP; whether using internal or external web auth.  So the client will arrive at the virtual IP of the WLC; which will then redirect the client to the external web server in your case.  When this happens the WLC has also inserted some information in to the redirect URL on the clients behalf so which the external server will use to send the information it collects (assuming you're using one of our standard external bundles).  The external server will process the client HTTP GET, so as far as "viewing and using" the external web server; the client will make that request directly to the external web server.  The external server, upon submittion of the form on the page, will send the information collected from the client back to the WLC server (which it learned it's IP from the redirect URL).  The authentication of the client will take place at the WLC.

So in this scenario you need a love triangle between the Client, WLC, and external server.  All will be talking to one another at some point.  Your client needs connectivity to the external server; and your WLC needs connectivity to the external server.

David W.

[Nigel Bowden]

Thanks to everyone for their feedback on this - much appreciated.

As a side note, if anyone else comes across this conversation at a later date, take a look at this link for details of setting up the WLC: http://www.cisco.com/en/US/partner/docs/security/nac/guestserver/configuration_guide/20/g_hotspots.html#wp1092277

Nigel.