This discussion is locked

Ask the Expert: Wireless LAN Security

Unanswered Question
Oct 3rd, 2013

Wireless LAN SecurityWith Jeal JimenezATE_Discussion-New-Icon_Nov2012_v2.png

Welcome to the Cisco Support Community Ask the Expert conversation.  This  is an opportunity to learn and ask questions about about how to implement, configure, and troubleshoot WLAN security with expert Jeal Jimenez. 

Our expert will also discuss how WLAN security works and the different security methods that are available and implemented on enterprise WLANs to validate clients and protect their traffic along with the network. 

Jeal Jimenez is a customer support engineer for the Cisco High-Touch Technical Support department specializing in wireless LAN technology. Prior to joining the HTTS department, he worked as a customer support engineer focused on wireless LAN in the Technical Assistance Center before he was promoted to an escalation leader and trainer, working also as a Cisco lab admin during these years. Jeal's technical expertise in the area of wireless LAN technologies spans more than seven years, and he also contributed to Cisco documentation and to the CCIE Wireless written exam. He holds a bachelor's degree in systems engineering from Universidad Latina in Heredia, Costa Rica. Jeal also holds the certifications CCNA, CWNA, CWSP, CCNP, and CCIE wireless (# 31554).

Remember to use the rating system to let Jeal know if you've received an adequate response. 

Because of the volume expected during this event, Jeal might not be able to answer every question. Remember that you can continue the conversation in the Wireless - Mobility community, subcommunity, Security and Network Management, shortly after the event. This event lasts through October 18, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.

      

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (65 ratings)
swapneswar panda Mon, 10/07/2013 - 08:15

Hi jeal,

I am now in my preparation for CCIE security LAB v4. While going through the details i came through about Wireless seurity parts. So would you mind to please suggest some tips to corelate this for my preparation ?

Thanks

swap

jeajimen Mon, 10/07/2013 - 09:26

Hello Swap,

I am not completely aware of the Wireless security topics covered by the Security CCIE, but checking the Lab blueprints and software/hardware list, I will say that you should know how to deploy secure authentications on a WLAN using a CUWN (Wireless LAN Controller and Lightweight APs), with an ACS or ISE as the Authentication Servers; this means:

- Learn about how to configure on the WLC some WLAN/SSIDs for 802.1X/EAP authentication methods with WPA or WPA2 (for key management, using TKIP or AES-CCMP for encryption), defining ACS or ISE as the RADIUS Server.

- Understand the differences between the multiple types of EAP authentication methods that you could deploy for a WLAN (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, and probably EAP-FAST with different inner method types). Some methods authenticate clients with username/password credentials, some with client certificates, some only use server side certificates to tunnel/encrypt the client credentials’ handshake, some could do machine authentication or multifactor authentication, etc. So depending on the requirements, you might need to deploy the appropriate EAP method, which might involve PKI.

- Learn how to configure the settings for those EAP authentication methods (including certificates installation) on the client side (wireless IP Phone or AnyConnect Client or perhaps Windows supplicant) and on the ACS/ISE side. The following is just one possible configuration example for you to start getting some hands-on on this topic:

http://www.cisco.com/en/US/products/ps10315/products_configuration_example09186a0080bd1100.shtml

- You might need to be familiar with most of the BYOD deployments possible on WLANs using the ISE, so you could start with the following guide to understand what I am talking about:

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bba10d.shtml

- I will say that you should be also familiar with Layer-3 Web Authentication for guest users using an ISE, such as in the following examples:

http://www.cisco.com/en/US/products/ps11640/products_configuration_example09186a0080bead09.shtml

http://www.cisco.com/en/US/products/ps11640/products_configuration_example09186a0080c13287.shtml

- In addition, it seems you should be familiar with wireless IPS (remember there are multiple attacks and threats to the network that can only happen over the air or with WLAN equipment, and only be detected/mitigated by wireless IDS/IPS). Therefore, I will recommend you to check the “Cisco Adaptive Wireless Intrusion Prevention System Configuration Guide” to get familiar with this topic:

http://www.cisco.com/en/US/docs/wireless/mse/3350/7.0/wIPS/configuration/guide/msecg_ch1_wIPS.html

- Regarding this topic, a WLC can also be integrated with wired IPS to mitigate some attacks coming from the WLAN that don't really need wIPS, so you might want to check if this wired IPS solution is valid for your exam version:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807360fc.shtml

Hope this can help you with your studies! Wish you the best on your CCIE journey!

- Jeal

swapneswar panda Mon, 10/07/2013 - 09:45

Hi jeal,

Many thanks for these many information. i can say you that definitely i was missing some good stuffs which i was not aware (like wireless IPS). I will go through all you mentioned URLs for docs and definitely will revert with my next concerns .

Thanks

swap

egordon310 Mon, 10/07/2013 - 16:10

Hi Jeal,

What recommendations do you have to troubleshoot a WLAN where the authentication is failing?  Thanks for your help on this.

Evan

jeajimen Mon, 10/07/2013 - 19:15

Hi Evan,

I think the best way to troubleshoot an authentication issue is by first understanding the process of the security method implemented, so let me summarize how 802.1X/EAP works, as this is basically the authentication framework implemented on WLANs:

*** Components ***

- Authentication Server: For WLANs this is a RADIUS Server where the authentication of the wireless clients actually takes place (ACS, ISE, Windows NPS, etc.). Here you define the specific EAP method that you want to allow and its settings (certificates, policies, etc.). Here you also have a local database with the client´s credentials to be checked, or it could be linked to an external database.

- Authenticator: This is the WLC/AP, and the role is basically to act as a "proxy" between the wireless client to be authenticated and the RADIUS Server that performs the authentication. Here you configure the SSID to force dot1X/EAP negotiation with the wireless clients trying to associate to this WLAN (using a specific key management and encryption method, like WPA/TKIP or WPA2/AES), and you define the RADIUS Server that will be used for this authentication.

- Supplicant: The wireless client trying to connect to the secure WLAN. Here you configure the SSID profile that will be used for the association to this WLAN. You define the specific EAP method, and the client security credentials (username/password, certificates, tokens, etc.).

*** Process ***

- The wireless client starts the association to the WLAN using the specific SSID and selecting an AP to connect.

- Once basic wireless association is successful, WLC/AP sends an EAP identity request to the client in order start doing 802.1X/EAP.

- The wireless client should answer back with an EAP identity response.

- This response is sent from the WLC/AP to the RADIUS Server on a RADIUS Access-Request packet.

- RADIUS Server processes the request and it replies back with a RADIUS Access-Challenge to start the EAP negotiation with the client (basically offering the client to start doing the EAP method that was configured for the wireless security policy).

- WLC/AP receives this Challenge, and forwards it to the client as an EAP request.

- Client answers back with an EAP response, which is forwarded by the WLC/AP to the RADIUS Server on another Access-Request. From here, the same exchange will happen multiple times between the server and the client (using the WLC/AP as intermediary) while the EAP method is negotiated and credentials are validated/authenticated. Depending on the EAP method we will see more/less exchanges, but in the end, the server should send to the WLC/AP a RADIUS Access-Accept if it passes or a RADIUS Access-Reject if it fails.

- The WLC/AP will inform the client about this result and deauthenticate it from the WLAN if it failed, or allowing it access to the network so it can start passing data traffic (client asking now for an IP address for example, as layer-2 is fully established now).

*** NOTES ***

- EAP is not a specific authentication method, it is just the name of the base protocol. Based on this, a specific EAP method is configured depending on our needs, requirements, and what the devices support (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, EAP-FAST/MSCHAPv2, EAP-FAST/TLS, EAP-FAST/GTC, etc.).

- This EAP method is only defined on the client (supplicant) and RADIUS Server (Authentication Server). Not on the WLC/AP (Authenticator).

*** Troubleshooting ***

Knowing that, without the need of understanding all the details about the specific EAP method deployed or about WiFi, you can easily Troubleshoot a WLAN authentication issue as follows:

1) First of all, check if the issue is happening to multiple clients/devices. If this is only happening to one, then more likely the issue is with the credentials of that client, or with the supplicant SSID setup on that client for the specific EAP method (or with the device itself, hardware or software).

