Showing posts with label Cisco. Show all posts
Showing posts with label Cisco. Show all posts

Tuesday, 12 August 2014

Cisco WLC: Per-client Packet Capture


Sometimes, you just want to capture the packets associated with a particular wireless client and see what the heck is going on with that client. Often, it may not be practical to do an over-the-air packet capture, as perhaps the client is at a remote location or just just don't have access to a wireless capture card.


I recently had an issue trying to understand why an Android device that I was trying to 'on-board' using Cisco's ISE wouldn't access the Google Play store. I desperately wanted to capture the over-the-air frames from the client to have a look at what the client was doing.


After a quick 'Google' around, I found an intriguing set of Cisco WLC CLI commands that allow a packet capture of traffic for a wireless client. This can all be done without having to change the AP mode, or reboot the AP etc.
In summary, the feature allows packets to be captured for a specified wireless client that is sending/receiving traffic to/from an AP. The AP will continue to process all user traffic as per usual, with the target client frames being streamed to an FTP server for a specified period. The resultant capture file is in standard pcap format that can be opened with Wireshark (amongst others).

The feature looks like it became available from WLC code 7.4 - full details can be found at the following URL : http://bit.ly/wlc-pkt-capture

In summary, the following work-flow worked pretty well for me:

  1. Identify the client MAC address you would like to capture
  2. Identify the FTP server to receive the trace file:

    config ap packet-dump ftp serverip <ip-address> path <path> username <user_ID> password <password>
  3. Configure the frames to be captured - data frames worked well for me:

    config ap packet-dump classifier data enable

    (don't try to capture without specifying a classifier, as you capture nothing - I tried it...)
  4. Start the client packet capture for the target client:

    config ap packet-dump start <client-mac-address>
  5. After a while, you can stop the capture sessions and see what you've got: (note that by default, the capture session stops after 10 mins)

    config ap packet-dump stop

    (note that the FTP server may not show any frames captured until you stop the capture and it empties out its buffer)

There are a few caveats to this capture technique, but it is still a very powerful tool to add to your WiFi utility belt. Caveats include:

  • beacons and probe responses are not captured
  • the client must be associated with an AP joined to the WLC
  • only frames for one client at a time can be captured
  • does not work from inter-controller roaming

Here are all of the commands for your reference (taken from the Cisco configuration guide):

  • Configure FTP parameters for packet capture by entering this command:

    config ap packet-dump ftp serverip ip-address path path username user_ID password password
  • Start or stop packet capture by entering this command:

    config ap packet-dump {start client-mac-address ap-name | stop}
  • Configure the buffer size for packet capture by entering this command:

    config ap packet-dump buffer-size size-in-kb
  • Configure the time for packet capture by entering this command:

    config ap packet-dump capture-time time-in-minutes

    (The valid range is between 1 to 60 minutes.)
  • Configure the types of packets to be captured by entering this command:

    config ap packet-dump classifier {arp | broadcast | control | data | dot1x | iapp | ip | management | multicast | {tcp port port-number} | {udp port port-number}} {enable | disable}
  • Configure the packet length after truncation by entering this command:

    config ap packet-dump truncate length-in-bytes
  • Know the status of packet capture by entering this command:

    show ap packet-dump status
  • Configure debugging of packet capture by entering this command:

    debug ap packet-dump {enable | disable}

Tuesday, 28 May 2013

Cisco ACS Policy Decisions Based on SSID Name

If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this.

In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note.

Background

In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of the authentication handshake between the WLC and RADIUS server. One of the attributes that is sent forward to the RADIUS contains information about the source SSID. This attribute can be leveraged in the policy/decision process for authenticating users.

The attribute we are interested in is the DNIS (Dialed Number Identification Service). If we inspect this attribute in the ACS logs, we can see that the DNIS contains the MAC address of the RADIUS client (the WLC), together with the SSID name. Here is a screenshot that shows an authentication record for a client (the SSID is called "home-8021x")



Having the MAC address and SSID mixed together like this is not that useful, but by using a wildcard character to ignore the MAC address segment of the field, we can look at the SSID name. Luckily for us, the '*' character can be used to wildcard the leading part of the field (i.e. the MAC address) and allow us to just look at the SSID segment that we wish to use for our decision making process.

To be able to include the SSID in the decision making process, we have to create an End Station Filter within ACS that we can drop in to our policy rules. Here is the ACS page that we are interested in:



To match on our SSID of interest ("home-8021x"), we have to configure the end station filter as shown below (note the use of the "*" to act as a wildcard for the MAC address of RADIUS client):



Configuration Example

Once we have our End Station Filter in place, we can make some very granular decisions around authentication and authorisation of users trying to join the SSID. One area that this is very useful for is defining Service Policies. We can tie a service definition to a particular source SSID.

For reference, here is a screen-shot from the Cisco WLC GUI, showing the SSID name that we are using:



In the example below, we have a service policy called "Auth_Users_Select". You can see from the highlighted field that only authentication requests that are received from our sample SSID will hit this policy entry, as they must match the End Station Filter that contains the SSID information. 




If you are looking at your own copy of ACS whilst looking at the example shown above, you may not see all of the fields shown in this screen-shot. You may need to customize the fields shown by hitting the 'Customize' button shown at the bottom right of the screen-shot.

Caveats

There are a couple of caveats to bear in mind:
  • SSID names are case sensitive. If you aren't hitting the policy line you expect, double check the case of the SSID name in your end station filter, compared to that on your WLC
  • Bear in mind that you are using a wild-card in the end station filter. If you have similar-named SSIDs, make sure you are not filtering out an important part of the SSID name inadvertently
Conclusion

Using End Station Filters in this way gives you a powerful way of making decisions around both authentication and authorization decisions.

Particularly when considering service policy decisions within ACS, being able to associate a service with a particular SSID is valuable - each service (e.g. Corporate-data, Corporate-voice etc.) may be authenticated by their own methods using this technique.

It's also worth noting that the same effect may be achieved using the WLAN-ID RADIUS attribute which provides the (numerical) index of the SSID (this is often suggested in other configuration examples I have seen). Although using the SSID index (via the WLAN-ID RADIUS attribute) is  a valid method, unless there has been a policy of assigning the same SSID to the same index on every WLC in the network, then this may not be a feasible approach.

References

The following documents provide some very valuable references, particularly if you are looking for the ACS 4.x version of this technique:

Wednesday, 21 November 2012

Cisco DTLS License

The whole area around the free DTLS license that can be obtained for Cisco WLCs has always been a bit of a head-scratcher for me.

I'm never sure whether I need the additional license or I already have it to be honest. Anyhow, today on my home lab I tried to have a look at some features which required DTLS between the AP & WLC, only to find that my 2504 did not support the option (the option was grayed out).

After some digging around on the Cisco forums, I found that the following licensing link can be used to obtain the DTLS entitlement license with very little fuss at all:

https://tools.cisco.com/SWIFT/LicensingUI/loadDemoLicensee?FormId=4090

The information to be entered can be found on the WLC inventory page. Only the model number & serial number are required.

Within seconds, I had the license (which can be downloaded directly or sent by email) and applied it to my 2504 (Management > Software Activation > Commands > Install License)

Tuesday, 18 September 2012

Installing a PFX File on a Cisco WLC

Cisco provide an excellent guide on how to create a CSR for a wireless LAN controller so that a certificate signed by a public CA can be installed. This is often very useful if you are using the WLC as a guest controller and want to prevent browser security messages that pop-up in a guest’s browser each time they access your guest wireless network.

The Cisco guide can be found here:

http://www.cisco.com/en/US/customer/products/ps6366/products_configuration_example09186a0080a77592.shtml

It also details how to install the chained certificate (provided by a public CA) on to the WLC. The certificate in the examples shown in the document use a ‘.pem’’ (Privacy Enhanced Mail) format file.

The method described in the (Cisco) document involves generating a CSR using Open SSL version 0.9.8 to create a certificate request which is then submitted to a public CA such as Thawte, Verisign etc.

It should be  possible to generate CSRs using other methods (other than Open SSL), but you may not end up with a resultant certificate file in the required file format to import into your WLC.

I had an instance recently where a customer had generated a certificate using their usual CSR method (I’m not too sure what they used), but the resulting file they received from their public CA (Thawte in this case) was a ‘.pfx’ file (Personal Information Exchange). The file required to import in to a WLC is a ‘.pem’ file (see this page for more information about various certificate file formats)

So, I was a in a bit of a tight spot, as the supplied ‘.pfx’ file was the incorrect format. I tried (in desperation) to import it anyhow, but it just failed with a rather unhelpful ‘file transfer error’ message.

So I had a dig about on the Internet and found a very useful document which walked through the process of how to convert the pfx file into a format I could use to create my final pem file.

To convert from pfx to pem format, I still needed the services of Open SSL, which I installed onto my Windows 7 laptop. You can get it from this page, but make sure you get the 0.9.8 version, otherwise the resultant files will not work on a Cisco WLC (you have been warned). Also, I believe that this process can only be performed if the pfx file you have been supplied with allows the export of the private key (this would have been specified as part of the certificate request). You will also need to know the import password for the certificate, which will have been specified when creating the original CSR.

There are 2 stages to the process:

  1. Extract and verify various elements from the pfx file
  2. Completion of the process described in the original Cisco configuration document to generate the final ‘.pem’ file

Stage 1

First of all, we need to extract various elements and verify checksums of what we have extracted. In the examples shown below, I have used the prefix ‘Wireless_Cert’ so indicate the various input and output files used.

The starting point is an input file called : Wireless_Cert.pfx. Inline comments indicate what each step is achieving.

The commands run below are run from a standard DOS command line and assume that openssl is in your %PATH% variable (set path=%path%;C:\OpenSSL\bin;). All operations will be performed in the c:\temp directory in this example. (Note: all commands will be on a single line, not broken by line-wraps)

  • Export the private key (import password for certificate required) - creates a new file: Wireless_Cert.key:openssl pkcs12 -in c:\temp\Wireless_Cert.pfx -out c:\temp\Wireless_Cert.key -nocerts -nodes
  • Remove the private key encryption - creates a new file: Wireless_Cert_s.key:openssl rsa -in c:\temp\Wireless_Cert.key -out c:\temp\Wireless_Cert_s.key
  • Export the SSL certificate (import password for certificate required) - creates a new file: Wireless_Cert.pem
    openssl pkcs12 -in c:\temp\Wireless_Cert.pfx -out c:\temp\Wireless_Cert.pem -nokeys -clcerts
  • Run the following commands. They should produce the same checksum if all has gone well:openssl x509 -noout -modulus -in c:\temp\Wireless_Cert.pem | openssl md5
    openssl rsa -noout -modulus -in c:\temp\Wireless_Cert_s.key  | openssl md5

You will now have a file called : c:\temp\Wireless_Cert.pem which will be the subject of stage 2 of our process.

Stage 2


In this stage, we combine the pem file from stage one with the (unencrypted) key file to create our final pem file.

Following on from our previous conventions, execute the following commands from a DOS command line. Note that the import password from the previous stage is required and embedded in the commands below, indicated by ‘xxxxxx’ :

  • Combine the .pem file and key file - a new file is created : c:\temp\All-certs.p12

    openssl pkcs12 -export -in c:\temp\Wireless_Cert.pem -inkey c:\temp\Wireless_Cert_s.key -out c:\temp\All-certs.p12 -clcerts -passin pass:xxxxxx -passout pass:xxxxxx
  • Create the final pem file: c:\temp\final-cert.pem
    openssl pkcs12 -in c:\temp\All-certs.p12 -out c:\temp\final-cert.pem -passin pass:xxxxxx -passout pass:xxxxxx

The final file that is created is: c:\temp\final-cert.pem, which is the file imported in to the WLC, as described in the original Cisco configuration document

Don’t forget that all of the steps described above can be found in the following couple of documents, if you should need them for reference:

Friday, 15 June 2012

Issue: Having to log back in on Apple devices on a Cisco wireless guest network

I'm documenting this for my own reference as much as anything, to avoid having to look this information up (yet again).

(This description assumes that the use-case is for a guest network, but will apply to any layer-3 authenticated wireless network)

It is a common occurrence on Cisco wireless networks (using a WLC of some type) to have complaints from guest users that they have to keep logging back in to the guest network after their device has gone in to sleep mode. They are often put in to sleep when they are enveloped in some type of holder or covering system that has a built-in magnet to make them sleep when they are not in use (this is very typical on iPad holders/covers).

The reason for the annoying issue of having to log back in to the guest network is that the WLC has a user idle timeout setting which expires (by default) after 5 minutes. So, when a device is put in to sleep mode, the WLC will not hear from it for a while and then after  5 minutes will terminate its session.

If you know a little about WLCs, you would expect this behaviour to be dictated by the 'session timeout' setting which is available on the WLC GUI via the Advanced tab of the WLAN definition. But, that timer is the time-out for the entire (continuous) session. If you wish guest sessions to automatically end after a pre-defined period of use (e.g. force guest users to re-authenticate every couple of hours of use), you would use that setting.

To configure the idle time-out setting, you can only configure this via the CLI (in version 7.0 code anyhow) using the command below. Remember, this is the setting that will determine how long a client is idle (e.g. in sleep mode)  before its session is terminated. The command to use is:

config network usertimeout  seconds

The 'seconds' value is obviously the amount of time a device can be idle before its session is terminated. By default, it is 5 minutes (300 seconds), and can be a minimum value of 90 seconds.

The value you choose depends on how long your users may put their device to sleep for. Obviously you need to wind it up above the default of 300 seconds if users are complaining. I'd suggest trying 15 minutes (900 secs) and maybe wind it up  if users still complain (...try 30 minutes(1800 secs) next?).

The only downside to winding this value up is that clients will sit in your client list on the WLC for longer. Normally, they would time-out within 5 minutes. But, if you wind this value up, they won't age-out as quickly.

Right...the next time I need this info, I know exactly where to find it.

(Note: I had a note via Twitter from @revolutionwifi advising that another consideration with this approach is the possible impact this may have on WLC memory, which is a fair point. I guess it depends very much on your environment. This setting is going to affect all clients that attach to the WLC, so if you have large numbers of users, you may need to keep an eye on your memory usage. I suspect this would only be an issue if you had an environment where you have many unique users who come and go during the day, who would effectively hang around in the WLC memory for longer periods than you would like.)

Tuesday, 24 April 2012

Decoding Cisco CAPWAP With Wireshark

Here's an interesting little gotcha I wasted a few hours on recently...

I have been looking at QOS on a Cisco WLC and was looking at DSCP markings in CAPWAP packets between a Cisco WLC and access point. I did this by spanning the switch port that the AP is connected to and then using a copy of Wireshark on another switch port to capture the traffic so that I could have a look through it.

However, when I looked at the CAPWAP frames, Wireshark was reporting most of the CAPWAP packets as being "Association Requests" and that they were "[Malformed Packets]".

After testing this in quite a number of versions of Wireshark (assuming a Wireshark decode bug), I finally gave up and reported a bug to the guys at Wireshark. They were incredibly quick to respond and diagnosed the issue very quickly!

It turns out that Cisco have not implemented the final draft of CAPWAP (according the guys at Wireshark), and that there is an option in Wireshark for Cisco CAPWAP support. You can it in the find the options panel at : Edit > Preferences > Protocols in the Wireshark GUI.

Select the CAPWAP protocol and check the 'Cisco Wireless Controller Support' check-box and everything decodes as you would expect :)

