Solutions

This chapter describes application-specific solutions for wireless LANs. Solutions are described in these sections:

Cisco WLAN Solution Security

Security Overview

The Cisco WLAN Solution Security solution bundles potentially complicated Layer 1, Layer 2, and Layer 3 802.11 Access Point security components into a simple policy manager that customizes system-wide security policies on a per-WLAN basis. The Cisco WLAN Solution Security solution provides simple, unified, and systematic security management tools.

One of the biggest hurdles to WLAN deployment in the enterprise is WEP encryption, which is weak standalone encryption method. A newer problem is the availability of low-cost access points, which can be connected to the enterprise network and used to mount man-in-the-middle and denial-of-service attacks. Also, the complexity of add-on security solutions has prevented many IT managers from embracing the benefits of the latest advances in WLAN security.

Layer 1 Solutions

The Cisco WLAN Solution Operating System Security solution ensures that all clients gain access within an operator-set number of attempts. Should a client fail to gain access within that limit, it is automatically excluded (blocked from access) until the operator-set timer expires. The Operating System can also disable SSID broadcasts on a per-WLAN basis.

Layer 2 Solutions

If a higher level of security and encryption is required, the network administrator can also implement industry-standard security solutions, such as: 802.1X dynamic keys with EAP (extensible authentication protocol), or WPA (Wi-Fi protected access) dynamic keys. The Cisco WLAN Solution WPA implementation includes AES (advanced encryption standard), TKIP + Michael (temporal key integrity protocol + message integrity code checksum) dynamic keys, or WEP (Wired Equivalent Privacy) static keys. Disabling is also used to automatically block Layer 2 access after an operator-set number of failed authentication attempts.

Regardless of the wireless security solution selected, all Layer 2 wired communications between Cisco Wireless LAN Controllers and Cisco 1000 Series lightweight access points are secured by passing data through LWAPP tunnels.

Layer 3 Solutions

The WEP problem can be further solved using industry-standard Layer 3 security solutions, such as VPNs (virtual private networks), L2TP (Layer Two Tunneling Protocol), and IPSec (IP security) protocols. The Cisco WLAN Solution L2TP implementation includes IPsec, and the IPSec implementation includes IKE (internet key exchange), DH (Diffie-Hellman) groups, and three optional levels of encryption: DES (ANSI X.3.92 data encryption standard), 3DES (ANSI X9.52-1998 data encryption standard), or AES/CBC (advanced encryption standard/cipher block chaining). Disabling is also used to automatically block Layer 3 access after an operator-set number of failed authentication attempts.

The Cisco WLAN Solution IPSec implementation also includes industry-standard authentication using: MD5 (message digest algorithm), or SHA-1 (secure hash algorithm-1).

The Cisco WLAN Solution supports local and RADIUS MAC (media access control) filtering. This filtering is best suited to smaller client groups with a known list of 802.11 access card MAC addresses.

Finally, the Cisco WLAN Solution supports local and RADIUS user/password authentication. This authentication is best suited to small to medium client groups.

Single Point of Configuration Policy Manager Solutions

When the Cisco WLAN Solution is equipped with Cisco WCS, you can configure system-wide security policies on a per-WLAN basis. SOHO Access Points force you to individually configure security policies on each access point, or use a third-party appliance to configure security policies across multiple access points.

Because the Cisco WLAN Solution security policies can be applied across the whole system from the Cisco Wireless Control System, errors can be eliminated and the overall effort is greatly reduced.

Rogue Access Point Solutions

Rogue Access Point Challenges

Rogue access points can disrupt WLAN operations by hijacking legitimate clients and using plaintext or other denial-of-service or man-in-the-middle attacks. That is, a hacker can use a rogue access point to capture sensitive information, such as passwords and username. The hacker can then transmit a series of clear-to-send (CTS) frames, which mimics an access point informing a particular NIC to transmit and instructing all others to wait, which results in legitimate clients being unable to access the WLAN resources. WLAN service providers thus have a strong interest in banning rogue access points from the air space.

The Operating System Security solution uses the Radio Resource Management (RRM) function to continuously monitor all nearby access points, automatically discover rogue access points, and locate them as described in the "Tagging and Containing Rogue Access Points" section.

Tagging and Containing Rogue Access Points

When the Cisco WLAN Solution is monitored using WCS, WCS generates the flags as rogue access point traps, and displays the known rogue access points by MAC address. The operator can then display a map showing the location of the Cisco 1000 Series lightweight access points closest to each rogue access point, allowing Known or Acknowledged rogue access points (no further action), marking them as Alert rogue access points (watch for and notify when active), or marking them as Contained rogue access points (have between one and four Cisco 1000 Series lightweight access points discourage rogue access point clients by sending the clients deauthenticate and disassociate messages whenever they associate with the rogue access point).