2) If you confirm this is happening to multiple clients, then select one or two to troubleshoot. Check if the client is trying to connect to the SSID. If it is not even trying, the SSID is more likely not properly configured on the WLC/LAP.

3) Check the WLC/AP client association table so you can see the client status, if it is even trying to connect and what the status is. For example, on a Cisco WLC you will notice that the client is stuck on the authentication process because the client status will be 8021X_REQD.

4) If you noticed that the client is trying but failing or stuck on the authentication phase, then immediately check the failed attempts (failure authentication logs) on the RADIUS Server.

5) The server logs should normally tell you the reason of the authentication failure, but if you don´t see any attempts at all, then there could be an issue between the WLC/AP and the server. If there are failures on the server, the reasons are normally: EAP method not defined or not properly configured on the server or the client, wrong credentials, request is not matching the security policy defined, RADIUS Server has an issue with the external database (if used), RADIUS Server doesn´t know the WLC/AP trying to talk to it (it should be configured as AAA client -NAS- with a valid shared secret), the EAP method defined requires certificates from a CA (at least on the Server) and this is not properly setup... The server logs should normally be clear on the specific reason.

6) If you can´t find any logs at all on the server for attempts from this client and you know the WLC/AP is properly configured to communicate with this specific RADIUS Server, then there could be an issue between the WLC/AP and the server, so you might want to check network connectivity between them (proper routing, no ACLs/firewall blocking RADIUS traffic, no fragmentation issues, etc.). At this point, you could start this network troubleshooting between the Authenticator and the Authentication Server, but you could also start some debugging on the Authenticator, as this will clearly confirm if the problem is on the WLC/AP itself, in the client side, or in the server side, as you should see IF:

- The WLC/AP even started with the EAP identity request or not.

- If the client is responding or not.

- If the WLC/AP is sending the request to the proper server or not.

- If the server is responding (and how) or not.

- If this response is forwarded to the client and if the client is responding, and then forwarded back to the server... Until the point you notice a failure due to a lack of response from the client, from the server, or because the WLC/AP is not forwarding what it should where it should. You could even check if the failure is happening during the key management negotiation (which normally happens due to software issues if the client actually supports the one configured on the WLC/AP).

Debug Notes:

- On a Cisco WLC, you could use the following debugs:

debug client

debug aaa all enable

- On Autonomous IOS APs, you could use the following debugs:

debug radius authentication

debug dot11 aaa authenticator process

debug dot11 aaa authenticator state-machine

7) After this, you will definitely focus your troubleshooting on the WLC/AP, the client side, or the server side, checking deeper connectivity between them (packet captures if needed), the settings of the specific EAP method defined on the client and the server, or looking for software issues due to bad behaviors on any of the three components.

Apologies if this is too long, but I hope it is clear enough to deal with these type of issues.

Regards,

Jeal

tonyp8581 Tue, 10/08/2013 - 12:53

Hi Jeal,

Your explanation on authentication process is greatly appreciated.  Very well done.

Thanks !!

jeajimen Tue, 10/08/2013 - 13:05

Hi Tony,

I am glad to know it was helpful!

If further questions arise about that (the process or troubleshooting), please feel free to ask.

PS: If you want to get more details about the authentication process, checking wireless packet captures and WLC debugs, including details about the processes when roaming or when Fast-Secure roaming with any of the supported methods, I will recommend checking the document I posted recently about "802.11 WLAN Roaming and Fast-Secure Roaming on CUWN" (let me know if there are also questions about this):

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080c1a517.shtml

Regards,

Jeal

AJCamacho Wed, 10/09/2013 - 07:21

Hi Jeal,

I was wondering if the Web Auth Redirect URL configured in the WLC can point to an ISE Administration Node (PAN) instead of a Policy Service Node (PSN).

thanks

Abraham

jeajimen Wed, 10/09/2013 - 08:46

Hi Abraham,

That is not possible, as the Policy Service Node (PSN) is the only node type (ISE Persona) that communicates with the Network Access Device (the AAA Client, in your case the WLC, using RADIUS protocol) to provide the network access, posture, guest access, client provisioning, and profiling services... Basically, this is the ISE Node/Persona that actually evaluates the policies for the requests coming and makes all decisions based on that.

The ISE Administration Node on the other hand, is the ISE persona that allows you to perform all administrative operations on the ISE itself, handling all ISE system-related configurations regarding the functionality of the services it provides. So this is basically the Node for the Administration of the ISE, not to validate the policies configured on the ISE (as this is handled by the PSN as mentioned above).

Regards,

Jeal

AJCamacho Wed, 10/09/2013 - 09:56

Hi Jeal,

Just to clarify my question and based on your answer, the ISE Admin Node would not have the Web Portal feature activated (see picture below) therefore the following steps for Web Auth can not be completed using this Node as Web Auth Redirect URL Server configured in the WLC because it wont work as external web server and could not send the request back to the action_url including credentials, right?. (please assume Web Auth in the picture below instead of MAB).

thanks

How to Make an External (Local) Web Authentication Work with an External Page

