Ask the Expert: Wireless LAN Security

[ciscomoderator]

With Jeal Jimenez

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.

[Jeal Jimenez]

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]

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

[Jeal Jimenez]

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

[Santosh Kolte]

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

[Jeal Jimenez]

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]

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?

[Jeal Jimenez]

Hi, Sure!

You can find documentation about this on the WLC Configuration Guides:

http://www.cisco.com/en/US/docs/wireless/controller/7.5/config_guide/b_cg75_chapter_010000111.html

And also on the Enterprise Mobility Design Guide:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob73dg/ch7_HREA.html

Regards,

Jeal

[Santosh Kolte]

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

[Jeal Jimenez]

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

[Santosh Kolte]

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 .

[Jeal Jimenez]

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:

[Sumit Chakravarty]

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

[Jeal Jimenez]

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

[tonyp8581]

Hi Jeal,

Concerning the Web-Auth process flow, I can't seem to access the URL you posted.  I keep getting Forbidden File or Application.  Is this a restricted area ?

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

Thanks !

Tony

[Jeal Jimenez]

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