WLC 上配置Web认证
Web Authentication on WLC (wireless and wired) : complete guide
Webauth inner workings on page 3
?Webauth position as a security
feature : on page 3
?How does it work really : on page 3?How to make an internal webauth work on page 4
?Let’s go for custom ! on page 4
?Small trick with “override global
config” : on page 5
?Redirection issue : on page 5?External webauth? Was ist das (what is
that)? on page 6
?Web Passthrough on page 6?Conditional Web Redirect on page 7?Splash Page Web Redirect on page 7?External Authentication (radius) on page
8
?How about setting a wired guest wlan ? on page 8
?Let’s put some certificates for the login page on page 10
?Putting a certificate for the controller
webauth : on page 11
?Putting the CA certificate and all other
certificates on the controller as well
(5.1 and later): on page 11
?Getting the certificate name to match
with the URL : on page 12
?Troubleshooting certificate issues : on
page 13
?Troubleshooting : things to check before crying on page 15
?What if I'm using an HTTP proxy server ? How is it going to work ? on page 17
?Hey, I don't want to be bothered with
certificates (i.e. doing webauth over HTTP
and not HTTPS) on page 18
Webauth inner workings
Webauth position as a security feature :
Web authentication is clearly layer 3 security. It allows for user-friendly security (no fancy configuration) that works on any station that can run a browser.
If you’ve been wondering if it can be combined with layer 2 security … Actually yes you can combine web authentication with any PSK security. Although this reduces the “user-friendly” part greatly and thus is not that much used, it has the advantage to encrypt client traffic! Y es, most people forget the fact that web authentication is an authentication method and doesn’t bring any encryption!
Web authentication cannot be configured with 802.1x/radius.
How does it work really :
The 802.11 authentication process is “open”, so you authenticate and associate without any problem. After that, you are “associated” but not in the WLC “RUN”state. Y ou are kept in “WEBAUTH_REQD” where you actually cannot access any network resource, no ping, nothing. Y ou’re supposed to have received a DHCP ip address along with the address of the DNS.
Then you are supposed to type in a URL in your browser. The URL has to be valid!!! The client will resolve the URL through the DNS protocol. The client
will then send his HTTP request to the ip address of the website. The WLC intercepts that request and returns the webauth login page, spoofing the website ip address. In case of external web authentication, the WLC replies with your
website ip address an http response saying the page has moved. And where
did your web page move ? T o the external web server used by WLC of course. Once you’re authenticated, you gain access to all network resources and are, by default, redirected to the URL you originally requested (unless you configured a forced redirect on the WLC).
Tips------------------------------------------------------------------------------------------------
If you want the WLC to watch another port than port 80 (like acs web interface being on port 2002 or other similar applications) you can use “config network web-auth-port
How to make an internal webauth work
This is quite simple. Y ou need to configure a WLAN with a working dynamic interface. The clients should also receive a DNS ip address through DHCP. The best is to test before setting any webauth if your WLAN works fine, if you can resolve DNS request (nslookup) and if you can browse web pages. Then you just set web authentication as layer 3 security features and you’re good to go. Y ou can create your users in the local database or on an external radius server for example.
Let’s go for custom !
Custom webauth can be configured from the security tab. There you can configure a “redirectUrl”. This is used to force a redirect (to your company homepage for example) after user authenticated fine, thus overriding the original URL client requested.
So you type https://www.360docs.net/doc/2818035880.html,, you end up on the webauth login page, you type your credentials and instead of being redirected to https://www.360docs.net/doc/2818035880.html, , you are redirected to
https://www.360docs.net/doc/2818035880.html, if google was configured as RedirectUrl.
The “custom” thing actually just allows you to put your nice shiny own little page instead of the default login page. The concept is just the same. So you can upload your bundle (html + images files) to the controller (in the upload page, look for “webauth bundle” in a tar format. Usually PicoZip is doing nice tars that work perfectly with the WLC. An example of bundle is provided with this chunk. It’s always recommended to start from an existing bundle and to customize it rather than starting from scratch.
There are some limitations with custom webauth that varies with versions and bugs. The things to watch for are .tar file size (used to be 1Meg maximum), also the number of files in the .tar as well as the filename length of the files in there (something like 30 characters max for a file). Don’t take the previously mentioned number for hard rules but if customer complains about the custom package not working, try with a simple one. Then add files and complexity to reach the package customer is using. Y ou’ll probably face the problem at some step there.
Small trick with “override global config” :
For each wlan, you can now configure “override global config” and set a webauth type for each WLAN. This means you can have an internal/default webauth with a custom one for another WLAN.
This also allows you to configure different custom pages for each WLAN. How can we do that ? First you have to put all your pages in the same bundle and upload it to the WLC. Then with the “override global config” setting you put custom (on each wlan) and you can actually select which is the login page from all the files in the bundle. So you can chose a different login page inside the bundle for each WLAN.
Redirection issue :
One thing to pay attention at is the fact that there is a variable in the HTML bundle
that allows the redirection. People customizing bundles are tempted to put their forced redirection URL there. For any weird redirection issue in custom webauth, this is definitely something to check.
For example one issue is that if you enter a “Redirect URL” in the WLC GUI, this could overwrite or adds up to the URL defined inside the bundle. What I already saw is : -in the WLC gui, redirectURL field is set to for example : https://www.360docs.net/doc/2818035880.html, -in the bundle you have the line : “redirectURL+= ‘https://www.360docs.net/doc/2818035880.html,’ “
Because of the “+=” you will end up with users being redirected to
https://www.360docs.net/doc/2818035880.html, ...
External webauth? Was ist das (what is that)?
As already briefly explained, using an external web authentication server is just an external repository for the login page. It is still the WLC taking care of authenticating the user credentials. The external web server just allows you to have a bigger login page. Here are the steps happening when doing external webauth :
1. The client (end user) opens a web browser with a URL, such as https://www.360docs.net/doc/2818035880.html,.
2. If
the client is not authenticated and external web authentication is used, the WLC redirects (by sending an HTTP redirect to the client, using yahoo spoofed ip address and pointing to the external server ip address) the user to the external web server URL. The external web auth login URL is appended with parameters such as the AP_Mac_Address, the client_url (https://www.360docs.net/doc/2818035880.html,) and the action_URL that the customer needs to contact the switch web server. 3. The external web server URL leads the user to a login page. At this point, the user can use a preauthentication access control list (ACL) in order to access the server. The ACL is only needed for 2000 series !!!! 4. The login page takes user credentials input, and sends the request back to the action_URL example, http://1.1.1.1/login.html, of the WLC web server. This is provided as an input parameter to the customer redirect URL, where
1.1.1.1 is the Virtual Interface Address on the switch. 5. The WLC web server submits the username and password for authentication. 6. The WLC initiates the RADIUS server request or uses the local database on the WLC and authenticates the user. 7. If authentication is successful, the WLC web server either forwards the user to the configured redirect URL or to the URL the client started with, such as https://www.360docs.net/doc/2818035880.html,. 8. If authentication fails, then the WLC web server redirects user back to the customer login URL.
Web Passthrough
This is simply a variation of the internal web authentication. It will display a page with warnings and blabla but no prompt for credentials. The user just has to click
“ok”. There is the possibility to enable “email input” and the user will have the possibility to leave its email address. This will have the effect to give to the user a name. Once the user is connected, if you check in your active clients list, this precise user will be listed as having the email address he typed as username.
Conditional Web Redirect
If you enable conditional web redirect, the user can be conditionally redirected to a particular web page after 802.1X authentication has completed successfully. You can specify the redirect page and the conditions under which the redirect occurs on your RADIUS server. Conditions might include the user's password reaching expiration or the user needing to
pay his or her bill for continued usage. If the RADIUS server returns the Cisco AV-pair "url-redirect," then the user is redirected to the specified URL upon opening a browser. If the server also returns the Cisco AV-pair "url-redirect-acl," the specified access control list (ACL) is installed as a preauthentication ACL for this client. The client is not considered fully authorized at this point and can only pass traffic allowed by the preauthentication ACL. After the client completes a particular operation at the specified URL (for example, changing a password or paying a bill), the client must reauthenticate. When the RADIUS server does not return a "url-redirect," the client is considered fully authorized and allowed to pass traffic. ________________________________________ Note The conditional web redirect feature is available only for WLANs that are configured for 802.1X or WPA+WPA2 Layer 2 security. ________________________________________ After you configure the RADIUS server, you can then configure the conditional web redirect on the controller using either
the controller GUI or CLI. More at :https://www.360docs.net/doc/2818035880.html,/en/US/docs/wireless/controller/5.1/ configuration/guide/c51wlan.html#wp1259282
Splash Page Web Redirect
If you enable splash page web redirect, the user is redirected to a particular web page
after 802.1X authentication has completed successfully. After the redirect, the user has full access to the network. You can specify the redirect page on your RADIUS server. If the RADIUS server returns the Cisco AV-pair "url-redirect," then the user is redirected to the specified URL upon opening a browser. The client is considered fully authorized at this point and is allowed to pass traffic, even if the RADIUS server does not return a "url-redirect."
________________________________________ Note The splash page web redirect feature is available only for WLANs that are configured for 802.1X or WPA+WPA2 Layer 2
security. ________________________________________ After you configure the RADIUS server, you can then configure the splash page web redirect on the controller using either the controller GUI or CLI. More at :https://www.360docs.net/doc/2818035880.html,/en/US/docs/wireless/controller/5.1/ configuration/guide/c51wlan.html#wp1259282
External Authentication (radius)
There is an order in which the WLC checks for the credentials of the user.
1) In any case, it first goes look into its own database 2) If it couldn’t find the users there, it goes to the radius server configured in the guest WLAN (if there is one configured) 3) It then checks in the global radius server list against the radius servers where “network user” is checked.
This third point is very important and answers the question of many people “I didn’t configure any radius for that WLAN but it still checks against the radius when the user is not found on the controller!”.That’s because you have “network user” checked against your radius servers in the global list.
WLC can authenticate users to RADIUS server using PAP, CHAP or EAP-MD5. This is a global parameter, it is configurable either from GUI or CLI:
From GUI : Controller -> Web Radius Authentication
From CLI: "config custom-web radiusauth
Note: Nac Guest Server only does PAP
How about setting a wired guest wlan ?
It is easy to configure and very close to the wireless guest config. You can do it on one controller, or with 2 controllers (only if one is auto-anchor), which is more interesting.
So imagine, you have a Switch, with a VLAN 50, which is the "Wired guest" VLAN. Whenever a wired guest wants access to the internet, plug the laptop to a port on that switch, in VLAN 50. This VLAN 50 guest to the trunk where you have your controller, called WLC1, waiting. WLC1 is your internal controller. It has quite a few WLANs and VLANs. It also receives the requests for wired (and wireless maybe) guest users, and sends them to the DMZ controller, DMZWLC.
So here is the process. Configuring Wired Guest Access is done is 5 steps:
1. Configure a dynamic interface (VLAN) for wired guest user access
2. Create a wired LAN for guest user access
3. Configure the Foreign controller (Main Office)
4. Configure the anchor controller (the DMZ controller)
5. Fine tune the guest LAN
1. On WLC1, create a dynamic interface VLAN50. In the interface configuration page, check the "Guest LAN" box. As soon as you check that box, fields such as IP address or gateway disappear. The only thing your WLC needs to know about this interface is that "there will be client traffic coming from VLAN 50. These clients are wired guests".
2. On a controller, an Interface is used when associated to a WLAN. The second step is therefore to create a WLAN on your Main Office controllers. Navigate to WLANs and click New.
In WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. These names can be different, but cannot contain any space. The term WLAN is used, but this network profile has nothing to do with wireless.
The General tab offers 2 drop down list: one "Ingress" and one "Egress". Ingress is the VLAN users come from (VLAN 50), Egress is the VLAN you want to send them to.
For Ingress, choose VLAN50. Easy. For Egress, things are a little more interesting. If you had only one controller, you would create another dynamic interface, a "standard" one
this time (i.e. NOT guest LAN), and you would send your wired users to this interface. In this case, we send them to the DMZ controller. So for the Egress interface, choose the Management Interface.
The Security mode for this Guest LAN "WLAN" is Web Auth, which is fine. Click Ok to validate.
3. From the WLAN list, click Mobility Anchor at the end of the Guest LAN line, and choose your DMZ controller. I am supposing here that both controllers know each others. If they do not know each other yet, go to Controller > Mobility Management > Mobility group, and add DMZWLC on WLC1, and similarly add WLC1 on DMZ. Both controllers do NOT need to be
in the same mobility group (actually they'd better NOT be! Otherwise you would be breaking basic security rules here).
4. Your Main Office controller is ready. You now need to prepare your DMZ controller. Open
a We
b browser session to your DMZ controller and navigate to WLANs.
Create a new WLAN.
Just like on the Main Office controllers, in WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. Use the same values as on the Main Office controller.
The Ingress interface here is None... It actually does not matter, as the traffic will be received through the EoIP tunnel, so this is why you do not need to specify any ingress interface.
The egress interface is the one on which the clients are supposed to be sent. Let's say
that the DMZ VLAN is VLAN9. Create a standard dynamic interface for VLAN 9 on your DMZWLC, then choose VLAN 9 as the egress interface.
You need to configure the end of the Mobility Anchor tunnel. From the WLAN list, choose Mobility Anchor for Guest LAN. Send the traffic to the local controller, DMZWLC.
Both ends are now ready.
5. You can also fine tune the WLAN settings on both ends. Be careful, settings are to be exactly the same on both ends. For example, if you choose to click, in the WLAN Advanced tab, "Allow AAA override" on WLC1, you need to check the same box on DMZWLC.
Any difference in settings in the WLAN on either side will make that the tunnel will break (DMZWLC will refuse the traffic, you can see that by running debug mobility).
Keep in mind that all values will actually be obtained from DMZWLC: IP addresses, VLAN values, etc. You configure the WLC1 side identically just for it to relay the request to the WLCDMZ..
Let’s put some certificates for the login page
What if you want to put your own certificate on the webauth page ? And what if you want to hide the fact that the webauth is on 1.1.1.1 and show a nice URL instead ?
Putting a certificate for the controller webauth :
Y ou can, either through the GUI (webauth -> certificate) or cli (transfer type “webauthcert”) upload a certificate on the controller. Whether it is a certificate you created with your CA or a 3rd party official certificate, it has to be in .pem format. Before sending, you will also have to enter the key of the certificate,
so don’t forget to ask it to the customer if you are using his certificate for a reproduction.
After the upload, a reboot is needed in order for the cert to be in place. Once rebooted, you can go to the webauth certificate page in the GUI and it will show you the details of the certificate you uploaded (validity and so on …). The important field is the CN (common name) which is the name the certificate was issued to. We will talk about this field later.
After this step, you will be presented with the new controller certificate when reaching the webauth login page. However, there can be two situations.
-If your certificate has been issued by one of the few main Root CAs that every computer trusts, then it’s ok. Y ou’re good to go. An example of these is Verisign. Y ou can check in your browser certificate store if you see the CA mentioned there as trusted. This is your ONL Y option if you are using 5.0 or older.
-If you got your certificate from a smaller company/CA (https://www.360docs.net/doc/2818035880.html, is another example) then not all computers in the world trust those. The trick is to provide the company/CA certificate as well to the client and hopefully that certificate will be issued by one of the root CAs. Eventually, you can end up with a chain like “my certificate has been issued by CA x -> Ca x certificate has been issued by CA y -> Ca y certificate has been issued by this root CA that everybody trusts”. The goal is to end up reaching a CA that the client will trust. This is ONL Y available from 5.1 and onwards.
Putting the CA certificate and all other certificates on the controller as well (5.1 and later):
In order to get rid of the “you don’t trust this certificate” warning, you have to put the certificate of the CA that issued the controller certificate on the controller as well. This way, the controller will present both certificates (his and his CA’s).
The CA certificate should be of a CA the client trust or has means to verify. Y ou can actually build a chain of CA certificates leading to a trusted CA on top.
What you have to do is to put the whole chain in the same file. This means your file will have a content such as this one :
BEGIN CERTIFICATE ------
?device certificate*
END CERTIFICATE ------
BEGIN CERTIFICATE ------
?intermediate CA certificate*
END CERTIFICATE ------
BEGIN CERTIFICATE ------
?Root CA certificate*
END CERTIFICATE ------
Getting the certificate name to match with the URL :
The problem remaining now is that you will be on “1.1.1.1” in order to authenticate yourself and the certificate is issued to (this is the CN field of the WLC certificate, remember ?) “https://www.360docs.net/doc/2818035880.html,” … which is quite not “1.1.1.1”. The way to correct this is to go into the virtual interface configuration (the
1.1.1.1 interface) and there you can enter a virtual dns hostname. This will replace the “1.1.1.1” in your URL bar. So the idea is to put https://www.360docs.net/doc/2818035880.html, there. But it’s not only a name trick, it has to be resolvable as well. We’ll see in the sniffer trace coming with this chunk how it all works in the end but when sending the login page, WLC says it’s at the address “https://www.360docs.net/doc/2818035880.html,” and the client will resolve this name with his DNS. This name should end up being
resolved as 1.1.1.1. This means that if you also use a name for the management
of the WLC you should use a different one for webauth. Meaning if you us “https://www.360docs.net/doc/2818035880.html,” as being mapped to the wlc management ip address,
for the webauth you will have to come up with a different name for it (like “https://www.360docs.net/doc/2818035880.html,”).
Troubleshooting certificate issues :
There is a main thing to check when having certificate issue and a main way to check it.
How to check : -Y ou can download OpenSSL (if you’re a windows user, search for OpenSSL Win32 …) and install it. Without any configuration you can go in the
bin directory and try “openssl s_client –connect https://www.360docs.net/doc/2818035880.html,:443. Provided that this URL is the URL where your auth web page is linked on your
DNS. An example of output is put at the end of this paragraph
What to check: -The thing is that you can see what certificates are sent to the
client when he connects. Read the device certificate: its CN should be the URL
where the web page is reachable at. Read the “issued by” line of the device certificate. This has to match the CN of the second certificate. Then this second certificate “issued by” has to match the CN of the next one … and so on and son
… Otherwise, it’s not making a real chain In the following OpenSSL output, you
can see that openssl cannot verify the device certificate because its “issued by”
is not matching the name of the CA certificate provided …
Loading 'screen' into random state - done CONNECTED(00000760) depth=0 /
O=
verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /
O=
error:num=27:certificate not trusted verify return:1 depth=0 /O=
OU=Domain Control Validated/CN=
the first certificate verify return:1 --- Certificate chain
0 s:/O=
69287
1 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class
2 Certification Authorit
y
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authorit
y --- Server certificate
BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIDRc2iMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV ?output cut*
YMaj/NACviEU9J3iot4sfreCQSKkBmjH0kf/Dg1l0kmdSbc=
END CERTIFICATE-----
subject=/O=
issuer=/C=US/ST=Arizona/L=Scottsdale/O=https://www.360docs.net/doc/2818035880.html,, Inc./OU=http://certificates.
https://www.360docs.net/doc/2818035880.html,/repository/CN=Go Daddy Secure Certification Authority/serialNumber=0
7969287 --- No client certificate CA names sent --- SSL handshake has read 2476 bytes and
written 322 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024
bit Compression: NONE Expansion: NONE SSL-Session:
Protocol : TLSv1 Cipher : AES256-SHA Session-ID: A32DB00A7AB7CD1CEF683980F3696C2BBA31A1453324F711F50EF4B Session-ID-ctx: Master-Key: C95E1BDAC7B1A964ED7324955C985CAF186B92EA34CD69E105F95D969D557E19
939C6A77C72350AB099B3736D168AB22
Key-Arg : None Start Time: 1220282986 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate)
---
Another high possibility of issue is “certificate cannot be uploaded to the controller”. In this situation there’s no question of validity, CA or whatever. It’s
just the certificate not going through.
Of course, checking TFTP connectivity (by trying to transfer a config or
something) is the first step. Then, usually, if you try a “debug transfer all
enable”, you will see the problem is actually in installing the certificate.
This could be due to the customer providing the wrong key to use with the certificate. It could
also be the certificate is in a wrong format or has something wrong with it.
A good idea is to compare the certificate content to a certificate you know is
valid. This allows for example to spot if a “LocalkeyID” attribute is showing all
0s (already happened), the certificate should be re-converted. Here are 2 nice
commands with OpenSSL allowing you to return from .pem to .p12 and then re-issue a .pem with the key of your choice :
Pre-step : If you received a .pem containing a certificate followed by a key => copy/paste the key part (----BEGIN KEY ---- until ------- END KEY ------....) from the .pem into "key.pem" openssl pkcs12 -export -in certificate.pem -inkey key.pem -out newcert.p12
Y ou will be prompted with a key, enter “check123”
openssl pkcs12 -in newcert.p12 -out workingnewcert.pem -passin pass:check123 -passout pass:check123
And ... there you go :-) A working .pem with password "check123"
Troubleshooting : things to check before crying
-Although mobility anchor has not been discussed in this document, if you are in an anchored guest situation, make sure the mobility exchange is happening fine and that you see the client arriving on the anchor. Any further webauth problem will be troubleshooted on the anchor.
Users cannot associate to the guest wlan :
Nothing to do with the web authentication here. Check the client configuration, the security settings on the WLAN, if it is enabled, if radios are up ….
Users don’t obtain IP address :
In a “guest anchor” situation this is most often due to the foreign and anchor not being exactly configured the same way.
Otherwise, check DHCP configuration, connectivity, … can other WLANs use the same DHCP server without problem ?
This has still nothing to do with the web authentication.
User is not redirected to the login page :
This is the most common symptom. But you have to precise a bit more. Either the user is not redirected (i.e. he types a URL and never ends up going to the webauth page) either the user is redirected to 1.1.1.1 correctly but the page itself does not appear.
For the first situation, check that a valid DNS server has been assigned to the client via DHCP (“ipconfig /all”), check that the DNS is reachable from the client (‘nslookup https://www.360docs.net/doc/2818035880.html,”), check that the user entered a valid URL in order to be redirected, check also that the user was going on a HTTP url on port 80 (for example, reaching an ACS with http://localhost:2002 will not get you redirected since you are sending on port 2002 instead of 80).
For the second situation, it is most likely either a WLC problem (bug) or a client-side problem. It could be that the client has some firewall or blocking software or policy. It could be that they have configured a proxy in their web browser …
Important thing here. It might be a good idea to take a sniffer trace on the client PC. No need for special wireless software, a simple wireshark ran on the wireless adapter will show you if at least the WLC is replying and trying to redirect. You have two possibilities : either WLC is not replying, either the SSL handshake for the webauth page is going wrong. For the second, you can check if the user browser allows for SSLv3 (some only do sslv2) and if it could be too aggressive on certificate verification.
It is a common step to try to manually type http://1.1.1.1 to check if the webpage appears without worrying about DNS. Actually, you could type http://6.6.6.6 and get the same effect. Any ip address you ask will be redirected by the WLC. So typing http://1.1.1.1 will actually not make you work around the web redirection. Typing httpS://1.1.1.1 will not work because WLC can redirect based on https traffic. Typing https://1.1.1.1/login.html IS actually the way to get the page directly without doing any redirection.
Users cannot authenticate :
See the section talking about authentication. Check credentials locally … on the radius …
Users can authenticate through webauth fine but they don’t have internet access afterwards :
See the following point.
When having a doubt :
Y ou can actually remove webauth from the security of the WLAN and then you should have an open WLAN. Y ou can then try to access the web, the DNS and
the rest. If you are experiencing issues there as well … take webauth out of the picture and check back your interfaces configuration.
What if I'm using an HTTP proxy server ? How is it going to work ?
First : yes that can work. Second, let's summarize what is needed :
-You basically need the client to add an exception in his browser that "1.1.1.1" is not to go through the proxy server.
-Make the WLC to listen for HTTP traffic on the port of the proxy server (8080 usually)
To understand the scenario, let's shortly go over what an HTTP proxy is doing.
It's something you configure on client side (ip address and port) in the browser.
Usual scenario when visiting a website is "resolving the name to ip with DNS, then asking the web page to the web server". The process now is "sending the http request for the page to the proxy, no matter what. The proxy will take care of the DNS if required and will forward to the web server (if page is not cached already on the proxy). The discussion is basically client to proxy only. Whether or not the proxy goes to fetch the real web page, the client cares very little about that.
This means that for the web authentication process :
-User types in a URL
-Client PC sends towards the Proxy server.
-WLC intercepts and spoofs Proxy server ip, it will reply to the PC with a redirect to 1.1.1.1
At this stage, if PC is not configured for it, it will ask for the 1.1.1.1 web auth page to ... the proxy so it's not going to work there ...
We need the PC to make an exception for 1.1.1.1. Then it will send a HTTP request to
1.1.1.1 and will proceed with web auth. Once authenticated all communications will go through proxy again.
Configuring an exception is usually in the browser close to the configuration of the proxy server. You should see "Don't use proxy for those ip addresses :".
Hey, I don't want to be bothered with certificates (i.e. doing webauth over HTTP and not HTTPS)
Is it possible to login on web authentication without being on https ? thus not receiving certificates alerts ?
Yes it is.
You simply need to disable HTTPS management of the WLC and just leave HTTP management.
This obviously has the side effect of only allowing the web management of the WLC over http only.
This bug CSCsy32145 is an enhancement request to have the webauth over http/https differentiated with web administration of WLC.