As already briefly explained, the utilization of an external WebAuth server is just an external repository for the login page. The user credentials are still authenticated by the WLC. The external web server only allows you to use a special or different login page. Here are the steps performed for an external WebAuth:

  1. The client (end user) opens a web browser and enters a URL.


  2. If the client is not authenticated and external web authentication is used, the WLC redirects the user to the external web server URL. In other words, the WLC sends an HTTP redirect to the client with the website's spoofed IP address and points to the external server IP address. The external web authentication login URL is appended with parameters such as the AP_Mac_Address, the client_url (www.website.com), and the action_URL that the customer needs to contact the switch web server.


  3. The external web server URL sends the user to a login page. Then the user can use a pre-authentication access control list (ACL) in order to access the server. The ACL is only needed for the Wireless LAN Controller 2000 series.


  4. The login page takes the user credentials input and sends the request back to the action_URL, such as http://1.1.1.1/login.html, of the WLC web server. This is provided as an input parameter to the customer redirect URL, where 1.1.1.1 is the virtual interface address on the switch.


  5. The WLC web server submits the username and password for authentication.


  6. The WLC initiates the RADIUS server request or uses the local database on the WLC, and then authenticates the user.


  7. If authentication is successful, the WLC web server either forwards the user to the configured redirect URL or to the URL the client entered.


  8. If authentication fails, then the WLC web server redirects the user back to the customer login URL.


jeajimen Wed, 10/09/2013 - 10:30

Hello Abraham,

Exactly, you're right! The Web portal is actually the PSN, not the Administration Node.

Regards,

Jeal

andrew.vlasek Wed, 10/09/2013 - 10:24

Jeal,

This may be a broad question but in general what type of securtiy measures and monitoring would you consider best practice? I have 5508 controllers and I did not pay for the enhanced WIPS capabilities but I am utilizing the built in WIPs functionality of the controllers and I am inundated with security alerts such as "broadcast probe flood" or "deauth flood" as examples. When I read the forums every security alerts leads down the path of contacting TAC and TAC indicating this is probably a false positive. I have my wireless networks firewalled. I have setup industry best practive encryption and authentication, so my question is does the WIPS provide much value? Does Cisco monitor and taking action or investigate these type of alerts internally? I posed this question to other Cisco contacts and I haven't been able to get much information.

Thanks,

Andrew

jeajimen Wed, 10/09/2013 - 13:16

Hi Andrew,

Let’s talk a bit about wireless threats/attacks and wireless IDS/IPS, and if this doesn’t address your concerns, please let me know so we can expand the discussion…

- There are multiple threats/attacks that can happen over the air and your wired IDS/IPS/firewall can’t really do anything about them; not even firewall rules on the wireless devices. For example, a wireless device can attack your WLAN by sending deauthentication frames to all or some of the wireless clients ("deauth flood”) connecting to a specific AP, so this attack will easily keep disconnecting the clients (basically causing a DoS attack because your wireless clients will continue dropping the WLAN). How does the attacker do this? Wireless clients should accept/follow any “instruction” from the AP they are connected to, so if the AP asks them to disconnect the WLAN/SSID using a deauthentication frame, they should follow this request and disconnect. So the attacker’s trick is to impersonate the AP by sending all these deauthentication frames on behalf of the AP, which is easily done by finding the AP’s MAC address with some wireless packet captures. An attack like “broadcast probe flood” can be a device/attacker sending multiple probes to an AP, forcing it to send probe responses to those multiple requests (as the 802.11 standard defines that the APs should answer back with a probe response when a client is looking for an AP. There are actually multiple attacks that can be done based on the way WiFi works to establish initial associations, where AP should answer back to clients trying to connect/authenticate), consuming not only AP resources but also channel/RF resources (leading to another possible DoS attack).

- So basically, these attacks are happening only over the air without ever touching the wired infrastructure; these “attack” frames are not traveling through any of the infrastructure devices (not even over the AP, or WLC, or firewall), so they can’t be avoided or blocked. For example, on the "deauth flood” the attacker simply directs the frame from its machine to the wireless clients by sending a deauthentication frame over the air on the specific channel used by the impersonated AP. For such an attack, we could say that there is nothing that can be done from the infrastructure perspective, as we can’t stop a device that is not even connected to the WLAN to continue sending deauthentication packets over the air to the clients. However, there is a feature called Client MFP (Management Frame Protection) that could avoid this attack (by having the clients ignoring these frames that can’t be avoided) as the deauthentication frames from the “official” AP are secured and you don’t need a wIPS to implement this, but the limitation is that you need some specific requirements to enable this on a WLAN/SSID (specific security, and wireless clients Must support this as well). The following document explains this feature:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008080dc8c.shtml

- Some other attacks where the attackers “flood” the AP/WLC with multiple authentication attempts (perhaps doing dictionary attacks to some credentials trying to connect to a secure network, or simply trying to cause a DoS attack to the WLAN) can also be mitigated with just the WLC (without the Adaptive wIPS) by enabling the client exclusion feature, where these devices will be excluded from trying to connect to the WLAN (WLC/AP will simply not respond to these excluded devices) after failing the authentication a certain amount of times. This applies to excessive 802.11 authentication and association failures, 802.1X authentication failures, Web-Authentication failures, or even IP theft or IP reuse.

So what do you get with the Adaptive Wireless IPS solution if your WLCs are already detecting attacks by just having the managed APs monitoring the air to find attacks with behaviors matching the signatures already implemented on the internal WLC IDS/IPS?

- First of all, there are a few signature updates that can only be deployed with the Adaptive wIPS, so some attacks might not be recognized by the WLC’s signatures.

- The Adaptive wIPS involves the Cisco MSE with the WCS/NCS/PI, where you might be able to track the attackers’ estimated locations using the maps configured here and Cisco’s location/wIPS technologies.


- In addition, you might be able to better monitor the attacks (with alarms and even email notifications).

- You could even avoid duplicate attack notifications by multiple WLCs, as they will be all working with the MSE to recognize that the attack reported by one WLC is the same that another reported. Now, even if you don’t have Adaptive wIPS and MSE, all your WLCs managing APs that can hear APs from other WLCs, should be configured within the same mobility/RF group and with the same wIPS policies; otherwise, your own WLCs might be reporting false alarms based on what is happening on your other APs/WLCs.

- The following "Cisco Adaptive wIPS Deployment Guide 7.4" should give you more details:

http://www.cisco.com/en/US/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_guide.html

Conclusions

- As you could imagine, some wireless attacks can’t be avoided at all. Going back to the "deauth flood” example, you can’t stop an attacker to continue sending frames over the air affecting clients that can’t do MFP, as you can’t control the AIR (such as you will control your Internet link traffic with a Firewall for example).

- Adaptive wIPS can’t stop such attacks either, however, you might be able to find the attackers location so you can go and find him/her to take appropriate actions against the actual person (yes, not a networking/technology response, but a task for a human :-)).

