Cisco WLC - No secured WebUI after failover switching

Table of contents

  1. Cisco WLC Web-UI problems after failover
  2. Check redundancy summary
  3. Port scan of Web-UI
  4. Check TLS certificate
  5. 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
    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
    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).