Thursday, 19 April 2012

Fast SSID Change - Out Of The Shadows

There are many configuration settings on a piece of networking kit that are just 'there'.

They sit there year after year just minding their own business being a quiet little chunk of configuration sitting in their default state not doing anyone any particular harm. Then, occaisionally, you come across some obscure case that causes you to actually pay attention to what exactly that particular setting is 'bringing to the party'.

One particular instance I came across recently is the 'Fast SSID Change' setting on a Cisco WLC.

From memory, it's been sat there for quite a while on many of the controllers I've installed, sitting dutifully in its default state of 'Disabled'. I've never really paid it much attention as it doesn't (on the face of it) seem to cause anyone any particular problems.

However, I recently ran in to a situation where a customer had some Apple iPads that he wanted to connect to an SSID that was mapped to an internal corporate VLAN. The iPads connected up quite nicely using PEAP - nothing too interesting there. However, the customer also wanted to flip an iPad or two across to the guest user SSID, which was mapped on to a completely different VLAN and anchored to a DMZ controller. The reason to flip between the 2 SSIDs was purely to carry out testing of the new wireless solution (i.e. corporate users with iPads and guest users with iPads).

The iPad was correctly configured for both SSIDs. To flip between the 2 SSIDs, we simply opened the network settings of the iPad and selected each SSID in the list of shown wireless networks. (For full disclosure, the iPad was running iOS 5.1.x, the guest SSID was brodcasting and the corporate SSID was set to not broadcast).