- On very crowded environments and with multiple types of wireless clients, some attacks could be actually a false alarm due to multiple clients just trying to connect to a WLAN that they can’t join due to security, or even just because there are wireless clients with software/drivers issues (for example, sending probes like crazy, and not really actively trying an attack). Remember the attacks are “recognized” based on signatures, so the behaviors here might be reaching the signatures frequency within the specific intervals, triggering the alarms.

- There are also possibilities that your WLAN could be attacked by a neighbor’s infrastructure WLAN. For example, our WLCs support a feature called AP Containment, where we will “attack” a malicious Rogue AP (for example, an unofficial AP connected by someone to one of your switchports). The way this works is that the WLC’s LAPs around this Rogue AP will start sending deauthentication frames to the clients trying to connect to this Rogue AP (basically doing the attack explained above), so we can avoid having clients connecting to this malicious Rogue and avoid them access to your network. The problem is that a WLAN administrator might be mistakenly attacking another company’s APs thinking that they are malicious Rogue APs, so you might want to check that this is not the case on your network (here, wIPS can’t do anything for you either; you will need to go and talk to the WLAN admin of your neighbors… Another task for a human).

- In the end, how can you confirm that there are actually some of these attacks happening on your RF environment? Some wireless packet captures will definitely tell the truth (taken around the AP reporting them and sniffing the channel reported), showing all those possible attack frames and behaviors.

Hope this can help!

Jeal

andrew.vlasek Wed, 10/09/2013 - 14:12

   That does help to some degree because it backs up my assumptions that most of the security alerts are if anything  DDOS attacks or mi-interpreted trafic, but do you have any feedback on the fact that a lot of the events tend to be false positives? I get events that turn out to be my own clients and they are not doing any sort of attack indicated in the security alert email I get. If you search the forums in most cases people report TAC told them its a false positive and to tune the signature which in some cases is not very configurable.

   Also I do already have an MSE and I get email alerts from prime infrastructure 1.3 and I have context licenses to track location I just don't get  the additional signatures that comes with the Adaptive WIPS licenses but either option (basica or adaptive) are their really any non RF DDOS type attacks? Without having the dictionary of signatures in front of me I don't remember them all, but are there any signatures I should be more concerned with? And regardless of adaptive WIPS or basic WIPS does either really help security other than from DDOS perspective? I see DDOS almost essentially like  a performance concern or reliability concern where if I see an issue my troubleshooting would start with looking at the affected AP looking for continuous transmitters and then security events.  I am less concerned with DDOS. I am more concerned some device getting unauthorized access.

I am being asked by my team can we shut off these annoying security alerts and I am finding it harder and harder to find a good reason not to at least from an email perspective. If I am having a performance issues then I would then look for continuous transmitters or DDOS attacks. I tried turning on MFP initially and had issues with that to where it didn't look like a road I wanted to go down ensuring client compatibility.

I am also already using the exclusion feature to block clients after multiple failed attempts. I am planning on integrating out wired infrastructure into prime 2.0 so that I can ensure that no authorized AP are broadcasting on our network. Am I missing anything do you have any other suggestions for security? On thing we currently don't have is wired IPS on the wireless infrastructure, but we do only allow corporate boxes with anti-virus on corporate wireless.

Thanks,

Andrew

jeajimen Wed, 10/09/2013 - 14:43

Hi Andrew,

I will need to do some troubleshooting to confirm that they are actually false positives, confirming the specific "attack" type and if it is actually a valid client as clients can also be impersonated like APs (perhaps getting some packet captures and checking the client behavior during the period the attack is reported)... But I can definitely tell you that some crowded environments and bad client behaviors could generate these false positives (bad client software/drivers as mentioned before, or bad client setup with credentials that keep failing to connect, or that decide to send deauthentications/dessasociations to leave the WLAN, or that send multiple probes just because they have a lot of WLAN profiles configured/learned or a software installed for this, etc.).

The document I shared about the wIPS deployment guide has some tables with the specific features and signatures added with the Adaptive wIPS or even with CleanAir APs, so I will recommend checking that for a more detailed list. What I can tell you is that most are related to DoS attacks as you mentioned, but remember that some of them could be related with actual threats to the network (for example, dictionary attacks trying to guess the password for some of your users, so they can then get access to your network using valid credentials).

Those "dictionary attacks" can be avoided with the exclusion feature, so you don't really need Adaptive wIPS for this.

Therefore:

- If you are not really concerned about those type of "wireless/RF specific attacks" (most of them DoS, as they basically attack the RF and 802.11 behaviors), then it is up to your security policies if you want to configure your setup to continue reporting these alarms or not.

- Also, if you already have a very good security implemented for your WLAN (strong EAP authentication tunneling the credentials or using certificates for example, and with WPA2 for key management encrypting with AES-CCMP), then I would say that your WLAN is secure enough and real attacks (other than DoS or password guess) can't really happen to your network from the wireless infrastructure (yes, WLANs are this secure nowadays if using proper authentication/encryption), but I would need to analyze your entire deployment and security policies (penetration tests) to confirm that you are completely secure

- Firewalls or wired IPS, or even WLC's Applications Visibility should be able to analyze traffic for valid clients already connected to the network if this is a concern (excluding the client as well or dropping traffic if needed; this doesn't need Adaptive wIPS).

If you want to share more details of your WLAN to get more feedback or if I didn't address some of your concerns, please feel free to let me know.

Regards,

Jeal

jorge.covenas Wed, 10/09/2013 - 15:16

Hi Jeal,

Please help me with this scenerio:

- I have WiSM2 in 6509-E, I have configured 4 SSID

- I want that some users can login to WiFi network only with one device per-time. I know I can set it globaly on the WLC - Security > User Login Policies.  change that value from 0(unlimited) to 1.

- But I need VIP users can login with more than one device per-time. In add, in one SSID we don´t need the restriction for number of devices.

Thanks in advance.

Jorge Coveñas

jeajimen Thu, 10/10/2013 - 10:14

Hi Jorge,

As you have noticed, the User Login Policies feature on the WLC is the one we have for this type of Max-Sessions restriction per user; however, this is a global setting and applies to all SSIDs, so there is really nothing that could be configured on the WLC to do exactly what you need.

What I can tell you is that you might be able to achieve this specific setup that you need (basically based on SSID, with Max sessions configured for some SSIDs and unlimited on the VIP SSID) but configuring the restrictions based on policies on the Authentication Server side. I remember this was possible on ACS 4.x and probably 5.x using SSID restrictions, but as far as I know, this is only possible on ISE for the guest users...