When the Cisco WLAN Solution is monitored using a GUI or a CLI, the interface displays the known rogue access points by MAC address. The operator then has the option of marking them as Known or Acknowledged rogue access points (no further action), marking them as Alert rogue access points (watch for and notify when active), or marking them as Contained rogue access points (have between one and four Cisco 1000 Series lightweight access points discourage rogue access point clients by sending the clients deauthenticate and disassociate messages whenever they associate with the rogue access point).

Integrated Security Solutions

•

Cisco WLAN Solution Operating System Security is built around a robust 802.1X AAA (authorization, authentication and accounting) engine, which allows operators to rapidly configure and enforce a variety of security policies across the Cisco WLAN Solution.

•

The controllers and lightweight access points are equipped with system-wide authentication and authorization protocols across all ports and interfaces, maximizing system security.

•

Operating System Security policies are assigned to individual WLANs, and lightweight access points simultaneously broadcast all (up to 16) configured WLANs. This can eliminate the need for additional access points, which can increase interference and degrade system throughput.

•

The controllers securely terminates IPSec VPN clients, which can reduce the load on centralized VPN concentrators.

•

Operating System Security uses the RRM function to continually monitor the air space for interference and security breaches, and notify the operator when they are detected.

•

Operating System Security works with industry-standard aaa (authorization, authentication and accounting) servers, making system integration simple and easy.

•

The Operating System Security solution offers comprehensive Layer 2 and Layer 3 encryption algorithms which typically require a large amount of processing power. Rather than assigning the encryption tasks to yet another server, the controller can be equipped with a VPN/Enhanced Security Module that provides extra hardware required for the most demanding security configurations.

Converting a Cisco WLAN Solution from Layer 2 to Layer 3 Mode

When you need to convert a Cisco WLAN Solution from Layer 2 to Layer 3 Mode, use one of the procedures in this section:

Using the Web User Interface to Convert from Layer 2 to Layer 3 Mode

Follow the steps in this section to convert a Cisco WLAN Solution from Layer 2 to Layer 3 LWAPP Transport Mode using the GUI on a wireless LAN controller.

Note This procedure causes your lightweight access points to go offline until the controller reboots and the associated access points reassociate with the controller.

Note Layer 3 Mode requires that all subnets that the controllers are connected to include at least one DHCP server. When you have completed this procedure, the controller stores its IP address in its associated access points. When each access point is powered up, it obtains an IP address from the local DHCP server and connects to its Primary, Secondary, or Tertiary controller.

Note Layer 3 Mode requires that all subnets that contain controllers and lightweight access points are routable to each other.

Step 1

To use the Cisco WLAN Solution in Layer 3 mode, you must create an AP Manager Interface, which manages communications between each controller and its associated access points. This AP Manager Interface will require a fixed IP address, which must be different from the Management Interface IP address, but which can be on the same subnet as the Management Interface.

Step 2

Make sure that all the controllers and access points are on the same subnet: that they are only connected through Layer 2 devices.

Note You must configure the controllers and associated lightweight access points to operate in Layer 3 mode before completing the conversion.

Step 3

Verify that the access points are assigned to the correct controller. If you do not complete this step, the access points will fail to associate with the controller after completing the conversion.

In the Web User Interface, select WIRELESS/Cisco APs to navigate to the Cisco APs page, and click Detail to display the Cisco APs > Details page.

On the Cisco APs > Details page for each access point, verify that the Primary, Secondary, and Tertiary Controller Names are correct. If you change the Primary, Secondary, or Tertiary Controller Names, click Apply to save the change to the access point.

Step 4

Select WIRELESS/Cisco APs to navigate to the Cisco APs page, and make sure that all the lightweight access points are listed before you continue with the next step.

Note

If you do not complete this step, the access points might not associate with the controller after completing the conversion.

Select CONTROLLER/General to navigate to the General page, and change Layer 2 LWAPP Transport Mode to Layer 3.

Click Apply to send the changes to the controller and to the associated access points. Click OK to continue.

Step 6

Select COMMANDS/Reboot to navigate to the System Reboot page, and click Reboot to display the Reboot System > Save? page.

Step 7

In the Reboot System > Save? page, click Save and Reboot to have the Operating System save the new configuration to and reboot the controller. The Cisco Wireless LAN Controller reboots.

Step 8

Select CONTROLLER/Interfaces to navigate to the Interfaces page, and verify that the Operating System has automatically added the ap-manager interface.

Step 9

Configure the ap-manager interface. In the Interfaces page, click the ap-manager Interface Edit button to have the Web User display the Interfaces > Edit page. In the Interfaces > Edit page:

•

Enter the physical port number for the Distribution System connection to the Cisco Wireless LAN Controller.

•

Enter a Secondary DHCP Server IP address. (This can be the same as the Primary DHCP Server IP address if you do not have a second DHCP server on this subnet.)

•

Click Apply to add the edited AP Manager Interface definition to the list of interfaces.

Step 10

From the Interfaces page, verify that the management interface is properly configured with a different IP Address than the ap-manager interface.