However, when I tried to flip between the SSIDs (e.g. guest SSID to corporate SSID), the iPad would attempt to connect to the newly selected SSID, but would fail and fall back to the original SSID that it was connected to. The real head-scratcher was that a smartphone correctly configured for both SSIDs switched between the two SSIDs back and forth with no issues at all!

After quite a bit of pondering and double-checking of the iPad wireless configuration, I decided to run a client debug on the WLC. The debug seemed to show that the iPad was associating with the newly selected SSID, but then reverted back to the original SSID before any authentication took place. I wasn't too sure what was going on...

After some digging around, I found a few Cisco forum posts talking about 'Fast SSID Change' which sounded like it might be related. Here is the description of the 'Fast SSID Change' parameter from the WLC help files:

"When you enable Fast SSID Change, the controller allows clients to move between SSIDs. When the client sends a new association request for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID.


When Fast SSID Change is disabled, the controller enforces a delay before clients are allowed to move to a new SSID."

So, I tried changing the 'Fast SSID Change' parameter to 'enabled' and suddenly the iPads were happily switching between the two SSIDs with no issues!

I'm guessing this was a timing issue on the iPads - I guess they weren't quite as patient as the smartphone.

The question remaining in my mind is this: why is 'Fast SSID Change' set to disabled by default? I wonder if there are any particular reasons you wouldn't want to just blindly enable it for every installation of a new WLC? (I haven't found any reasons to date...)