So if you have a Cisco RADIUS Server, I will recommend you to open a TAC case with the AAA team asking for assistance to setup this specific restriction based on your needs. If it were not supported on the specific server/version you have, you might be able to ask for the feature (in this case you could also get in touch with your Cisco account team to drive a Product Enhancement). If you are using a third-party RADIUS Server to perform the authentication on your WLANs, then I will recommend checking their documentation (or contacting their support) to check if this type of Max-sessions per user restriction is possible on their server.

Regards,

Jeal

kamalmander Thu, 10/10/2013 - 00:20

Hi Jeal,

Is there a way to deploy Radius authentication using Microsoft 2003 or 2008 server(Only IAS/NPS) without installing any certifiacte on Server side.

What type of security types does controller supports(eg EAP-TlS,EAP-TTLS, MsCHAPv1 etc)

Is it possible to use CHAP or MsCHAP without using PEAP(without using them as inner method.)

Regards,

Kamal

jeajimen Thu, 10/10/2013 - 11:03

Hello Kamal,

I will recommend you to read the second answer I provided on this event (Oct 7 answering to Evan), so you can better understand how secure authentication (802.1X/EAP) works on a WLAN.

To answer your specific question, no, you can't really deploy any authentication method for WLANs on the Windows 2003/IAS or Windows 2008/NPS servers without using certificates.

That is basically because those Windows servers only support EAP methods for WLANs (PEAP and EAP-TLS) that require certificates at least on the server side; hence the requirement of the PKI to have a CA issuing at least the server certificate (good news is that you normally use the same Windows server as the CA).

EAP-TLS requires the certificate on the server and on the clients since they will be authenticated based on this type of client credentials (a certificate).

PEAP can authenticate the clients using other type of credentials (such as AD username/password), but the certificate on the server is still required as this one is used to build a TLS tunnel between the client and the RADIUS Server in order to protect the client credentials during the authentication handshake (the P on PEAP actually stands for protected: Protected EAP; hence the server certificate, to protect the client credentials on a TLS tunnel).

You don't really need to worry about what type of authentication method is supported by the WLC, as this is not actually defined or limited by the Authenticator (we could say that the WLC/AP don't worry about the authentication method), but as I explained to Evan on my other answer, the specific authentication method to be used is defined on the wireless client and the RADIUS Server... So the question here is about what 802.1X/EAP authentication methods are used on WLANs, and mainly what methods are supported by your RADIUS Server and the supplicant of your wireless clients (the limitation about the EAP method to be used is actually found here).

Regards,

Jeal

smailmilak Thu, 10/10/2013 - 01:04

Hello,

can you please tell me if I need two AP licenses if I have two

AIR-CT2504-HA-K9 working in HA mode?

Do I need additional software for HA (Prime NCS) or is the included software enough?

kamalmander Thu, 10/10/2013 - 01:25

Hi Smailmalik,

Yes as 2504 only supports n+1 HA and does not support AP sso.

If you plan on making other controller as backup you need another licence.

Please check document given below for N+1 HA licensing.

http://www.cisco.com/en/US/docs/wireless/technology/hi_avail/Licensing.html

Q. What behavior can I get with the -HA SKU on the Cisco 2504 Wireless Controller (CT2504)?

A. Starting 7.5, the HA SKU on the Cisco 2504 can operate only in N+1 mode. It does not support access point or client SSO.

And please post question in correct discussion, this is WLAN security discussion.

regards,

Kamal

smailmilak Thu, 10/10/2013 - 01:31

Hello,

if I have one AIR-CT2504-15-K9and one AIR-CT2504-HA-K9which can work only as secondary/backup WLC

then I don't need an second license?

I read this on this document
http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/qa_c67-714540_ps2706_Products_Q_and_A_Item.html

under

Standby Controller Licensing

"

Q.

Do I need to buy access point licenses on my standby controller?

A. No. When the active controller is unavailable, the standby controller will adopt the licenses from the primary controller. It is expected that the customer will be able to get the primary controller back online within 90 days. After 90 days, the customer will get a daily reminder to switch back to the primary controller."

jeajimen Thu, 10/10/2013 - 10:43

Hi Smailmilak,

Even when the 2500 WLC can't really do AP/client SSO HA, the 2500 HA SKU (AIR-CT2504-HA-K9) can be purchased to be used as the secondary/backup WLC on the N+1 HA setup mentioned on the document you referenced.

So regarding your specific question, no, you don't need any license on the 2500 HA SKU as the HA part is already licensed from factory to support the maximum amount of APs for the specific WLC model (as it is supposed to be used as a backup, so that's why you get the reminder about switching back the APs to the primary WLC, which is the only controller that should have a license for the specific amount of APs that you need).

Regards,

Jeal

smailmilak Thu, 10/10/2013 - 23:29

Great, thank you.

The reminder is just a reminder and the backup WCL will not stop to work after a 90+ days?

jeajimen Fri, 10/11/2013 - 09:27

Hi Smailmilak,

Just a reminder because you shouldn't be using this HA WLC as the only primary WLC for your APs... But the WLC won't stop working after this period.

Regards,

Jeal

sebastian.ingenerf Thu, 10/10/2013 - 11:04

Hi,

i've got a upcoming poc for a guest access solution and the scenario looks like this:

Guest Access with Captive Portal -> Internet only

Internal users with Captive Portal -> Internet only

Here is the deal:

How to avoid the reauthentication for internal users and stop them from using their private phones?

One idea was an MDM integration with Cisco ISE and check if the devices are registered in MDM, but i guess with an CWA "sleeping client" doesnt work ?!
The other idea is to make whitelist on Cisco ISE but how to keep it updated without alot of work?

5508 controller 7.5
Airwatch MDM
Cisco ISE

Any ideas?

Thanks in advance

Seb


Sent from Cisco Technical Support iPad App

Sent from Cisco Technical Support iPad App

andrew.vlasek Thu, 10/10/2013 - 13:12

Sebastian,

When you say simple and your talking about NAC and MDM policies with personal devices I don't think you can use simple in that discussion. Especially not if your controlling a personal phone let alone a business provided phone. I actually use a third party radius (nac) but I am sure ISE can do the same thing where you use its profiling capabilities to determine if the device is corporate or personal. What are you planning to manage on personal devices are you going to tell them what they can and cannot install? Do you need to do that if it is internet only? We provide internet only and we do not manage personal devices.

Andrew

jeajimen Thu, 10/10/2013 - 13:28

Hi Sebastian,

I honestly don't have too much experience with all the features and possibilities available on the ISE, so I am actually struggling with this request, but I will share my thoughts about this...

