A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Friday, December 11, 2009

WLC Layer 2 and Layer 3 Security Policies

In the Wireless Guest WLAN scenario, you need to create a WLAN on the foreign controller, and the same WLAN on the Anchor controller. You then add each controller to the other controller's mobility list (good practices dictate that controllers should be in DIFFERENT mobility groups. So they know each other, but they do not belong to the same mobility group). Last step, you define the Anchor as the Mobility Anchor for this WLAN on both the Foreign and the Anchor controller (don't forget to define the Anchor as the Mobility Anchor on the Anchor itself! This controller needs to know that it is one end of a EoIP tunnel).

That's the easy part, you can find tutorials on this config almost everywhere, for example at:

Now, two questions:
1. Can you combine Layer 3 security (Web Authentication) with Layer 2 security?
2. What exactly needs to be the same and what can be different on the WLAN configuration on both controllers?

1. Yes! And you'd better do it if you want to secure the wireless part. With standard Layer 3 policy only, the only moment that is protected is when you access the Web authentication page and enter your credentials: at that time, you use HTTPS, so you are safe. As soon as authentication is complete, you use the pure Open WLAN, no encryption no encryption. Anybody sitting next to you can eavesdrop what you send and receive with no restriction... haven't you try already when waiting for your flight in an Airport lounge? Well, don't, it is completely in clear and fun to watch, but watching is completely forbidden in most countries...
So you can protect the traffic between the wireless client and the AP by adding to the Layer 3 policy a Layer 2 policy... but not in any conditions. For example, if you try to add WPA/802.1X and click Apply, you get this:

Well, we expected that! If you think about it, 802.1X is a user authentication that occurs at Layer 2... if this worked, you would have to start an 802.11 authentication/association process, get authenticated at Layer 2 with a strong mechanism (PEAP, FAST or even EAP-TLS!), then have to re-authenticate at Layer 3... not very handy and not very logical (why do you need this Layer 3 authentication if we already know who you are?)... and single sign on is out of reach for now...
So you can add a Layer 2 protection mechanism, but it has to be ENCRYPTION, not AUTHENTICATION. In other words, you can use WEP, WPA or WPA2, provided that you rely on PSK, not 802.1X. And then it works. This is how it looks:

Details of Layer 2 page:

And Layer 3 page:

Not very practical for public networks, as you would have to distribute the PSK to your Wireless LAN guest users, but fun as a configuration challenge.

2. Everything on the WLAN has to be strictly identical on the Foreign controller and on the Anchor controller, except:
- the Interface: you can send your users to a DMZ dynamic interface on the Anchor controller to the Management Interface on the Foreign controller (it is actually going to be the Management interface whatever your configured interface is on the Foreign controller, as Controller to controller communication always use the Management interface), so this can be different, and the Foreign controller does NOT need to (and should not) be configured with the DMZ dynamic interface you create on the Anchor.
- RADIUS server: in the WLAN Security > AAA Servers tab, you Anchor controller can define specific RADIUS server(s) to use, which your Foreign controller does not care about. Authentication is done on the Anchor, not on the Foreign, so you can call RADIUS servers on the Anchor and not on the Foreign, no problem. This can also be one difference.
- Profile Name: when you configure the WLAN, you setup a Profile Name and an SSID. The Profile name is a local identifier and not exchanged between controllers, so it can be different on the Foreign and the Anchor.
- Encryption key! Yep, that one is funny. One of my friends (thanks Amir!) discovered that 2 weeks ago. If you add Layer 2 policy with WEP, WPA or WPA2, you need to define a PSK... the PSK can be different on the Foreign and the Anchor! Now... which one will be used by the client? The one on the Foreign! Yes, this is the exception, everything comes from the Anchor controller, except this key. When you think about it, this makes logical sense. Your Layer 2 connection is to an access point connecting to the Foreign Controller, and you need to get to the Foreign controller before being sent through EoIP to the Anchor. So the Layer 2 protection is between you and the AP (connecting to the Foreign). It is therefore very logical to think that the key you need on the client is the key that the Foreign controller sends to the foreign AP!
Notice that you MUST define a key on the Anchor if you define a key on the Foreign: in the mobility exchange, they do tell each other that there is a Layer 2 key, and of which type (WEP, WPA or WPA2). It is just that they do not actually send that key, so it can be different on both controllers...
Wireless is so much fun!


  1. Layer 2 Sec in addition to a Web portal is an interesting one. I had a customer that was doing this and we found that it broke the crippled browser function of iOS devices. Apple assumes that if there is a layer 2 security mechanism in place, there is no need to test for layer 3 security; therefore the crippled browser never automatically popped up. Users were forced to open the browsers manually (if they remembered to do so). Definitely not a good way of making things easy on the end users in the real world.

    1. Captive bypass should be disbaled in WLC for CNA pop up for IOS devices

      WLC# config network web-auth captive-bypass disable

  2. That’s really a nice one, I have seen many blogs but they are outdated so I’m pleased to see this blog now.
    Zero Up 2.0

  3. I am happy i read this document.