Archive

Archive for the ‘WLC’ Category

FlexConnect APs – Some Thoughts

I’m working on a project that requires FlexConnect APs. As part of the project, I’ve run into a few pieces that took a bit to figure out, as they weren’t readily apparent to me.

FlexConnect ACLs

I understand your typical WLC ACLs.  Everything for non-CPU ACLs was from the perspective of the WLC to and from the client.  So, inbound was from the client to the WLC.  Outbound was from the WLC to the client.  And, just make sure that if you have a deny all at the end, you have a permit for both directions of the flows that you want to allow.  No problem.

FlexConnect ACLs appear to take a different approach. I made the (apparently erroneous) assumption that “ingress” (note the change in terminology) was from the client to the AP, while “egress” was from the AP to the client.  Au contraire!  “Ingress” means from the wired side/switch to the AP, while “egress” means from the AP to the wired side/switch.  In this case, I wanted to ensure that guests could only get to external IP addresses.  Applying an ACL that basically denied anything to the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 subnets while permitting everything else INGRESS blocked my traffic.  Once I applied it EGRESS, everything worked as expected.  I could also apply the inverse ACL ingress, but that wasn’t necessary in this case.

FlexConnect and Local External RADIUS

Way back in my day, if you wanted to use RADIUS with H-REAP, you had to send it back through the WLC.  Then, Cisco added this new-fangled feature of a Backup RADIUS server as part of H-REAP groups, where the AP could go to authenticate users if the WLC was down.  But, what if I want to use a local RADIUS server (say an ACS or Windows NPS server at a site)?  That is where the checkbox “FlexConnect Local Auth” comes into play.  When checked, RADIUS requests will be sent from the AP to either the default RADIUS authentication server(s) of the WLAN OR the primary/secondary RADIUS server(s) of the FlexConnect group (if defined).  The FlexConnect group configuration takes precedence over the WLAN configuration.  Note that the RADIUS server needs to be configured to allow the AP as a NAS, using the shared key defined by the RADIUS server configuration on the WLC.  Also, if using an external RADIUS server, you can ignore the “Enable AP Local Authentication” checkbox under the FlexConnect group configuration.  That’s used if the AP itself will be the RADIUS server. (Thanks to Mr. @revolutionwifi for his article at http://revolutionwifi.blogspot.com/2011/09/cisco-h-reap-local-authentication.html for pointing me in the right direction there!)

FlexConnect and ISE

In looking at the literature, one would assume that FlexConnect APs won’t work with ISE at this point (WLC 7.2 and ISE 1.1).  That is not completely true.  You can configured ISE as a AAA server for RADIUS, similar to how ACS 5.X (not including 5.0) is configured.  The interface is a bit different from ACS, but many of the concepts apply.

I’m sure that there will be more things with FlexConnect in the future.

Advertisements

Wildcard Certs for WLC

I love a challenge. Tell me that something can’t be done, and I’ll try to find a way to do it. The challenge yesterday was installing a wildcard cert from a 2 tier CA on Cisco NCS (see this page if you haven’t read that article.  You will need to go through that to get the certificates and components for this article.) Since I was able to get that working, I decided to try it on a WLC. The WLC in question is a NME-AIR-WLC6-K9 running 7.0.220.0.  WLC certificates can be used for three purposes:

  1. Web administration of the WLC
  2. The web authentication page
  3. Local EAP (PEAP and EAP-TLS)

In particular, I wanted to get a certificate for both #1 and #2.  And, a benefit of the wildcard cert would be the ability to use the same certificate for both!  In looking at options, I came across a thread on Cisco Support Community that seemed to be a dead end (https://supportforums.cisco.com/thread/2067781).  That thread references a Cisco Bug ID that was junked (http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsy88149).  So, I figured that this would be an interesting challenge 🙂

Since the combined CA cert worked on NCS, I figured I would start with that.  Technically, this is not required for #1 or #2, but why not try it anyways.  I renamed the cacerts.cer file to cacerts.pem.  No conversion, just renaming the file.  I uploaded the file as a Vendor CA Certificate.  And, low and behold, it was successful.  Here is the output from debug transfer all enable:

*TransferTask: Mar 06 20:29:38.870: Memory overcommit policy restored from 1 to 0
*TransferTask: Mar 06 20:30:27.733: Memory overcommit policy changed from 0 to 1
*TransferTask: Mar 06 20:30:27.775: RESULT_STRING: FTP EAP CA cert transfer starting.
*TransferTask: Mar 06 20:30:27.775: RESULT_CODE:1
*TransferTask: Mar 06 20:30:32.552: ftp operation returns 0
*TransferTask: Mar 06 20:30:32.552: RESULT_STRING: FTP receive complete... installing Certificate.
*TransferTask: Mar 06 20:30:32.552: RESULT_CODE:13
*TransferTask: Mar 06 20:30:32.552: Adding cert (3680 bytes) with certificate key password.
*TransferTask: Mar 06 20:30:32.564: RESULT_STRING: Certificate installed.
                Reboot the switch to use new certificate.
*TransferTask: Mar 06 20:30:32.564: RESULT_CODE:11
*TransferTask: Mar 06 20:30:32.565: ummounting: <umount /mnt/download/ >/dev/null 2>&1>  cwd  = /mnt/application
*TransferTask: Mar 06 20:30:32.576: finished umounting

So, the next (and more important for this) task was to take the wildcard certificate and key files that were used for NCS and combine them for the WLC.  First I combined the cert and the key into a single PKCS#12 file using the following command (I don’t believe that the passin is necessary, but I used the password for the original PFX file anyways.)

openssl pkcs12 -export -in cert.pem -inkey key-nopw.pem -out cert.p12 -clcerts -passin pass:12345 -passout pass:12345

The output from this was a single file (guest.p12) with the line “Loading ‘screen’ into random state – done” after the command.  Next, I converted the PKCS#12 file into a PEM file.

openssl pkcs12 -in cert.p12 -out newcert.pem -passin pass:12345 -passout pass:12345

This produced a PEM certificate (newcert.pem) and the line “MAC verified OK” after the command.  I then uploaded that file as an HTTPS administration certificate (Management>HTTP-HTTPS>Download SSL Certificate) using the Certificate Password “12345”.  And it worked!!! Here is the debug output.

*TransferTask: Mar 06 20:42:17.633: Memory overcommit policy restored from 1 to 0
*TransferTask: Mar 06 20:43:14.151: Memory overcommit policy changed from 0 to 1
*TransferTask: Mar 06 20:43:14.192: RESULT_STRING: TFTP Webadmin cert transfer starting.
*TransferTask: Mar 06 20:43:14.192: RESULT_CODE:1
*TransferTask: Mar 06 20:43:18.193: Locking tftp semaphore, pHost=192.168.1.2 pFilename=/newcert.pem
*TransferTask: Mar 06 20:43:18.275: Semaphore locked, now unlocking, pHost=192.168.1.2 pFilename=/newcert.pem
*TransferTask: Mar 06 20:43:18.276: Semaphore successfully unlocked, pHost=192.168.1.2 pFilename=/newcert.pem
*TransferTask: Mar 06 20:43:18.276: TFTP: Binding to local=0.0.0.0 remote=192.168.1.2
*TransferTask: Mar 06 20:43:18.891: TFP End: 4561 bytes transferred (0 retransmitted packets)
*TransferTask: Mar 06 20:43:18.891: tftp rc=0, pHost=192.168.1.2 pFilename=/newcert.pem
               pLocalFilename=cert.p12
*TransferTask: Mar 06 20:43:18.891: RESULT_STRING: TFTP receive complete... installing Certificate.
*TransferTask: Mar 06 20:43:18.891: RESULT_CODE:13
*TransferTask: Mar 06 20:43:18.891: Adding cert (4525 bytes) with certificate key password.
*TransferTask: Mar 06 20:43:19.165: RESULT_STRING: Certificate installed.
               Reboot the switch to use new certificate.
*TransferTask: Mar 06 20:43:19.166: RESULT_CODE:11
*TransferTask: Mar 06 20:43:19.166: ummounting: <umount /mnt/download/ >/dev/null 2>&1>  cwd  = /mnt/application
*TransferTask: Mar 06 20:43:19.178: finished umounting

I then uploaded the same for Web Authentication (Security>WebAuth>Certificate>Download SSL Certificate,) again using the same “12345” certificate password.  And, that was accepted as well.  As required, I rebooted the WLC.  After rebooting, I tried logging in using the DNS hostname of the WLC.  No certificate error.

I haven’t had a chance to validate the web authentication for the SSID, but I will update this post once that is done.  Given the success of the web administration, I’m fairly confident that will succeed as well.  Hope this helps you in working with WLC and certs.

(Side note: I also uploaded the certificate as a Vendor Device Certificate  Again, we’ll test to verify the Local EAP.)