I'm setting up new Guest Wireless, I have 2 internal foreign 5508 WLC's talking to 2 DMZ anchor WLC's. The guest connects to Guest SSID and the anchor controllers acts as a DHCP server, the Guest interface configured on the WLC is the in the range of the DHCP scope I've setup. The DHCP scope is using the anchor WLC Mgmt interface as the DHCP server.
Guest SSID - is setup for Webauth and Guest is redirected to the ISE server https://wlc.company.com/login...., when the page is presented to the Guest they get cert problem because the cert is not trusted (its an Internal Cert), Guest logins in ok and the AUP says "cert not trusted" 126.96.36.199 name of the WLC wlc.company.com.
In the browser Guest has https://wlc.company.com/loginredirecthttps://188.8.131.52........
184.108.40.206 is the Virtual interface of the Anchor WLC.
How can I get the client to stop using the Virtual Interface for cert. Why is the WLC doing this? I gather something to do with DHCP?
My plan is to apply a External Cert on the ISE for Guests, that way they will automatically trust a cert from Geotrust for example. But I'm going to still run into this Cert "not trusted" problem where the Guest is not trusting the WLC anchor Virtual Interface 1.1.1 . Why is the guest using the Virtual interface error 220.127.116.11. I've even added the ISE name of the cert to the Virtual interface, same problem, instead its just says wlc.company.com not trusted. I have also imported the cert onto the WebAuth cert on anchor WLC, still doesn't work.
Hopefully I've explained this ok.....any ideas? but if the Guest page keeps getting presented with
https://wlc.company.com/loginredirecthttps://18.104.22.168........ it will never work.
Your writing implies you're trying to use ISE to host the WebAuth page(?) in which case your Config is wrong. If you want to use CWA on the ISE, you do not specify a redirect URL under the WLAN's Layer3 settings at all, you just enable MAB, AAA Override, RADIUS-NAC and a Pre-Auth ACL on the WLAN, and you setup the ISE to do CWA.
There's a lot of detailed guidance about this in various Config Guides and in the SRNDs.
Once implemented, the Virtual Interface is not used on the WLC, which avoids the error message you're seeing. It does still require the use of an SSL Cert on the ISE, so you'll need to give it a publicly registered DNS Name and a Cert signed by a Public Trusted CA for that DNS entry.
Sent from Cisco Technical Support iPad App
Sent from Cisco Technical Support iPad App
I beg to disagree with Richard. If you're doing MAB, you don't need to create a pre-authentication ACL. Pre-authentication ACL is only required for Layer 3 web authentication when using redirect to an external server. The redirect URL is specified under the Security Tab --> Web Login page sub menu.
Stephen, from your description, you're using a Layer 3 webauth, so you need to ensure you have a pre-auth ACL set on the WLAN Layer3 setting. Also ensure that the Radius server under WLAN security setting points to the ISE Server IP address.
Concerning the cert error, note that the public signed certificate which is required as suggested by Richard should be imported to the ISE and not the Anchor WLC as it is the ISE that presents the web portal page.
You need a pre-auth ACL to be defined on the Anchor WLC and it needs to allow TCP 8443 to the ISE. This ACL is then referenced by name in the ISE Authz Profile. When the User performs their initial MAB, the ISE returns the Redirect URL and the ACL Name to the WLC, both of which are then imposed upon the User in order to get them to see the ISE's login page.
There's no need for any "Layer3 Security" configuration in the WLC whatsoever.
I have a Preauthentication ACL applied to Layer 3 SSID, which includes the ISE IP address.
However instead of the using the ISE IP address I have the URL the customer sees in the browser which then gets NATed on the Firewall back to ISE. Does this have to be the IP address or can you use a FQDN. This FQDN has a DNS lookup on the DMZ even though the ISE is on the Internal Network. Both DNS network and Guest network use Firewall as default Gateway.
I don't want to sound too rude here, but I think you're probably better off deleting all of your config, reading the SRND and ISE Config Guides, and starting again from scratch.
Look at it this way. You can use either MAB or Layer 3 web auth for guest access. In this case you're using Layer 3 web auth, hence the need for a redirect URL. MAB doesn't require redirect URL. It doesn't matter if you specify the IP address or DNS resolvable name in the External Server redirect column.
I wouldn't advise that you do your config from scratch as your clients are getting redirected to the Web auth page, which means that your set up is working. Your concern is the cert error, isn't it? Then all you have to do is to obtain a public cert from Verisign or whatever vendor of your choice and import to the ISE. If the anchor controller will be presenting the web auth page, then the cert has to be imported to the anchor.
Some clarification about MAB and Layer 3 Web Auth. In Layer 3 web auth the pre-authentication ACL is specified on the layer 3 security setting as you have rightly done. For MAB, the ACL created is applied in the advanced tab under the "Override Interface ACL". Now the big question is with MAB, will the local WLC forward the clients requests to the Anchor WLC. I don't think so, as MAB is basically Layer 2, hence the authentication requests are sent directly from the local WLC to the ISE.
I followed Richard's advice and started from scratch, removing LWA and implementing CWA -MAB. It didn't take too long to setup CWA and get authentication working, I appled a Preauth ACL on WLC's and on ISE under Authorization pofile (CWA)
This is when the problems started happening, I was using the default ISE Authorization profile
cisco-av-pair = url-redirect=https://ip:8443/guestportal/gateway?sessionid=SessionValueIdValue&action=cwa.which is not what I want, again the certificate is the server cert which is not an external Cert that the guest wants to see. The user can login fine, unlike LWA, with Firefox or IE it would accept the cert and login so at least I had a working Guest wifi solution. Though there was a cert error symbol at the end of the browser url.
The next step I tried was to change the Authorization Profile to
(wireless.company.com which is a C-NAME for ISE box and has this Alias in the cert, this was a test before I apply the external cert)
cisco-av-pair = url-redirect=https://wireless.company.com:8443/guestportal/gateway?sessionid=SessionValueIdValue&action=cwa
I applied the change and the new page appeared on the users laptop, great, but this time users were declined access via live Authentications, reason "Cannot login due to session id expiry, please login a again", I created a new user a/c, same problem. Not good. Ok so I thought well if I want clear all these stale session id's that appartenly exist I'll stop/start the application which I did from the command line, still the same error "Cannot login due to session id expiry". hmmm, whats going on here.
I then rebooted the ISE (this must clear all the sessions!), reboot I performed from home and now for some reason I cannot login to the ISE front end GUI with the admin account or my account. Tried resetting the GUI password for admin and other admin users, the message "Error: cannot reset password this can only be performed on Standalone or Primary node" Well what have I done, just rebooted ISE nothing else apart from changing authorization profile. This box is a Standalone node. Without seeing if the clients connect due t no GUI access, I have referred this issue to TAC!
Also I don't like the fact that your have to install a external cert against the internal node name, epsecially when its external. But again I haven't reached this part yet.
TAC engineer confirmed my database was corrupted, reason for me not been able to login to the admin GUI. We completed a restore from a backup, this worked successfully and I was able to login via GUI, Guests authentication started working again.
Now in regards to exposing internal FQDN cert to Guests, there is no way around this in versions prior to 1.2. There is a new redirect functionality you can use in 1.2 to redirect Guests to an alternate URL (its in the release notes, have a read)
Please note changing the cisco-av-pair like I did to stop exposing a FQDN host and use a C-NAME will not work in a Standalone setup.
So this weekend I will upgrade to 1.2 with latest patch. I still just do not understand why you should have to expose internal cert details to an external guest this is not normal practice in my view, even with an external Cert the user can check the cert details and view the ISE FQDN. To me that is a Security hole, TAC engineer agreed.
I upgraded from 1.1.3 to ISE 1.2 patch 2. Was a straight forward upgrade, though there were a couple of things:
Or other configuration information migrated ok.
I've tested the Web re-direct and this works well, nice addition to 1.2