Table of contents
- Cisco WLC Web-UI problems after failover
- Check redundancy summary
- Port scan of Web-UI
- Check TLS certificate
- Create self-signed TLS certificate
Cisco WLC Web-UI problems after failover
One of my coworkers discovered a strange problem with two newly installed Cisco’s 3504 Wireless Controllers. Both Wireless Controllers are running in a failover (SSO) setup. When the Primary Unit is active, the WebUI of the Wireless Controller at the management IP is reachable. When the failover is switched to the Secondary Unit, the WebUI at the management IP was gone and only a login with SSH (and HTTP) was possible.
Check redundancy summary
To check the problem I logged in into the WLC and verified the redundancy summary:
(Cisco Controller) >show redundancy summary Redundancy Mode = SSO ENABLED Local State = ACTIVE Peer State = STANDBY HOT Unit = Secondary (Inherited AP License Count = nnn) Unit ID = hh:hh:hh:hh:hh:hh Redundancy State = SSO Mobility MAC = hh:hh:hh:hh:hh:hh Redundancy Port = UP BulkSync Status = Complete
Port scan of Web-UI
To check what services are running on the Secondary Unit, I did a port scan with nmap. As shown in the nmap scan output, the port TCP/443 for the secured WebUI (HTTPS) is closed.
Nmap scan report for wlc.domain.tld (nnn.nnn.nnn.nnn) Host is up (0.085s latency). Not shown: 996 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp closed https 16113/tcp open unknown
To compare the scan result with the Primary Unit (where the secured WebUI was working) I did a redundancy force-switchover, which restarts the Secondary Unit and makes the Primary Unit the active one.
(Cisco Controller) >redundancy force-switchover This will reload the active unit and force a switch of activity. Are you sure? (y/N) y System will now restart!
A nmap port scan against the management IP (in this case the Primary Unit), the scan result shows now that the port for TCP/443 for the secured WebUI is open. The WebUI in a Browser is responding as well and showing the login dialog.
Nmap scan report for wlc.domain.tld (nnn.nnn.nnn.nnn) Host is up (0.100s latency). Not shown: 996 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 16113/tcp open unknown
Check TLS certificate
Because TCP/443 on the Secondary Unit was shown as “closed” in the nmap port scan, my assumption was that the certificate required for HTTPS was not generated or that the secured WebUI was not enabled. A check with show certificate webadmin showed that on the Secondary Unit no certificate was generated or present.
Create self-signed TLS certificate
Therefore I created a self-signed certificate on the Secondary Unit and enabled the secure WebUI as shown below.
(Cisco Controller) >config certificate generate webadmin Creating a certificate may take some time. Do you wish to continue? (y/n) y Web Administration certificate has been generated (Cisco Controller) >config network secureweb enable (Cisco Controller) >config network secureweb cipher-option high enable (Cisco Controller) >save config Are you sure you want to save? (y/n) y Configuration Saved!
A switching between Primary Unit and Secondary Unit shows now that both Units are responding to the secured WebUI at TCP/443. My assumption is that when a PKI-signed certificate is rolled out on the Wireless Controller, both Units get synced and use the PKI-signed certificate. (Not tested yet).