I tried to think of other scenarios where you may run in to this issue. It's hard to think of any beyond the testing scenario I described above, but I guess there will be one or two use-cases. I thought of something perhaps around a provisioning-type WLAN where maybe some type of client or agent is provisioned to an iPad and then you need to flip across to another SSID to use the new client or agent, but that was the best I could come up with.

I'd be interested to hear if anyone else has any good arguments for or against enabling 'Fast SSID Change'.

References:

Thursday, 12 April 2012

Cisco NCS 1.0/1.1 - Internet Explorer Chrome Plugin Gotcha

If you're like me, then when it's time to use or install a new release of software, you quickly scan through the release notes trying to make sense of the reams and reams of 'new features', 'caveats', 'bugs fixed' etc. without falling to sleep and smashing your nose on the desk in front of you. (Why can't technical writers give those things a plot, a love interest and a gripping ending..?)

The main purpose of this exercise is often to pick up the 'headlines' so that you can fairly comfortably install or implement the new software, armed with a reasonable amount of knowledge to allow you to not fall down any particularly large holes during the process.

One area I'm particularly guilty of 'glossing over' in this release-note-scanning activity is the section that describes the versions of browser support that are provided for web-GUI based products (e.g. network management software).

Sure, I give the browser support section a quick glance and verify that the usual suspects are there (IE, Firefox & maybe Chrome), but never really pay too much attention beyond making sure that there nothing too old there that may cause any issues.

However, I have fallen down a very large hole recently when it came to using Cisco's NCS. To make matters worse, I have to admit to having fallen down this particular hole twice.

The gotcha to watch out for is the browser support for both NCS version 1.0 & 1.1. If you skim the release notes quickly (like I did), then it's very easy to miss a very important piece of information. Here is the relevant extract from the NCS 1.0 & 1.1 release notes:

"The NCS user interface requires Mozilla Firefox 3.6 or later minor version and Internet Explorer 8.x with the Chrome plugin releases or Google Chrome 12.0.742.x. Internet Explorer 6.0 is not supported."

The important piece of information here is : "Internet Explorer 8.x with the Chrome plugin"

The "with the Chrome plugin" doesn't seem too important if you scan over it quickly. But, believe me, you don't want to ignore that particular phrase if your customer uses IE as their corporate-standard browser.

On both of the occaisions when I have installed NCS recently, the customer used IE as their standard browser, with strict policies restricting the download of plugins (or other browsers!). This meant that in both cases, we couldn't install the Chrome plugin. Believe me we tried (..and tried and tried!!!) But, the corporate AV policies wouldn't allow the installer to run as it looks like the Chrome updater, and, it has to have access the Internet to download updates & 'stuff'.

So, in both cases (after much embarrasment, head scratching and silent cursing), we had to admit defeat and get some change controls in place for special dispensation to install Firefox...which was very painful and took some considerable time.

Not having the Chrome plugin (which, incidentally, you can get from here: http://www.google.com/chromeframe) means that if you login to NCS using IE8 as an admin user, you have very limited GUI functionality. It sort of limps along and gives you access to a few features, but it doesn't take long before you're tearing your hair out with it as you find things that don't work.

If you login with a Lobby Ambassador account, things are even worse. Instead of being presented with the usual Lobby Ambassador GUI, you actually get to see a read-only version of the home page that an NCS admin would normally see! As, I said, it's a read-only version of the page, so there don't appear to be any security risks there, but it's weird (and totally useless) to login as a LA and see the usual NCS home page...

So, the key takeaway from this: don't fall down the NCS/IE/Chrome plugin hole that I did (twice). Make sure your customer is able to install the Chrome plugin before you start putting NCS in, or make arrangements to ensure they can use Firefox or Chrome as an alternative.

Finally, don't scan software release notes...(even if you spend hours and hours and hours reading them that could be better spent with family, friends and picking out those bits of fluff that seem to collect in your navel).

...anyone else remember suffering plugin issues with other Cisco NMS products - dare I mention Java..?

References:


Wednesday, 24 August 2011

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: