Single SSID - Multi VLAN - FlexConnect

An configuration example that I feel is under documented and not particularly clear is how to deploy a single SSID on a cisco WLC with ISE authentication on multiple VLANs based on authorization profiles.

It is actually very simple.

1st:

You build out you ISE policies just as you would for Wired.1x or Wireless.1x and make sure to add the VLAN assignment to the authorization result that you match.

2nd:

On your WLC, make sure that your SSID has the box for Flexconnect local switching checked and AAA override checked on the advanced tab.  

Make sure that you AP has VLAN support turned on and a local VLAN (Native) configured.

3rd:

Create a flexconnect group on your WLC from the wireless tab and add your APs to that group.

From the AAA VLAN-ACL mapping tab, create all of the VLANs that you will need to add users to from dynamic ISE assignments. 

This will cause sub-interfaces to be auto-generated on all of your APs in that flexconnect group.

Finally:

Test a user/device that ISE will assign to one of the VLANs and verify that they are authenticated and placed into the desired VLAN.  If everything connects you are good to go.

ISE

WLC

TIPS:

Make sure your VLANs are extended to the switch that the AP is connected to.

Make sure the WLC is running code level 7.4 or higher.

WPA(WPA2)-PSK not supported for ISE guest CWA?

I ran across this one very recently. 

If you are using ISE for CWA, then you are "limited" in what you can do from and SSID security standpoint.
Basic constraints:

• Set Layer2 security to None with MAC filtering. 
• Select the ISE IP address for both Authentication and Accounting Servers. 
• Advanced tab, enable AAA Override and set the Network Admission Control (NAC) State to RADIUS NAC (CoA support)

This means that you cannot use a PSK when you want to do central web auth with ISE.  Its sounds bad (unsecure) until you think about the security mechanisms behind it.  

• Your guest VLAN should not have access to anything besides the internet once authenticated.  
• All devices must get registered in ISE before they can authentication, so even if an unencrypted packet is sniffed, the device still gets redirected to the Guest portal page.  
• Absolute worst case, the "hacker" gets on your guest network: your guest VLAN ACLs peel them off to the internet only and you disallow peer to peer communication on the SSID.

I realize this might make some people uncomfortable with "no security" in the SSID, but keep in mind that this is for guest only and ISE is validating clients.

Links to ISE/WLC Guest Configuration:

ISE 1.3 CWA DOC

ISE and iPads

I do a lot of customer site install these days.  There are varying levels of infrastructure at all of them so here is a solution I ran into recently.

Needs:
ISE authentication for Wired Domain Joined PC
ISE authentication for Wired Non-Domain Joined (printers)
ISE authentication for Wireless Domain Joined PC
ISE authentication for Wireless Non-Domain Joined (ipad, iphone, scan gun)

Most of this is straight forward.

For starters they wanted to use Certificate authentication.  This worked great for all of the domain joined PCs, wired and wireless alike.  I simply allowed EAP-TLS connections only for each and used computer based authentication with a machine cert validation.  I pushed out the machine certs with a GPO and did the roll out the following week.  Piece of cake.

MAB was an easy solution for all of the printers, scanners, and misc devices in the manufacturing/warehouse areas.

The issue came in when they wanted secure access via their iPads.  Had these devices been domain joined it would have been simple.  Issue them a machine cert.  Alternately I could have used NDES to join the iPads (but they're running windows server 2008 standard... Not NDES).  A third option would be to manually generate certs for each device (not an option, too many and spread out across the country).

My solution was to add all users that needed WiFi via iPads into an AD group.  I then profiled all apple devices joining the network and created an identity group mapping.

My policy was simple and just required that after a cert failure, check to see if the devices has been profile as an apple-device and that the user is a member of the ipadUser group.  Not as secure as certificates or checking for domain joined machines, but a lot better than just allow all devices coming and going onto the corp-WiFi.

Ipad/Iphone SSID Join issue

I have seen this happen to more people than I can count.

Symptoms:

• Ipad/Iphone can't join a wireless network
• Ipad/Iphone can't roam properly
• Laptops and androids join/roam just fine
• Debugs on the Controller show the Ipad/Iphone joining 

Solution:

Turn on Fast SSID switching.


















The apple devices for whatever reason try to join a 2nd SSID before they receive the response from the controller. With the option disabled the WLC sets a delay before the devices and join a different SSID.  The vicious cycle begins.

Nothing make people more irritated than not being able to use their shiny apples.

References:
rscciew

Apples on your Cisco gear

If you Apple devices on your network, this is a handy doc from Cisco.

http://www.cisco.com/c/en/us/td/docs/wireless/technology/vowlan/bestpractices/EntBP-AppMobDevs-on-Wlans.pdf

Wireless Mobility Connections Fail and Do Not Recover When ASA is Rebooted

I saw this issue for the first time today so I thought it was worth sharing. 
Full article is linked here: LINK

Took TAC a while to find the issue, but apparently TAC says its a design issue not a bug.

Brief overview:

Problem

In this situation a Wireless LAN Controller (WLC) at 10.10.1.2 attempts to communicate with the WLC at 10.10.9.3, but the communication fails.
This problem can be triggered by any of these events:

• The ASA is rebooted.
• The routing table is modified by an administrator or routing protocol.
• An interface is shut down, then brought back up by the administrator.

Besides mobility traffic, this problem might be experienced for any UDP or non-TCP IP protocols.

Solution

Solution 1

One possible solution for this issue is to remove the same-security permit intra-interface command from the ASA. This solution prevents the u-turn connection from being built back out the same interface on which the original packet was received, which allows the correct connection to be built when the interface comes up. However, depending on the routing table of the ASA, this solution might not work (the traffic might be routed to another interface other than the intended destination based on the routing table), and the same-security permit intra-interface command might be necessary for other connections on the ASA.

Solution 2

For this specific instance, the problem was successfully mitigated by enabling the timeout floating-conn feature. This feature, which is not enabled by default, caused the ASA to tear down these connections one minute after a more preferred route to one of the endpoints is added to the routing table out a new interface of the ASA, which occurs when the dmz interface comes up. The connections are then immediately rebuilt when the next packet arrives at the ASA, using the more preferred interface (dmz, instead of inside for the 10.10.9.3 host).

ASA(config)# timeout floating-conn 0:01:00 

Outdoor Mesh

Cisco's outdoor mesh is not a new concept, but a different animal than the indoor world.  You can cover much larger areas with fewer APs.  Be warned, just because you can 'see' the AP from a location doesn't mean it can 'see' you.  the 1550 series APs have a much greater sensitivity than lets say the 3600 series.  The external omni-direction antenna can detect down to the range of -92 dBm.  The real limiting factor is going to be your clients.  Laptops at 'full' power will get you a lot further then your average Moto handheld scanner, iPhone, etc.  There is lots of good info out there, but some of it is hard to find.

Here is a list of documents that are very useful for mesh deployments:

Cisco 1550 Ordering Guide

Cisco Mesh Deployment Guide 7.3

Cisco Mesh Deployment Guide 7.4

Cisco 1552 Range Calculator