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.

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