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

Convert Lightweight AP back to Autonomous

On occasion I need an autonomous AP, but all I have is a drawer full of lightweights.  Here is the process for getting them back to autonomous mode:

(This is from Cisco)

Step 1 The static IP address of the PC on which your TFTP server software runs should be between 10.0.0.2 and 10.0.0.30.

Step 2 Make sure that the PC contains the access point image file (such as c1200-k9w7-tar.122-15.JA.tar for a 1200 series access point) in the TFTP server folder and that the TFTP server is activated.

Step 3 Set the timeout value on the TFTP server to 30 seconds.

Step 4 On the PC where the TFTP server is located, perform these steps:

a. Disable any software firewall products, such as Windows firewall, ZoneAlarm firewall, McAffee firewall, or others.

b. Ensure all Windows files are visible. From Windows Explorer, click Tools > Folder Options > View; then uncheck the Hide extensions for known file types check box.

Step 5 Rename the access point image file in the TFTP server folder to c1200-k9w7-tar.default for a 1200 series access point, c1130-k9w7-tar.default for an 1130 series access point, c1240-k9w7-tar.default for a 1240 series access point, and c1250-k9w7-tar.default for a 1250 series access point.

Step 6 Connect the PC to the access point using a Category 5 (CAT5) Ethernet cable.

Step 7 Disconnect power from the access point.

Step 8 Press and hold MODE while you reconnect power to the access point.

Step 9 Hold the MODE button until the status LED turns red (approximately 20 to 30 seconds) and then release.

Step 10 Wait until the access point reboots, as indicated by all LEDs turning green followed by the Status LED blinking green.

Step 11 After the access point reboots, reconfigure it using the GUI or the CLI.

Upgrade Cisco AP to LWAPP without UpGrade tool

I don't know how many times I've tried to use Cisco's free upgrade tool and had something go wrong, but it was too many to bother trying again. As with most things Cisco, CLI is my favorite way to do it. I did a little research and found a command that saved me all the frustration of the Upgrade Tool.

Here's all you need to totally bypass the Upgrade Tool and do it yourself:

1. Download Tftpd32/64: Link

2. Start Tftpd32/64

3. Change your current directory to the directory to the directory that contains your LightWeight image file

4. Log in to your AP (while its attach to a network your PC can access)

5. Input this command:

Ap#archive download-sw /leave-old-sw tftp://(tftpserver IP)/imagename

6. Allow AP to download image from your PC.

7. Reload AP

8. Sigh (you're done)


If you really want the link to the UpgradeTool here it is: Link