First, I am not sure if the sleeping client feature will affect this setup when trying to do it with MDM integration; I don't see why this should be a problem, so you could try it.

Regarding a whitelist on Cisco ISE, this is definitely a possibility, but surely a lot of work that can't be avoided unless you can do something like this:

Configure the MAB_Auth policy for the wireless captive portal on the ISE to use also "Internal Endpoints". Once the policy is configured to match Internal Endpoints, then you just need to make sure that the Internal Endpoints for this policy are only the devices that you want to allow for the Internal users without permitting smartphones for example (based on Profilling).

Regarding your question about how to avoid reauthentication for Internal users, I am not sure if I understood this correctly, but you can't really avoid this since this would be a security issue; once the clients have left (after the sleeping client timeout for example), they are basically removed from the client's list, so they should reauthenticate to the Web-Auth portal if they later come back...

Regards,

Jeal

sebastian.ingenerf Thu, 10/10/2013 - 14:18

Thank you for your replies.

@andrew

Only corporate devices will be managed. So with the integration of MDM in ISE i can filter the managed devices.
Private devices are not going to have any wifi.



@jeal

We want to reduce the reauthentications. So sleeping client would be a nice feature to use. My concern is that when we use ISE and its captive portal that this feature is not going to work. Profiling could be a solution, but I'm not sure it will work a 100%.

Regards

Seb

Sent from Cisco Technical Support iPad App

jeajimen Thu, 10/10/2013 - 15:30

Hi Sebastian,

Just wondering: Did you read any document saying that the WLC sleeping client feature doesn't work when using the ISE or CWA? (if so, I will appreciate if you can share it)

Or did you already try it and confirmed it doesn't work?

I can tell you that this WLC sleeping client feature works for layer-3 Web-Authentication, but it doesn't matter if you are doing local Web-Auth or CWA or using the ISE for any reason, so this feature should definitely help you to reduce reauthentications.

Basically the idea behind this feature is that the WLC is not going to deauthenticate or remove a guest Web-Auth client from its association list when it goes to sleep/inactive (as it used to happen after expiring the user-idle timeout), so if the client awakes before the sleeping client timeout, the WLC will simply allow it to continue passing traffic without the need of the reauthentication as if it were active during all this time (keeps the client in RUN state), and ISE has no idea of what happened during this time. ISE will come into the game if the WLC thinks that the client needs to be reauthenticated, but as long as the WLC doesn't force a new reauthentication (thanks to this new feature), then it won't contact the ISE at all and client will continue connected to the network without reauthentication.

Regards,

Jeal

egordon310 Thu, 10/10/2013 - 18:20

Hi Jeal,

Another question for you - what type of RADIUS Server will you recommend for a remote location with just a few APs? Back to the WLC? An external RADIUS Server on the remote locations or using the local RADIUS Server on the APs?

Thanks,

Evan

jeajimen Fri, 10/11/2013 - 09:24

Hello Evan,

Let me first describe the scenario to answer your question:

When you have APs installed on remote locations/offices from the WLC (over a WAN link, VPN, MPLS, etc.), the APs are normally configured in FlexConnect mode. Most of the time, you even do local switching for the WLANs/SSIDs used on these APs, so once the wireless clients are successfully authenticated, you can switch the client’s Data traffic on a local VLAN/subnet where the AP is directly connected (using their own local DHCP, gateway, and other local resources), instead of sending the client data traffic back to the WLC within the CAPWAP tunnel (normal behavior).

So for these scenarios, as you mentioned, you have basically three options to perform the authentication (802.1X/EAP with RADIUS) of the secure wireless clients: (1) Central Authentication back to the WLC, (2) Local Authentication performed by the AP itself against an external RADIUS Server, and (3) Local Authentication performed by the AP itself against its own local RADIUS Server feature. However, none of them is “better” to be recommended; the best choice is the one that meets your requirements (or even sometimes limitations, obviously being clearly aware of them), so this is what I can tell you about those possibilities available:


1)  Most of the time you will have the Authentication Servers and ID stores/databases (such as Active Directory) on the Data Center or main/central location. You will normally have the WLCs installed on this same location. In this case, and mainly if you need to centralize all authentications on your WLCs due to policies or specific requirements, for example:

- You just want to allow only the WLCs to communicate with your authentication servers.

- Assign specific attributes or apply policies that only work with central authentication on the WLC but not when the local authentication by the AP itself is performed.

- The client’s traffic can’t be locally switched, but only centrally switched due to requirements; so if you are not doing local switching but only central switching, you can only do central authentication back to the WLC.

- If the clients must be authenticated using your official ID stores (meaning no manual local lists can be configured due to the big amount of credentials or due to policies), but you can’t really replicate these ID stores to the remote offices/locations using also Backup Authentication (RADIUS) Servers installed on these remote locations.

- If you want to implement a specific Fast-Secure Roaming method to improve the roaming performance when using secure authentication, then you might need to perform Central Authentication back to the WLC depending on the method. You can check the document I had mentioned about Fast-Secure Roaming for further details on this topic:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080c1a517.shtml

You just need to make sure that the WAN/VPN/MPLS/etc. link between your WLC and the LAPs is meeting the requirements to send back to the WLC site all the traffic that you might need to send for the amount of clients that your link will support for this remote location. For example:

- Latency: No greater than 100 ms.

- Bandwidth: At least 128 kbps for deployments where up to eight APs are being deployed at a given location, but this also depends on the amount of clients.

- Path MTU: No smaller than 500 bytes is required, making sure that fragmented packets are also allowed in the path since some authentication methods might handshake with fragmented packets (such as when certificates are used, so the big packets used for the certificates are normally fragmented, and some WAN/VPN links might drop fragmented packets).

- QoS: Depending on the amount of traffic and type of WAN link or limitations, you might need to set the appropriate QoS policies on this WAN link to ensure CAPWAP traffic is not being affected.

2) Depending on the above (requirements, policies, or limitations), you will need to perform Local Authentication at the remote location where the APs are installed. If you can replicate the ID stores and install a RADIUS Server on this remote location to authenticate the clients, then this is definitely the way to go performing Local Authentication, where all of the APs on this site will use this RADIUS/DB to authenticate the clients without the need of traversing the WAN link. This option could also be a backup authentication option in case the link or central authentication setup fails.

3) If Local Authentication is needed due to the conclusions above, but you can’t really install a Local RADIUS Server on this remote location (and even less the ID stores), then you could use the Local RADIUS Server feature on the APs. For example, if you were migrating an autonomous IOS APs deployment where you were using the AP’s Local RADIUS Server, or because this is truly a small office where there is no need to use the official AD (Active Directory).

