Cisco WiSM Config Practice Opens SVI Vulnerability
Thursday, October 7, 2010 at 9:12PM

Cisco’s recommend WiSM configuration practice will make you vulnerable – by George Stefanick

I was asked, “The WiSM Config Practice has been out for years, how did you find this ?” The devil is in the details.... 

WiSM Configuration Practice

The initial steps in configuring a Cisco WiSM is what I like to call a “configure-and-forget” step. This is because once the WiSM is configured and married to the backplane of the Sup720 via the “service port” its rare one would need to revisit this procedure again.

There are a number of Cisco WiSM Configuration guides available at explaining this process. We will get into these in a bit… 

What is the WiSM “service port”?

First lets understand what the service port interface is and the purpose of the service port. The WiSM service port is one of many ports on a Cisco WiSM. They include the management, ap manager, virtual, service and the operator dynamic interfaces.

Cisco’s 4400 and 5500 model controller’s service port is used for out-of-bandwidth management. The service port is a physical port supported on these models, whereby allowing you physical access with a console / null modem cable.

Contrary to the service port on the 4400 and  5500’s models. The WiSM service port is NOT used for out-of-bandwidth management. Rather it is used to synchronize the supervisor engine (720) and the WiSM. 

How does the “service port” on the Cisco WiSM connect to the Sup720?

Once the WiSM is installed, you enter the Sup720 and create a local vlan for the purpose of communications between both the WiSM and the Sup720.  Cisco references vlan 192 in their WiSM config documents, but of course any vlan number can be used. 

Cisco’s WiSM Configuration documentation goes a step further and states to create an SVI interface. An SVI interface is a gateway to bridge traffic. (Here in lies the problem. I will cover in more detail in the next section.)

(See below reference and links to Cisco WiSM configuration Guides, note the SVI interface recommendations and the lack of an ACL) 

The Vulnerability

The Cisco WiSM Configuration Guides detail the creation of an SVI interface for the purpose of the service port interface. For example;

Sup720(config)# interface Vlan 192
Sup720(config-if)# ip address
Sup720(config-if)# no shutdown
Sup720(config-if)# exit

The Cisco WiSM Guides makes no reference to an ACL which would restrict traffic access to the service port SVI interface. By creating the SVI interface you have a “connected route” from users who terminate to the 6500 to reach the SVI interface. This would include wired and wireless users. Essentially, inside users have access to the WiSM service port. This would also include wireless guest!

Lets follow the packet:

1)     Wireless client pings

2)     The packet egresses the wireless client and 802.11 headers are applied

3)     The packet travels via RF

4)     Packet reaches Access Point

5)     Access points encapsulates the packet in a LWAPP/CAPWAP headers

6)     The packet is then sent to the Cisco WiSM / Controller

7)     The WiSM removes the LWAPP/CAPWAP encapsulation and adds 802.3 headers

8)     The WiSM places the packet on the wired

9)     The packet transverses the router to the connected SVI interface


I’m positive this is an oversight by Cisco. Recent conversations with Cisco SE’s, Cisco TAC and other peers agree this is an issue on many levels.

Engineers and Admins who configure the WiSM for the first time or perhaps engineers who have little knowledge would follow the Cisco WiSM Configuration Guide step by step. Not understanding that an ACL needs to be applied to the SVI interface for the WiSM service port. 

Real World Examples:

Lets cover why this is an issue with some real world examples:

Example#1 –

Your inside networks are 10.x.x.x and 172.x.x.x. Your service port on the WiSM is configured for 192.168.10.x network. Users who terminated to the cat / Sup 720 that houses the WiSM has access to the SVI interface 192.168.10.x. Why, because it is a connected route. The traffic will bridge over from 10 / 172  to the 192 network.


Example#2 –

Suppose you don’t have a Cisco WLC to anchor guest traffic. Your wireless guest traffic terminates to the  cat / Sup720 that houses the WiSM. Let suppose you ACL your "GUEST" SVI interface denying your known inside networks. You think you are done and call it a day.

DENY (inside network)

But did you remember to deny 192.168.10.x? If you didn’t your wireless guest now have access to your service port

How to Fix it:

If you configured an SVI interface. Simply ACL the SVI not to allow ANY network access to this SVI interface.  


I admit this isn’t a five-alarm hole. You don’t have to drop everything you are doing.  But it is one that needs to be addressed if you followed Cisco WiSM Configuration Guides.


Cisco links to WiSM Config

! - Create a vlan in the Supervisor 720, this vlan is local to the chassis and is used for

communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit interface on

the Supervisor and service-port in the Cisco WiSM. 

Sup720(config)# vlan 192 

! -- Assign an appropriate IP address and subnet mask for VLAN 192 

Sup720(config)# interface Vlan 192

Sup720(config-if)# ip address

Sup720(config-if)# no shutdown

Sup720(config-if)# exit

Create the WiSM Service Port Gateway and assign the IP address.

Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit Interface on the Supervisor and a service port in the Cisco WiSM.

interface Vlan192 
Description WiSM Service Port Gateway or Management Interface on CAT6K
ip address 



Article originally appeared on (
See website for complete article licensing information.