Select COMMANDS/Reboot to navigate to the System Reboot page, and select Reboot.

On the Reboot System > Save page, click Save and Reboot to save the changes to and reboot the Cisco Wireless LAN Controller.

Step 12

After the Cisco Wireless LAN Controller has rebooted, select CONTROLLER/General to navigate to the General page, and verify that the LWAPP Transport Mode is set to Layer 3.

Step 13

Power down each Cisco 1000 Series lightweight access point to save the Layer 3 configuration to nonvolatile memory.

Step 14

Connect each Cisco 1000 Series lightweight access point to its final location in the network. Each Cisco 1000 Series lightweight access point connects to its Primary, Secondary, or Tertiary Cisco Wireless LAN Controller, downloads a copy of the latest Operating System code, and starts reporting its status to the Cisco Wireless LAN Controller. Note that this can take a few minutes for each Cisco 1000 Series lightweight access point.

You have completed the LWAPP Transport Mode conversion from Layer 2 to Layer 3. The ap-manager interface now controls all communications between Cisco Wireless LAN Controllers and Cisco 1000 Series lightweight access points on different subnets.

Using the Cisco WCS User Interface to Convert from Layer 2 to Layer 3 Mode

Follow the steps in this section to convert a Cisco WLAN Solution from Layer 2 to Layer 3 LWAPP Transport Mode using the GUI on the Cisco WCS.

Note This procedure causes your lightweight access points to go offline until the controller reboots and the associated access points reassociate with the controller.

Note Layer 3 Mode requires that all subnets that contain controllers and lightweight access points are routable to each other.

Step 1

To use the Cisco WLAN Solution in Layer 3 mode, you must create an AP Manager Interface, which manages communications between each Cisco Wireless LAN Controller and its associated access points. This AP Manager Interface requires a fixed IP address, which must be different from the Management Interface IP address, but which can be on the same subnet as the Management Interface.

Step 2

Make sure that all the Cisco Wireless LAN Controllers and Cisco 1000 Series lightweight access points are on the same subnet: that they are only connected through Layer 2 devices.

Note You must configure the Cisco Wireless LAN Controllers and associated Cisco 1000 Series lightweight access points to operate in Layer 3 mode before completing the conversion.

Step 3

In the Cisco WCS User Interface, select CONFIGURE/Access Points to navigate to the All Access Points page, and verify that the Primary, Secondary, and Tertiary Controller Names are correct for all Cisco 1000 Series lightweight access points. If you change the Primary, Secondary, or Tertiary Controller Names, click Apply to save the change to each Cisco 1000 Series lightweight access point.

Step 4

Select CONFIG/Access Points to navigate to the All Access Points page, and MAKE SURE that the access points are associated with the controller before you continue with the next step.

If you do not complete this step, the Cisco 1000 Series lightweight access points might fail to associate with the controller after completing the conversion.

Select CONFIGURE/Controllers to navigate to the All Controllers page, and select the Cisco Wireless LAN Controller by IP address to have Cisco WCS display the <IP address> > Controller General page.

From the <IP address> > Controller General page, select System/Networking to display the <IP address> > Networking Setups page.

On the <IP address> > Networking Setups page, change Layer 2 LWAPP Transport Mode to Layer 3 and click Save.

Cisco WCS displays a Please reboot the system for the LWAPP Mode change to take effect message; click OK.

Select CONFIGURE/Controllers to navigate to the All Controllers page, and select the desired Cisco Wireless LAN Controller by IP address to have Cisco WCS display the <IP address> > Controller General page.

In the <IP address> > Controller General page, select System/Interfaces to have Cisco WCS display the <IP address> > Interface page.

In the <IP address> > Interface page, select System/Interfaces and then click GO to have Cisco WCS display a second <IP address> > Interface page.

–

Enter the physical port number for the Distribution System connection to the controller.

–

Enter a Secondary DHCP Server IP address. (This can be the same as the Primary DHCP Server IP address if you do not have a second DHCP server on this subnet.)

Use the browser Back button (ALT-Left Arrow) to return to the first <IP address> > Interface page, and verify that Cisco WCS has added the ap manager Interface Name to the list of Interfaces.

Step 7

From the first <IP address> > Controller General page, verify that the management interface is properly configured with a different IP Address than the ap manager interface.

Step 8

Save the new configuration and restart your Cisco Wireless LAN Controller:

Select the Cisco Wireless LAN Controller by IP address to have Cisco WCS display the <IP address> > Controller General page.

From the <IP address> > Controller General page, select System/Commands to display the <IP address> > Controller Commands page.

On the <IP address> > Controller Commands page, under Administrative Commands, select Save Config to Flash and click GO to save the changed configuration to the Cisco Wireless LAN Controller.

On the <IP address> > Controller Commands page, under Administrative Commands, select Reboot and click GO to reboot the Cisco Wireless LAN Controller. Then click OK to confirm the save and reboot.

Step 9

After the Cisco Wireless LAN Controller has rebooted, verify that the LWAPP Transport Mode is now Layer 3:

From the <IP address> > Controller General page, select System/Networking to display the <IP address> > Networking Setups page.

On the <IP address> > Networking Setups page, verify that the Current LWAPP Transport Mode is Layer 3.

Step 10

Select CONFIGURE > Access Points to navigate to the All Access Points page, and make sure that the access points are associated with the controller before you continue with the next step. If you do not complete this step, the access points might not associate with the desired controller after completing the conversion.

Step 11

Power down each access point to save the Layer 3 configuration to nonvolatile memory.

Step 12

Connect each access point to its final location in the network. Each access point connects to its Primary, Secondary, or Tertiary controller, downloads a copy of the latest Operating System code, and starts reporting its status to the controller. Note that this can take a few minutes for each access point.

You have completed the LWAPP Transport Mode conversion from Layer 2 to Layer 3. The ap-manager interface now controls all communications between controllers and access points on different subnets.

Converting a Cisco WLAN Solution from Layer 3 to Layer 2 Mode

When you need to convert a Cisco WLAN Solution from Layer 2 to Layer 3 Mode, use one of the procedures in this section:

Using the Web User Interface to Convert from Layer 3 to Layer 2 Mode

Follow the steps in this section to convert a Cisco WLAN Solution from Layer 3 to Layer 2 LWAPP Transport Mode using the GUI on a wireless LAN controller.

Note This procedure causes your lightweight access points to go offline until the controller reboots and the associated access points reassociate with the controller.

Step 1

Make sure that all the Cisco Wireless LAN Controllers and Cisco 1000 Series lightweight access points are on the same subnet: that they are only connected through Layer 2 devices.

Note You must configure the Cisco Wireless LAN Controllers and associated Cisco 1000 Series lightweight access points to operate in Layer 3 mode before completing the conversion.

Step 2

In the Web User Interface, select CONTROLLER/General to navigate to the General page, and change Layer 3 LWAPP Transport Mode to Layer 2. Then click Apply to send the changes to the Cisco Wireless LAN Controller. Click OK to continue.

Step 3

Select COMMANDS/Reboot to navigate to the System Reboot page, and select Reboot. On the Reboot System > Save page, click Save and Reboot to save the changes to and to reboot the Cisco Wireless LAN Controller. Then click OK to confirm the save and reboot.

Step 4

After the Cisco Wireless LAN Controller has rebooted, select CONTROLLER/General to navigate to the General page, and verify that the current LWAPP Transport Mode is set to Layer 2.

Step 5

Also select CONTROLLER/Interfaces to navigate to the Interfaces page, and verify that the ap-manager interface is removed from the list of Interface Names.

You have completed the LWAPP Transport Mode conversion from Layer 3 to Layer 2. The Operating System software now controls all communications between controllers and access points on the same subnet.

Using the Cisco WCS User Interface to Convert from Layer 3 to Layer 2 Mode

Follow the steps in this section to convert a Cisco WLAN Solution from Layer 3 to Layer 2 LWAPP Transport Mode using the GUI on the Cisco WCS.

Note This procedure causes your lightweight access points to go offline until the controller reboots and the associated access points reassociate with the controller.

Step 1

Make sure that all the controllers and lightweight access points are on the same subnet: that they are only connected through Layer 2 devices.

Note You must configure the Cisco Wireless LAN Controllers and associated Cisco 1000 Series lightweight access points to operate in Layer 3 mode before completing the conversion.

Step 2

In the Cisco WCS User Interface, change the LWAPP Transport Mode from Layer 3 to Layer 2:

Select CONFIGURE/Controllers to navigate to the All Controllers page, and select the Cisco Wireless LAN Controller by IP address to have Cisco WCS display the <IP address> > Controller General page.

On the <IP address> > Controller General page, select System/Networking to display the <IP address> > Networking Setups page.

On the <IP address> > Networking Setups page, change Layer 3 LWAPP Transport Mode to Layer 2 and click Save.

Cisco WCS may display a Please reboot the system for the LWAPP Mode change to take effect message; if so, click OK.

On the <IP address> > Networking Setups page, select System/Commands to display the <IP address> > Controller Commands page.

On the <IP address> > Controller Commands page, under Administrative Commands, select Save Config to Flash and click GO to save the changed configuration to the Cisco Wireless LAN Controller. Click OK to continue.

On the <IP address> > Controller Commands page, under Administrative Commands, select Reboot and click GO to reboot the Cisco Wireless LAN Controller. Then click OK to confirm the save and reboot.

Step 4

After the Cisco Wireless LAN Controller has rebooted, verify that the LWAPP Transport Mode is now Layer 2:

Select CONFIGURE/Controllers to navigate to the All Controllers page, and select the Cisco Wireless LAN Controller by IP address to have Cisco WCS display the <IP address> > Controller General page.

On the <IP address> > Controller General page, select System/Networking to display the <IP address> > Networking Setups page.

On the <IP address> > Networking Setups page, verify that the LWAPP Transport Mode is set to Layer 2.

You have completed the LWAPP Transport Mode conversion from Layer 3 to Layer 2. The Operating System software now controls all communications between controllers and lightweight access points on the same subnet.

Configuring a Firewall for Cisco WCS

When a Cisco WCS Server and a Cisco WCS User Interface are on different sides of a firewall, they cannot communicate unless the following ports on the firewall are opened to two-way traffic:

Open these ports to configure your firewall to allow communications between a Cisco WCS Server and a Cisco WCS User Interface.

Refer to the Cisco WCS Software Release Notes for any other ports that need to be opened for a Cisco WCS Server-to-Cisco WCS User Interface communications.

Configuring the System for SpectraLink NetLink Telephones

For best integration with the Cisco Wireless LAN Solution, SpectraLink NetLink Telephones require an extra Operating System configuration step: enable long preambles. The radio preamble (sometimes called a header) is a section of data at the head of a packet that contains information that wireless devices need when sending and receiving packets. Short preambles improve throughput performance, so they are enabled by default. However, some wireless devices, such as SpectraLink NetLink phones, require long preambles.

Using the Controller CLI to Enable Long Preambles

Use this procedure to use the controller CLI to enable long preambles to optimize the operation of SpectraLink NetLink phones on your wireless LAN.

Step 2

Enter show 802.11b and check the Short preamble mandatory parameter. If the parameter indicates that short preambles are enabled, continue with this procedure. This example shows that short preambles are enabled:

Short Preamble mandatory....................... Enabled

However, if the parameter shows that short preambles are disabled (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure. This example shows that short preambles are disabled:

Short Preamble mandatory....................... Disabled

Step 3

Enter config 802.11b disable network to disable the 802.11b/g network. (You cannot enable long preambles on the 802.11a network.)

Step 5

Enter config 802.11b enable network to re-enable the 802.11b/g network.

Step 6

Enter reset system to reboot the controller. Enter y when this prompt appears:

The system has unsaved changes. Would you like to save them now? (y/n)

Step 7

To verify that the controller is properly configured, log back into the CLI and enter show 802.11b to view these parameters:

802.11b Network................................ Enabled

Short Preamble mandatory....................... Disabled

These parameters show that the 802.11b/g network is enabled and that short preambles are disabled.

Using the Controller GUI to Enable Long Preambles

Use this procedure to use the controller GUI to enable long preambles to optimize the operation of SpectraLink NetLink phones on your wireless LAN.

Step 2

Follow this path to navigate to the 802.11b/g Global Parameters page:

If the Short Preamble Enabled box is checked, continue with this procedure. However, if the Short Preamble Enabled box is unchecked (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure.

Step 3

Uncheck the Short Preamble Enabled check box to enable long preambles.

Note If you do not already have an active CLI session to the controller, Cisco recommends that you start a CLI session to reboot the controller and watch the reboot process. A CLI session is also useful because the GUI loses its connection when the controller reboots.

Step 5

Reboot the controller using Commands > Reboot > Reboot. Click OK in response to this prompt:

Configuration will be saved and switch will be rebooted. Click ok to confirm.

Step 6

Log back into the controller GUI and verify that the controller is properly configured. Follow this path to navigate to the 802.11b/g Global Parameters page:

If the Short Preamble Enabled box is unchecked, the controller is optimized for SpectraLink NetLink phones.

Using WCS to Enable Long Preambles

Use this procedure to use WCS to enable long preambles to optimize the operation of SpectraLink NetLink phones on your wireless LAN.

Configuration > Configure Controllers > controller-ip-address > 802.11b/g > 802.11b/g Params

If the 802.11b/g Params page shows that short preambles are enabled, continue with this procedure. However, if short preambles are disabled (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure.

Step 5

Save the controller configuration using the Controller Config/Save Config command.

Step 6

Reboot the Cisco Wireless LAN Controller using Controller Commands/Reboot.

Please save configuration by clicking `Save Config' under `Switch Config' menu. Do you 
want to continue Rebooting anyway?

The controller reboots. This will take some time, during which Cisco WCS loses its connection to the controller.

Note

You can use a CLI session to view the controller reboot process. When you can log into the controller CLI, continue with this procedure.

Monitor > Troubleshoot > Controller Status > controller-ip-address > 802.11b/g/Stats

On the Stats page, verify that Short Preamble Implemented is set to No, which indicates that this controller is optimized for SpectraLink NetLink Telephones.

Using Management over Wireless

The Cisco WLAN Solution Management over Wireless feature allows Cisco WLAN Solution operators to monitor and configure local controllers using a wireless client. This feature is supported for all management tasks except uploads to and downloads from (transfers to and from) the controller.

Before you can use the Management over Wireless feature, you must properly configure the controller using one of these sections:

Using the Controller CLI to Enable Management over Wireless

Step 1

In the CLI, use the show network command to verify whether the Mgmt Via Wireless Interface is Enabled or Disabled. If Mgmt Via Wireless Interface is Disabled, continue with Step 2. Otherwise, continue with Step 3.

Step 2

To Enable Management over Wireless, enter config network mgmt-via-wireless enable.

Step 3

Use a wireless client to associate with an access point connected to the controller that you want to manage.

Step 4

Enter telnet controller-ip-address and log into the CLI to verify that you can manage the WLAN using a wireless client.

Using the the Controller GUI to Enable Management over Wireless

Step 1

In the Web User Interface, use the Management/Mgmt Via Wireless links to navigate to the Management Via Wireless page.

Step 2

In the Management Via Wireless page, verify that the Enable Controller Management to be accessible from Wireless Clients selection box is checked. If the selection box is not checked, continue with Step 2. Otherwise, continue with Step 3.

Step 3

In the Management Via Wireless page, check the Enable Controller Management to be accessible from Wireless Clients selection box to select Management over Wireless for the WLAN.

Step 5

Use a wireless client web browser to connect to the Cisco Wireless LAN Controller Management Port or DS Port IP Address, and log into the Web User Interface to verify that you can manage the WLAN using a wireless client.

Configuring DHCP

Follow the steps in one of these sections to configure your Wireless LAN to use a DHCP server:

Using the Controller CLI to Configure DHCP

Step 1

In the CLI, enter show wlan to verify whether you have a valid DHCP server assigned to the WLAN. If you have no DHCP server assigned to the WLAN, continue with Step 2. Otherwise, continue with Step 4.

In these commands, wlan-id = 1 through 16 and dhcp-ip-address = DHCP server IP Address.

Step 3

Enter show wlan to verify that you have a DHCP server assigned to the WLAN.

Step 4

Enter ping dhcp-ip-address to verify that the WLAN can communicate with the DHCP server.

Using the Controller GUI to Configure DHCP

Step 2

Locate the WLAN which you wish to configure for a DHCP server, and click the associated Edit link to display the WLANs > Edit page.

Step 3

Under General Policies, check the DHCP Relay/DHCP Server IP Addr to verify whether you have a valid DHCP server assigned to the WLAN. If you have no DHCP server assigned to the WLAN, continue with Step 4. Otherwise, continue with Step 9.

Step 6

In the DHCP Relay/DHCP Server IP Addr box, enter a valid DHCP server IP Address for this WLAN.

Step 8

Click Apply to assign the DHCP server to the WLAN and to enable the WLAN. You are returned to the WLANs page.

Step 9

In the upper-right corner of the WLANs page, click Ping and enter the DHCP server IP Address to verify that the WLAN can communicate with the DHCP server.

Customizing the Web Auth Login Screen

When you use Web Authorization (Web Auth) to authenticate clients, you must define usernames and passwords for each client, and when clients attempt to join the wireless LAN, they must enter a valid username and password when prompted by a login window. These sections describe the default Web Auth operation and how to customize the Web Auth login screen.

Default Web Auth Operation

When Web Auth is enabled, clients might receive a web-browser security alert the first time that they attempt to access a URL. Figure 3-1 shows a typical security alert.

Figure 3-2 After the client user clicks Yes to proceed (or if the client's browser does not display a security alert) the Web Auth system redirects the client to a login window. Typical Web Auth Login Window

The client must respond with a username and password that you define using the Local Net Users > New Web User page, or using the config netuser add CLI command.

The default Web Auth login window contains Cisco WLAN Solution-specific text and a logo in four customizable areas:

•

The message "Cisco WLAN Solution is pleased to provide the Wireless LAN infrastructure for your network. Please login and put your air space to work."

The Customizing Web Auth Operation section explains how to customize the Cisco WLAN Solution logo, window title, message, and logo.

When the client enters a valid username and password, the Web Auth system displays a successful login window and redirects the authenticated client to the requested URL. Figure 3-3 shows a typical successful login window.

The default login successful window contains a pointer to a virtual gateway address URL, redirect https://1.1.1.1/logout.html. You define this redirect through the Virtual Gateway IP Address parameter in the configuration wizard, the Virtual Gateway Address parameter on the Interfaces GUI page, or by entering the config interface create command in the CLI.

Customizing Web Auth Operation

This section explains how to customize Web Auth operation using the controller CLI. These sections describe the customization tasks:

Hiding and Restoring the Cisco WLAN Solution Logo

Changing the Web Auth Window Title

Use this command to reset the Web Auth window title back to the default setting:

Changing the Web Message

To reset the Web Auth window message to the Cisco WLAN Solution default ("Cisco WLAN Solution is pleased to provide the Wireless LAN infrastructure for your network. Please login and put your air space to work"), use this command:

Changing the Logo

These sections explain how to change the logo on the right side of the Web Auth login window:

Preparing the TFTP Server

•

If you are downloading through the Service port, the TFTP server MUST be on the same subnet as the Service port, because the Service port is not routable.

•

If you are downloading through the DS (Distribution System) network port, the TFTP server can be on the same or a different subnet, because the DS port is routable.

Step 2

On the CLI, enter ping ip-address to ensure that the controller can contact the TFTP server.

Note The TFTP server cannot run on the same computer as WCS. WCS and the TFTP server use the same communication port.

Copying the Logo or Graphic to the TFTP Server

Step 1

Create a logo in .JPG, .GIF, or .PNG format with a maximum file size of 30 kilobits. For the best fit in the space available, make the logo around 180 pixels wide and 360 pixels high.

Downloading the Logo or Graphic

Step 1

On the CLI, enter transfer download start and answer n to the prompt to view the current download settings:

transfer download start

Mode........................................... TFTP 
Data Type...................................... Code 
TFTP Server IP................................. xxx.xxx.xxx.xxx 
TFTP Path...................................... <directory path> 
TFTP Filename..................................... <filename.jpg|.gif|.png>

Are you sure you want to start? (y/n) n

Note

Some TFTP servers require only a forward slash (/) as the TFTP server IP address, and the TFTP server automatically determines the path to the correct directory.

Step 3

Enter transfer download start to view the updated settings, and answer y to the prompt to confirm the current download settings and start the download:

transfer download start

Mode........................................... TFTP 
Data Type...................................... Login Image 
TFTP Server IP................................. xxx.xxx.xxx.xxx 
TFTP Path...................................... <directory path> 
TFTP Filename.................................. <filename.jpg|.gif|.png>

This may take some time. 
Are you sure you want to start? (y/n) y

TFTP Image transfer starting.

Hiding the Logo

Creating a Custom URL Redirect

Use this command to redirect all Web Auth clients to a specific URL (including http:// or https://) after they authenticate:

For example, if you want to redirect all clients to www.AcompanyBC.com, use this command:

Verifying your Web Auth Changes

Enter show custom-web to verify your Web Auth operation changes. This example shows the output from the command when the Web Auth settings are at defaults:

Cisco Logo................................. Enabled 
CustomLogo..................................... Disabled 
Custom Title................................... Disabled 
Custom Message................................. Disabled 
Custom Redirect URL............................ Disabled 
External Web Authentication Mode............... Disabled 
External Web Authentication URL................ Disabled

This example shows the output from the command when the Web Auth settings have been modified:

Cisco Logo................................. Disabled 
CustomLogo..................................... 00_logo.gif 
Custom Title................................... Welcome to the AcompanyBC Wireless LAN! 
Custom Message................................. Contact the System Administrator for a  
Username and Password. 
Custom Redirect URL............................ http://www.AcompanyBC.com 
External Web Authentication Mode............... Disabled 
External Web Authentication URL................ Disabled

Example: Sample Customized Web Auth Login Page

This example shows a customized Web Auth login window and the CLI commands used to create it. Figure 3-4 shows the example Web Auth login window.

>config custom-web weblogo disable

>config custom-web webtitle Welcome to the AcompanyBC Wireless LAN!

>config custom-web webmessage Contact the System Administrator for a Username and 
Password.

>transfer download start

Mode........................................... TFTP 
Data Type...................................... Login Image 
TFTP Server IP................................. xxx.xxx.xxx.xxx 
TFTP Path...................................... / 
TFTP Filename.................................. Logo.gif

This may take some time. 
Are you sure you want to start? (y/n) y

TFTP Image transfer starting.

>config custom-web redirecturl http://www.AcompanyBC.com

Cisco Logo................................. Disabled 
CustomLogo..................................... 00_logo.gif 
Custom Title................................... Welcome to the AcompanyBC Wireless LAN! 
Custom Message................................. Contact the System Administrator for a  
Username and Password. 
Custom Redirect URL............................ http://www.AcompanyBC.com 
External Web Authentication Mode............... Disabled 
External Web Authentication URL................ Disabled

Configuring Identity Networking

These sections explain the Identity Networking feature, how it is configured, and the expected behavior for various security policies:

Identity Networking Overview

In most wireless LAN systems, each WLAN has a static policy that applies to all clients associated with an SSID. Although powerful, this method has limitations since it requires clients to associate with different SSIDs to inherit different QoS and security policies.

However, the Cisco Wireless LAN Solution supports Identity Networking, which allows the network to advertise a single SSID but allows specific users to inherit different QoS or security policies based on their user profiles. The specific policies that you can control using identity networking include:

•

Quality of Service. When present in a RADIUS Access Accept, the QoS-Level value overrides the QoS value specified in the WLAN profile.

•

ACL. When the ACL attribute is present in the RADIUS Access Accept, the system applies the ACL-Name to the client station after it authenticates. This overrides any ACLs that are assigned to the interface.

•

VLAN. When a VLAN Interface-Name or VLAN-Tag is present in a RADIUS Access Accept, the system places the client on a specific interface.

Note

The VLAN feature only supports MAC filtering, 802.1X, and WPA. The VLAN feature does not support Web Auth or IPSec.

Note

When any of the other RADIUS attributes in this section are returned, the Tunnel Attributes must also be returned.

In order for this feature to be enabled, on a per WLAN basis, the Enable AAA Override configuration flag must be enabled.

The Operating System's local MAC Filter database has been extended to include the interface name, allowing local MAC filters to specify to which interface the client should be assigned. A separate RADIUS server can also be used, but the RADIUS server must be defined using the Security menus.

RADIUS Attributes Used in Identity Networking

QoS-Level

This attribute indicates the Quality of Service level to be applied to the mobile client's traffic within the switching fabric, as well as over the air. This example shows a summary of the QoS-Level Attribute format. The fields are transmitted from left to right.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type      |  Length       |            Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Vendor-Id (cont.)          | Vendor type   | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ACL-Name

This attribute indicates the ACL name to be applied to the client. A summary of the ACL-Name Attribute format is shown below. The fields are transmitted from left to right.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type      |  Length       |            Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Vendor-Id (cont.)          | Vendor type   | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Interface-Name

This attribute indicates the VLAN Interface a client is to be associated to. A summary of the Interface-Name Attribute format is shown below. The fields are transmitted from left to right.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type      |  Length       |            Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Vendor-Id (cont.)          |  Vendor type  | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Interface Name...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

•

Value - A string that includes the name of the interface the client is to be assigned to.

Note

This Attribute only works when MAC Filtering is enabled, or if 802.1X or WPA is used as the security policy.

VLAN-Tag

This attribute indicates the group ID for a particular tunneled session, and is also known as the Tunnel-Private-Group-ID attribute.

This attribute might be included in the Access-Request packet if the tunnel initiator can predetermine the group resulting from a particular connection and should be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. It should be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.

A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      Type     |    Length     |     Tag       |   String...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

•

Tag - The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it should be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it should be interpreted as the first byte of the following String field.

•

String - This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs.

Tunnel Attributes

Note When any of the other RADIUS attributes in this section are returned, the Tunnel Attributes must also be returned.

Reference RFC2868 defines RADIUS tunnel attributes used for authentication and authorization, and RFC2867 defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.

In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in IEEE8021Q, based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network.

The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access- Request.

Note that the VLANID is 12-bits, taking a value between 1 and 4094, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in RFC2868, for use with IEEE 802.1X, the VLANID integer value is encoded as a string.

When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in RFC2868, section 3.1:

•

The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it must be zero (0x00).

•

For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field.

•

Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result, where it is only desired to specify the VLANID, the tag field should be set to zero (0x00) in all tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F should be chosen.

Table Of Contents

Solutions

Cisco WLAN Solution Security

Security Overview

Layer 1 Solutions

Layer 2 Solutions

Layer 3 Solutions

Single Point of Configuration Policy Manager Solutions

Rogue Access Point Solutions

Rogue Access Point Challenges

Tagging and Containing Rogue Access Points

Integrated Security Solutions

Converting a Cisco WLAN Solution from Layer 2 to Layer 3 Mode

Using the Web User Interface to Convert from Layer 2 to Layer 3 Mode

Using the Cisco WCS User Interface to Convert from Layer 2 to Layer 3 Mode

Converting a Cisco WLAN Solution from Layer 3 to Layer 2 Mode

Using the Web User Interface to Convert from Layer 3 to Layer 2 Mode

Using the Cisco WCS User Interface to Convert from Layer 3 to Layer 2 Mode

Configuring a Firewall for Cisco WCS

Configuring the System for SpectraLink NetLink Telephones

Using the Controller CLI to Enable Long Preambles

Using the Controller GUI to Enable Long Preambles

Using WCS to Enable Long Preambles

Using Management over Wireless

Using the Controller CLI to Enable Management over Wireless

Using the the Controller GUI to Enable Management over Wireless

Configuring DHCP

Using the Controller CLI to Configure DHCP

Using the Controller GUI to Configure DHCP

Customizing the Web Auth Login Screen

Default Web Auth Operation

Customizing Web Auth Operation

Hiding and Restoring the Cisco WLAN Solution Logo

Changing the Web Auth Window Title

Changing the Web Message

Changing the Logo

Preparing the TFTP Server

Copying the Logo or Graphic to the TFTP Server

Downloading the Logo or Graphic

Hiding the Logo

Creating a Custom URL Redirect

Verifying your Web Auth Changes

Example: Sample Customized Web Auth Login Page

Configuring Identity Networking

Identity Networking Overview

RADIUS Attributes Used in Identity Networking

QoS-Level

ACL-Name

Interface-Name

VLAN-Tag

Tunnel Attributes