This is a very good option for those scenarios, and starting on CUWN 7.5, we now support even PEAP and EAP-TLS on the AP’s Local RADIUS Server (we used to support only LEAP and EAP-FAST before this software line), where the certificates are installed on the WLC and transferred from here to the APs of the FlexConnect groups. The limitation is that you will need to use a local (manually added) database configured on the WLC (also transferred to the APs), as this AP’s Local RADIUS Server feature can’t really talk to an external database (such as AD); but we already mentioned that this option will be deployed for a small amount of users where AD can’t be used. This option could also be a backup authentication option in case #1 or #2 setups fail.

Regards,

Jeal

CSCO12008989 Thu, 10/10/2013 - 21:36

We  have 5508 wireless controller  with 1142 aironet acess points.... we  configured Radius authentication  on ACS 5.3  for wireless users with WPA2 + 802.1x on WLC

when we take remote desktop connection of wireless client ... it disconnects after 10 sec.

and  when we logged in to client connectivity was lossed  .. I have to reconnect Manually ..

It was not happening before upgrading Security..

It's really frustrating for all our service engineers to work remotly ....... Please Help

jeajimen Fri, 10/11/2013 - 10:09

Hello Santosh,

I strongly recommend working on a TAC case for this issue, since it will require a deep troubleshooting to find out what is happening here.

What I can tell you is that this is not normal at all, and the 802.1X/EAP authentication should not affect any type of data traffic that is handled by the client once it was authenticated (so it shouldn't affect Remote Desktop connections). Some ideas:

- Your PC is also connected to the wired infrastructure while it is also wirelessly authenticated, so the client/OS is basically getting crazy sending traffic out of the wrong NIC or taking bad decisions (causing disconnects) due to this. This shouldn't be a problem, but can definitely happen as a client side issue.

- Your WLAN and RF environment is severely affected so you are facing disconnects or packet drops due to this, and when you add encryption to a WLAN, then you are actually adding more overhead to the traffic (the encryption overhead is normally not a real concern, but something to keep in mind depending on the RF environment or amount of clients/traffic).

- If you don't have a Fast-Secure Roaming method implemented, then roaming events could be breaking the remote desktop connections. If there are RF design issues, then wireless clients could be constantly roaming and hence this problem happening so often.

- Some policies applied by the authentication server to these clients are affecting Remote Desktop connections or other type of traffic.

- QoS policies on the WLC can be affecting some type of traffic.

- We basically can never discard a software issue somewhere when dealing with technology (hence the deep troubleshooting to find the culprit)

I will do the following to troubleshoot this setup while reproducing the issue:

1) Run debugs on the WLC:

debug client

debug aaa detail enable

debug aaa events enable

2) Get some packet captures to analyze the traffic flow and behavior. You can start with some captures sniffing the WLC port (or AP port if doing local switching) and the client PC (just wireshark or similar installed on the PC sniffing the wireless NIC; these are not wireless packet captures, but can show what is coming in/out for this client). If needed, you might need to sniff the AP port as well (even if doing central switching back to the WLC) and also get some wireless packet captures to analyze the Over-The-Air behavior. You can check the following post we have about wireless packet captures as this is actually a funny topic:

https://supportforums.cisco.com/docs/DOC-24502

Regards,

Jeal

CableWiFi Fri, 10/11/2013 - 10:31

Hi Jeal,

Is there a Cisco document you can refer me to that specifies the WAN backhaul requirements you mention above in terms of Latency, Bandwidth, Path MTU, etc. requirements?

CSCO12008989 Fri, 10/11/2013 - 20:55

Thank you for reply..

after Remot desktop connection When Client disconnects.. on client side i seen that it leaves ip address & shows limited acsess .I have to reconnect manually. 

and ACS shows Authentication failed for Machine not for user , see Acs log image when it disconnect, might help you.

regards

santosh

jeajimen Mon, 10/14/2013 - 13:10

Hello Santosh,

So if machine authentication is properly configured and passing successfully on the initial association, but client is then doing reauthentication (perhaps getting disconnected, or simply roaming but you don't have fast-secure roaming implemented, so full reauthentication must happen), and then machine authentication is failing when trying to reauthenticate, then more likely there has to be a software issue here that needs to be analyzed further (could be on the ACS, or even on the WLC, but this is why I mentioned that this will definitely require a deep troubleshooting analysis with debugs and further ACS logs).

I will focus mainly on why the clients are actually doing reauthentication (as this is the reason to then fail), but if everything is properly setup, then this reauthentication must be successful.

If you want, please share the ACS version and WLC software version so I can do some quick research looking for known bugs, but I definitely recommend a TAC case to analyze this further (this will be a very quick bug search, as I don't really have enough details to clearly understand the behavior here).

Regards,

Jeal

CSCO12008989 Mon, 10/14/2013 - 20:42

Thanks Jeal

Requested Details

WLC5508

Software Version 7.0.116.0

ACS Version 5.3.0.40

One more thing

We didn't configured Machine Authentication for wireless ... client Authentication is based on AD userid, password

but when we take Remote after 10 secs it's going for Machine Authentication not for user authentication .

jeajimen Tue, 10/15/2013 - 08:58

Hello Santosh,

I remember there was a software issue affecting the initial 7.0 codes when doing User & Machine authentication, but if you don't really have a setup with Machine authentication and just want to authenticate the users based on their AD user/pass credentials, then this is definitely not a WLC issue... If there is an attempt for machine authentication, it is because your wireless clients are trying to do machine authentication, so you need to check the setup on your wireless clients' supplicant.

Probably most of the problems you are having with this secure setup are due to client side issues (check drivers if possible), but for this, just make sure that your WLAN settings on the clients supplicant (the wireless configuration settings on Windows, or the specific software that you use to configure your WLAN/SSID settings) is Not trying to do machine authentication at all. For example, the following is the section on the Windows-7 OS supplicant to check this when you go to the WLAN/SSID properties:

sumitch Mon, 10/14/2013 - 02:06

Hi Jeal,

  What are the various troubleshooting steps we can look into when the web-authentication is not working. Specifically if the page does not come up or the page does not redirect to the internet page. Any suggestions will be highly appreciated.

Thanks and Regards

   Sumit

jeajimen Mon, 10/14/2013 - 09:22

Hi Sumit,

We have a very good document about troubleshooting Web Authentication on Cisco WLCs, where it first explains the Web-Auth process flow, so we can better understand the troubleshooting:

http://www.cisco.com/en/US/partner/products/ps10315/products_tech_note09186a0080a38c11.shtml

This document is great and covers a lot, but let me give you a summary of the troubleshooting I normally do:

- First, definitely make sure that the client is already wirelesslly connected and fully associated at layer-2, and it even has an IP address so it can start the HTTP session to be redirected to the Web-Auth page.

- We need to make sure that the clients are getting a valid IP address with a valid DNS Server that can resolve the IP address of the site you are trying to access. This is very important and normally the issue: Client didn't get a valid DNS from DHCP (or using a static one that doesn't work), client doesn't have connectivity to the DNS Server (public or private), or DNS server is not able to resolve the specific site you are trying to access when opening the Web browser.

- Based on that, make sure the client is connecting on a subnet/VLAN with proper Internet access. If the VLAN doesn't have Internet access, then the client can never start the TCP session with the initial web site that you try to access before getting redirected (or won't be able to reach a public DNS Server). I normally check Internet connectivity on the VLAN from the wired infrastructure (from the gateway of this VLAN for example), and then check that there is IP connectivity from the WLC's port to the gateway (in case there are layer-2 issues on this path).

