Cisco WLC - No secured WebUI after failover switching

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.

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
3504 WLC: Secondary Unit active, Primary Unit Standby Hot

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
3504 WLC: nmap scan when Secondary Unit is active

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!
3504 WLC: Switching from Secondary to Primary Unit

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
3504 WLC: nmap scan when Primary Unit is active

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.

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!
3504 WLC: Generate certificate and enable secured WebUI

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).


Share: