Creating Per-site Guest VLANs on a Guest WLC (Cisco Guest Solution)

-

Overview

Before the advent of WLC code version 7.0.116.0, it was difficult to scale a Cisco guest wireless solution (in terms of IP address space) due to the fact that all foreign controllers (i.e. non-guest controllers) could only map to a single layer 3 interface on the guest (anchor) controller.

This often meant that a very large subnet had to be allocated to guest users to allow for multiple sites which shared a guest controller. The guest controller is usually located on a firewall DMZ interface (perhaps in a data center).

The only way around this was to have multiple guest SSIDs (e.g. one per building), with a separate VLAN for each SSID. This is not a very popular option with customers as there is no consistency of SSIDs between sites/buildings.

Another drawback of the single guest-VLAN restriction is that all guest traffic originates from a single subnet range. From an administrative point of view, it is often desirable for guest traffic from different buildings or sites to be sourced from their own subnet (to assist with traffic identification, filtering etc.)

In 7.0.116.0, a new feature: ‘VLAN Select’ was introduced which allows an individual dynamic interface (VLAN) to be selected on the anchor (guest) controller for each foreign (non-guest) controller. As an example, if you have a foreign controller at a number of buildings which all use one anchor (guest) controller, each building can now be assigned their own guest VLAN.

I recently had time to test this out in a lab environment and managed to grab a few screenshots of how to set this up. The process is very similar to the traditional method of setting up a guest controller, with a few additions and configuration changes at the anchor (guest) controller end of things.

Test Environment

The diagram below gives you some idea of the test environment I was using. It comprised 3 x 5508 WLCs running 7.0.116.0 code: two acting as foreign controllers and one as an anchor (guest) controller.

The aim of the test configuration is to provide guest users at Building A with a guest subnet of 192.168.50.0/24 and guest users a Building B with a subnet of 192.168.60.0/24. All guest users will use the same SSID of ‘guest’.



Mobility Management

As usual, all controllers have their mobility management configured so that they all know about each other. In this example, both non-guest WLCs are in the ‘corp’ group and the guest WLC is in the ‘guest’ group.
All controllers will have their Mobility Group configuration configured as shown below:


Fig1: Mobility configuration (all controllers)


Foreign WLC Configuration

The foreign controllers are configured using the traditional method for configuring guest access. This involves defining the guest WLAN and assigning it to the management interface*. The guest WLAN is also anchored to the guest controller using the ‘Mobility Anchors’ feature:

(*NOTE: In a real-world deployment, it is best practice to assign the guest WLAN to an interface assigned to an unused VLAN. This mitigates the scenario where the anchor controller becomes unavailable and the guest WLAN become attached to the management interface of the foreign controller, which represents a security issue.)


Fig2: Guest WLAN created


Fig3: Guest WLAN anchored to guest WLC

Fig4: Guest WLAN assigned to management interface*

(*NOTE: In a real-world deployment, it is best practice to assign the guest WLAN to an interface assigned to an unused VLAN. This mitigates the scenario where the anchor controller becomes unavailable and the guest WLAN become attached to the management interface of the foreign controller, which represents a security issue.)


This process is repeated on both foreign controllers for the guest WLAN so that they both have a guest WLAN anchored to the guest controller.


Anchor (Guest) WLC Configuration

The difference to the traditional (pre-7.0.116.0) method of configuring guest access is found on the anchor (guest) controller.
On the anchor controller we have to configure a dynamic (VLAN) interface for each of the foreign controllers.
The activities we have to perform are:
  • Create the dynamic interfaces (2 in our case)
  • Create the guest WLAN (assigning it to the management interface)
  • Assign the dynamic interfaces on the anchor (guest) WLC to the foreign controllers on the guest WLAN
The screen shots below show these steps:


Fig5: Create a dynamic interface for the first site

Fig6: Create a dynamic interface for the second site

Fig7: Dynamic interface summary showing new interfaces

Fig8: Create guest WLAN and assign to management interface

Fig9: Configure the Foreign Maps to map the dynamic interface on to the foreign controllers


Fig10: Select each foreign controller and map it on to a dynamic interface


Additional Steps

There are additional steps that will required such as correctly configuring the guest WLAN or your environment, perhaps creating DHCP scope on the guest WLC etc.  These are all detailed in the Cisco wireless design guide in some depth.


Hopefully, if you are already familiar with configuring guest access on Cisco wireless solutions, this guide will have provided you with enough information to take advantage of this new feature. For further information about configuring guest wireless, please visit the resources shown below:

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more