- If using an internal private DNS server, then make sure that there is IP connectivity to this server as well; sometimes an ACL/policy could be an issue from the client's VLAN to the server's VLAN. Again, make sure this private DNS can resolve the Internet sites or even private web sites if used, for example, I have worked on problems where the client was not getting redirected because it was just opening the web browser and immediately trying to get redirected using the Home Page, which was a private company site (Intranet) that client's DNS couldn't resolve.

- Regarding this, make sure that the web site you are trying to access is HTTP (TCP port 80 is the only one the WLC listens at by default to intercept the traffic and redirect the client).

- In addition, make sure the clients are not using a proxy Web server, as this is not supported for Web-Auth redirection.

- If everything is fine regarding client's IP info and their Internet access, DNS, no ACLs or other policies, then you could try to access the WLC's web server page directly from the client using https://WLC_virtual_Int_IP/login.html

- If that works and you actually get redirected to the Web-Auth page going manually, then more likely something from the steps above is still failing (you will probably need to start getting some packet captures at this point, at least on the client's NIC and the WLC's port), but if this doesn't work, then there could be a problem on the WLC with the virtual interface (or a software issue).

- In that case, make sure the WLC virtual interface is properly configured, and if needed, reconfigure it (there could be an issue with the WLC's interface or its internal web server used for this web-auth).

- If you installed a third-party certificate from a known CA on the WLC to avoid the warning message on the clients when getting redirected to the HTTPS Web-Auth page (due to WLC using a Self-Signed Certificate by default for this secure HTTPS session), then you need to make sure that this certificate was properly generated and installed. For this case, I will recommend the following document:

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

- If this third-party certificate was properly generated and installed, then this won't really work until you do the following:

1) Configure the WLC's virtual interface with a FQDN (which is supposed to be the name you used for the certificate when it was generated).

2) Configure the client's DNS Server with a valid name entry that can resolve the WLC's virtual interface FQDN (which you just configured) to its virtual interface IP address. Yes, this means that you should be able to manage or at least be able to add entries to the client's DNS Server if you want to install a third-party certificate on the WLC to avoid this HTTPS warning (or you could disable HTTPS for the Web-Auth login page if this is not a worry, leaving only HTTP, but then the Web-Auth credentials exchange will be unsecure).

Regards,

Jeal

jeajimen Tue, 10/15/2013 - 12:26

Hi Tony,

I apologize, I think I have shared a few URLs taken while I am logged in on Cisco.com, so those URLs might need a cisco.com profile to be accessed...

Almost all our documents are also publicly available, so this is the public URL for this document I referenced about "Troubleshooting Web Authentication on a Wireless LAN Controller (WLC)":

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080a38c11.shtml

Let me know if you can access this.

Regards,

Jeal

yamazaki9 Mon, 10/14/2013 - 07:59

Hi Jeal Jimenez

                                           We implement new AP 5 Sets(AIR-SAP2602I-E-K9)  for medium warehouse , but exiting AP we used 

AIR-AP1242G-E-K9  for 3 Sets

                                        User used handheld symbol " MC3190 " for 50 Sets

                                          when new AP Already install  user can't working with handheld  , it's show on screen handheld " disconnect from program " 

I try shutdown dot11radio 0 of New 5 AP Sets  and try with AIR-AP1242G-E-K9 3 Sets  ,but  It's Fine

                                        Handheld Symbol  " MC3190 " has data rate support maximum 54 Mbps

  Best Regards,

Thamon

jeajimen Mon, 10/14/2013 - 13:34

Hello Thamon,

The configurations look fine (I just noticed the subnet mask of the BVI1 interface on the 2602 AP is different than on the 1240, but this shouldn't cause this problem where the handhelds are not connecting at all; however, I still recommend you to check this).

Now, this is an issue where you can definitely be affected by interoperability with these handhelds (mainly if they are old radios, and the 2600 AP's radios are new radios with 802.11n features supported, while the 1240s are not, just 802.11b/g). Therefore, I will recommend configuring the radio settings similar to the 1240, and I noticed that the data-rates configuration is not matching (you are using the default data-rates setup on the 1240, while you are not allowing the lower data-rates on the 2600). This could definitely be a problem depending on the handhelds behavior, so you could configure the data-rates the same way on the 2600 for testing:

basic-1.0 basic-2.0 basic-5.5 basic-11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0

If the problem continues, then some wireless packet captures might be the best way to go as there could be a software issue negotiating the association, since this is a very simple setup that should work just fine (check also if you see this problem with other type of wireless clients, and if this is the case, then I will recommend reconfiguring the PSK manually on the AP).

Regards,

Jeal

Vijayakumar.2013 Mon, 10/14/2013 - 09:54

Hi Jeal ,

We want to use MDM in our test lab for mobile devices posture and security purposes. IS there any free or trial period MDM is available that we can integrate with cisco ISE ?

Thanks!,

Regards,

jeajimen Mon, 10/14/2013 - 10:54

Hi Vijay,

MDM integration capabilities are supported on the ISE with the Advanced license, and the free trial evaluation license on the ISE (when you first install it) includes Base and Advanced licenses for a 90-day trial period.

If you need to extend this ISE evaluation license for any reason, then you could contact your Cisco sales/account team, and they should be able to help you generating the specific license that you need to do your tests (a specific license or simply extende the trial evaluation license for another 90-day period, so you can use the Advanced license features).

Regards,

Jeal

Vijayakumar.2013 Mon, 10/14/2013 - 18:28

Hi jeal,

Thanks a lo for ur reply. Is ther any free version of MDM i can integrate with ISE?

Regards,

Vijay

Actions

Login or Register to take actions

This Discussion

Posted October 3, 2013 at 11:15 AM
Stats:
Replies:64 Avg. Rating:4.99074
Views:6702 Votes:0
Shares:4

Related Content

Discussions Leaderboard