Using Wireless VLANs to Provide
Tiered Levels of Security & Accessibility

Author:  Colin Weaver
Company:  ITdojo, Inc.
Last Revision:  8/25/2006

Disclaimer: This document is for fun and education. You are responsible for anything you choose to implement as a result of what you read. If you don’t want to be accountable for what you might do with the knowledge you stand to receive, stop reading now. I don’t cover every possible facet, nuance, nook and cranny of securing your wireless system. Due diligence is your responsibility. Besides, I’m probably lying. None of this really works. It’s all made up.

The Problem

My company has a transient client base.  Customers come in and spend all day for a week and then they’re gone.  On a regular basis I am asked things like, “Hey, do you have a wireless LAN I can connect to so I can check my email?”, or,  “I need to VPN back in to my office.  Do you have a wireless LAN I can use?”.  My usual answer:  “No...” 

It's not that I don't have a wireless LAN.  I do. 
It's not that I'm not willing to let them connect.  I am.
 
What it really boils down to is that I'm not just a security freak; I’m actually a security super-freak.  My wireless LAN is too secure to make it easy for passers-by to make use of.  As of today, my WLAN is using Protected EAP (PEAP) as its authentication mechanism.  Encryption is set to use AES-CCMP.  Users and computers are authenticated using RADIUS (which then passes the authentication request to Active Directory).  In order for a client to connect to my wireless LAN we would have to 1) create a user account and a computer account  in Active Directory (e.g., they would have to join the domain), 2) add my Root Certificate Authority’s certificate to their certificate trust list and 3) make sure their device was capable of doing AES encryption.  When confronted with a choice between all that work for someone who needs connectivity for a short time and just saying, "no" ... can you really blame me?

It's not just the complexity of my WLAN that makes me say “no”.  Users who can successfully connect to my WLAN also have [potential] access to resources that are private.  Sure, I use other security mechanisms to protect those resources (defense-in-depth) but the need to be a good ‘doobie’ about security precludes me from simply letting them on to a LAN segment that provides the opportunity.  So the complex nature of my WLAN configuration and my unwillingness to allow un-trusted users onto a sensitive subnet forces me to tell my customers that a WLAN connection isn't available.  Suck factor = high.

What I would like to do is say, yes.  It would be quite cool of me to let my clients connect to a WLAN while in my office.  I see at least two ways to make that happen.  The purpose of this SYNner article is to identify the possibilities and explore, in detail, how to make one of them, wireless VLANs, a reality.

Before we start listing solutions lets summarize the state of device support for WLAN authentication and encryption.

1)  Handheld devices (Pocket PC's, Sony PSP, etc.) - Many, if not most, continue to lag behind the times when it comes to nifty authentication and encryption support.  While there are some out there than can do LEAP, and possibly even a few that can do PEAP and EAP-TLS, most cannot.  In fact, there is still a widely deployed base of devices that only supports static WEP keys.  Until the processing power and code of these handhelds catches up with new security standards (802.11i), I'm left with two choices:  provide no access for handhelds or allow weak encryption with limited or no authentication.  Both choices suck and are considered ‘loser.com’ by today’s standards.  The good news is that these devices are starting to catch up.

2) There are still a large number of notebooks out there that don't support WPA or WPA2 (802.11i).  Because of this, these devices are very limited in their support for authentication and encryption.  Some have limited WPA support and can do TKIP while others support, at best, LEAP (which is not part of WPA).  The worst scenario for these devices is that they only support static WEP keys.  The problems with WEP security is the stuff of campfire legend.  Again, I find myself confronted with the 'access vs. security' conundrum.

3)  Newer devices, notebooks in particular, support 802.11i.  They can do it all; PEAP, EAP-TLS, EAP-FAST (not part of 802.11i), WPA-PSK, etc.  They are not limiting factors when choosing a security mechanism.  It would be nice if all the devices that want to connect to my WLAN fit into this block.  If every device that wanted to connect to my WLAN was a company asset I could accomplish this via company policy.  But I've got customers, in and out, some with nifty new gear and others with stuff that’s ‘old and busted’.  I need to accommodate them all.

The Solution

I see two:

• Multiple Access Points
• Wireless VLANs

In reality, I see three solutions.  Solution #3 = Solution #1 + Solution #2 (Multiple access points with wireless VLANs on each AP)

Solution #1:  Multiple access points – A plausible but less elegant solution

In order to meet the demands of every possible device I can set up, say, three access points.  AP #1 (visitorAP1) is configured to use static WEP keys.  AP#2 (visitorAP2) is configured to use either TKIP or WPA-PSK.  AP#3 (corporateAP) is configured to use PEAP or EAP-TLS with AES encryption.

Assuming the use of the 2.4 GHz range and to avoid channel overlap I can put AP #3 on channel 1, AP#2 on channel 6 and AP#1 on channel 11.  Note:  While the 5GHz UNII range provides more non-overlapping channels (and therefore the capacity for more APs located in the same RF space) it is less likely that all devices will have 802.11a compliant radios installed.  802.11g (and 802.11b to an increasingly lesser extent) seem to be the most prevalent.

To keep the naming scheme simple I will set the SSIDs as follows:

• AP#1 (visitor AP #1) – visitorAP1
• AP#2 (visitor AP #2) – visitorAP2
• AP#3 (corporate AP) – itdojo

For security I will set the following:

• WEP Key for visitorAP1 SSID (64-bit WEP):  8005551212
• WPA-PSK Key for visitorAP2 SSID:  0123456789abcdef (ascii)

To get the best possible security for my corporate resources I will place the corporate AP on a protected subnet and I will put the visitor AP’s outside the firewall (or on a different protected subnet).

On AP#1 and AP#2 I will configure inbound access-lists on the radio interface.  I will limit the ports/protocols available for use to those commonly used (HTTP, HTTPS, DNS, SMTP, POP3, etc.)  This will exercise at least some control over what the average user can do when making use of my network resources.  If you happen to be using an AP that doesn’t support access-control lists (filters), do the next best thing; configure the rules on the closest upstream router/firewall.

Note:  The access-list functionality of Cisco AP’s is (as of today) not stateful.  They are simple packet filters.  If you want stateful packet filtering, move upstream.

To give out IP addresses to the visiting WLAN clients I will configure either the APs or an upstream router to be a DHCP server.  Because each AP is connecting to the same layer-2 switch, the clients of each AP (AP#1 and AP#2) will be on the same IP subnet.  If the APs are taking the DHCP job I also need to remember to split the DHCP scope to avoid any IP conflicts.

Figure 1 shows what this configuration might look like.

Figure 1 – Multiple AP Solution

Does this solution work?  Yep.  Is there a problem?  Yep.   

The problem:  I just tripled (at least) the cost of my WLAN deployment.

Reality check:  Do you really have enough visiting users to justify something like this?  If you have people stop by every now and then, is it really worth it?

Solution #2:  Wireless VLANs on a Single Access Point – A more elegant solution for a more civilized age

I can meet the demand of my visiting customers and stay in compliance with corporate security policy (perhaps) using a single access point.  VLANs have long been used in wired systems to segregate data flows, implement security and maximize performance.  We can take the same concept and extend it into the RF, providing a different VLAN for each type of WLAN user; one VLAN for corporate devices, one for WEP-only visiting devices and one for WPA-capable visiting devices. 

The steps we need to take to achieve the end result are:

• Configure inter-VLAN routing on the router
• Configure VLANs on the switch
• Create VLANs on the AP
• Associate SSIDs with VLANs
• Configure different authentication and encryption settings for each SSID
• Configure filters on the AP to control what types of ports and protocols are available to each VLAN.
  

The end result will look like the figure below.

Figure 2 – Wireless VLAN solution

The remainder of this article will detail the configuration of the following devices:

• The Access Point
• The switch connected to the Access Point
• The router/firewall
• The RADIUS server (running Windows Server 2003 & the Internet Authentication Service)

The equipment I will use in this scenario includes:

• Cisco Aironet 1200 series Access Point (802.11g)
• Cisco IOS router with at least one (1) FastEthernet interface
• Cisco Catalyst 2950 switch (layer 2 switch)
• Microsoft Windows Server 2003 w/ SP1
  

Configuring Microsoft Active Directory Users and Groups

Using the Active Directory Users & Computers MMC snap-in, do the following:

• Create a group (Universal group or Global group).  Name it something like, ‘Universal – WLAN Users’
• Create user account for each user you want to be able to access your WLAN.  Add each user to the Universal – WLAN Users group.

Figures 3 & 4 illustrate the steps you need to take.

Figure 3 – Create the necessary users and group(s)

Figure 4 – Add each WLAN user to the WLAN Users group

• Under the properties of each user, grant the Allow Access permission under the Remote Access Permission (Dial-in or VPN) tab.

Figure 5 – Granting users “dial-in” permission.

Configuring Microsoft Internet Authentication Server (RADIUS) to support Protected EAP (PEAP)

Creating a New RADIUS Client

Open the Internet Authentication Service MMC (this is what Microsoft calls RADIUS).
Create a new RADIUS Client.  The steps to create the client are detailed below.  The RADIUS client is the Access Point.  It is NOT the wireless client itself (e.g. it is not the notebook or the PDA).

Figure 6 – Creating a new RADIUS client

At the Name and Address dialog, enter a Friendly Name (anything you wish to make this device recognizable from the others).  Enter in the AP’s IP Address.  Click Next.

Figure 7 – Configuring a new RADIUS client

From the Additional Information dialog choose Cisco from the Client-Vendor drop-down.
Enter a shared secret value.  This value has to match the one you configure on the AP.  Click Finish.

Figure 8 – Configuring a new RADIUS client

Verify the existence of the new RADIUS Client you just created.

Figure 9 – Verifying the creation of the RADIUS client

Creating a New Remote Access Policy

From the Remote Access Policies option in the tree-view pane, select New Remote Access Policy.  The New Remote Access Policy Wizard will begin.

Figure 10 – Creating a new remote access policy

At the Welcome screen, click Next.

Figure 11 – The New Remote Access Policy Wizard welcome screen

At the Policy Configuration Method dialog, choose the Use the wizard to set up a typical policy for a common scenario radio button.
Enter a name for the policy in the Policy Name field.
Click Next.

Figure 12 – Configuring a new remote access policy

At the Access Method dialog, select the Wireless radio button.  Click Next.

Figure 13 – Configuring a new remote access policy

At the User or Group Access dialog, click the Group radio button. Use the Add… button to add the WLAN Users group you created.  Click Next.

Figure 14 – Configuring a new remote access policy

At the Authentication Methods dialog, choose Protected EAP (PEAP) from the drop-down.  Click Configure…

Figure 15 – Configuring a new remote access policy

At the Protected EAP Properties dialog, choose an appropriate certificate from the drop-down menu.  The certificates intended use must support Server Authentication.  You can use the Certificates MMC to view the intended use of each installed certificate if you aren’t sure which one to pick (assuming this is more than one).  The certificate you select here is what will be used by the client to verify the identity of the RADIUS server.

It is critical that the Issuer’s certificate is listed in the Trusted Root Certification Authorities list on all WLAN clients that will be using PEAP.

Check the Enable Fast Reconnect check box. (Optional)
Verify that Secured Password (EAP-MSCHAP v2) is selected. 
Click OK.

Figure 16 – Configuring a new remote access policy

Click Next.
At the Summary screen, click Finish.

Figure 17 – Configuring a new remote access policy

Verify that your newly created policy is listed above any built-in policies.  Microsoft IAS policy processing is top-down.  The higher your newly created policy is to the top of the list, the more likely it is to be the policy in use.

Figure 18 – Verifying the new Remote Access policy

Configuring the Cisco IOS router/firewall to support multiple VLANs

For this configuration I am using a Cisco router.  The only requirement of note is that your router must have at least one (1) FastEthernet interface.  Inter-VLAN routing and trunking are not supported on interfaces slower than 100 Mbps.

For this setup I chose to configure the Cisco router as the DHCP server.  I also chose to exclude addresses .1 - .99 from client assignment.  This leaves me with a static pool I can use later (if I can think up a reason for doing so).  The router DHCP configuration is as follows:

Figure 19 – DHCP configuration for Cisco IOS

Notice that the CorporatePool is configured to use an internal DNS server while the two VisitorPools are configured to use an external DNS server.  This provides a small amount of additional security by reducing the likelihood that a visiting user will be able to resolve the hostname of an internal resource.

Next, I need to create four (4) sub-interfaces on the main FastEthernet interface.  For my router, the interface is Fa3/1; yours will likely be different.

To keep things easily interpretable I created sub-interface numbers that correspond to the VLAN ID’s I chose to use.  My sub-interfaces are:

• Fa3/1.1 – for VLAN 1
• Fa3/1.44 – for VLAN 44
• Fa3/1.66 – for VLAN 66
• Fa3/1.88 – for VLAN 88

The configuration is shown in Figure 20 below.

Figure 20 – Configuring subinterfaces and trunking on a Cisco IOS router

Assuming we don’t need any ACLs on the router, that’s all we need to do.  Next, we configure the Layer-2 switch.

Configuring the Cisco Catalyst Switch (Layer 2)

Configuring the switch should be a simple affair.  There are three (3) things you must do:

• Create the VLANs on the switch
• Configure the link between the switch and the AP to be a trunk
• Configure the link between the switch and the router to be a trunk

Note:  It is perfectly plausible to remove the switch from the equation; just plug the AP directly into the router using a crossover cable.

Figure 20a – Required trunk links

In my configuration port Fa0/7 is connected to the switch and Fa0/8 is connected to the router.

Figure 21 shows the VLAN configuration.

Figure 21 – Output of show vlan brief on Catalyst 2950 switch

Figure 22 shows the ports configured to trunk.

Figure 22 – Output of show running-config on Catalyst 2950 switch

The switch is now configured.  Next up:  the access point.

Configuring the Cisco Aironet Access Point

Configuring the access point is the most in-depth process.  The configuration requires the following:

• Configure AAA (RADIUS client functionality)
• Create VLANs & SSIDs (Cisco 1200 series APs support up to 16 SSIDs) (ergo 16 VLANs).
• Configure authentication & encryption for each VLAN/SSID combination
• Configure filters (access control lists) for each VLAN

The easiest way to configure the AP is to use the HTTP web interface.  Using the web interface is a lot like using a calculator to divide 9 into 1237; you get the answer quickly but you don’t necessarily understand how the answer was achieved.  Do it long enough and you’ll be helpless without a calculator.  I feel the same way about graphical interfaces.  In the long run, they rot your mojo.  For that reason I will be showing you how to configure the AP from the CLI.

Configuring AAA (RADIUS client functionality) on the Aironet Access Point (AP)

From the CLI on the AP:

Enter global configuration mode and enter the following commands:

Assign an IP Address to bridge-virtual interface 1 (BVI1) and specify the interface as the source for RADIUS traffic

Create VLANs & SSIDs

The VLANs and SSIDs I create in this example are arbitrary.  I like having sub-interfaces and VLAN numbers match.  It makes troubleshooting a lot easier.  It is not, however, a requirement.

SSIDs to create: 

• itdojo
• dojo-visitor1
• dojo-visitor2

Note:  These are lame SSID names.  Make yours something cool and, more importantly, something that is not overly descriptive of what/who the SSIDs are for.  Security through obscurity?  Sure it is, but every little bit helps, right???  Right??? 

Subinterfaces to create:

• 0.44
• 0.66
• 0.88

VLANs to create:

• 44
• 66
• 88

From the CLI on the AP:

 Associating the SSIDs with the Radio Interface

To associate the SSIDs with a radio interface, enter the following commands:

In order for VLANs to work on the AP you have to configure a corresponding sub-interface on the wired (distribution system) side.  You also have to enable bridging of the VLAN traffic from the radio interface to the FastEthernet interface.  It is usually enabled by default.  If you aren’t sure what bridging is all about I recommend you read this Cisco document (you can also find it at this alternate location).  It will explain the concept of bridging across a layer 3 boundary.

Note:  The following commands are automatically added to the dot11 Radio sub-interface when you assign it to a bridge-group:

• no bridge-group <bridge_group_number> source-learning
• bridge-group <bridge_group_number> spanning-disabled

Note:  The following commands are automatically added to the dot11 Radio sub-interface when you assign it to a bridge-group:

• bridge-group <bridge_group_number> subscriber-loop-control
• bridge-group <bridge_group_number> block-unknown-source
• no bridge-group <bridge_group_number> source-learning
• no bridge-group <bridge_group_number> unicast-flooding
• bridge-group <bridge_group_number> spanning-disabled

Configure authentication & encryption for each VLAN/SSID combination

Next I need to configure the authentication mechanisms and key management options for each SSID.  I also need to configure the encryption that will be used for each VLAN.

To configure encryption fore each VLAN, enter the following commands:

To configure the authentication for each SSID, enter the following commands:

Now, if you open your web interface you should see something like Figure 23-A.  The web interfaces nicely summarizes the configuration you just did from the CLI.

Figure 23-A (Click here or on the image for a larger view)

 Configure filters (access control lists) (Optional)

One of the last configuration tasks is to limit what ports & protocols are available to users of each VLAN.  If your intention is to allow users on the visitor VLANs only the most basic of connectivity then you need to implement access-controls either on the AP or on the upstream router.  As long as processor utilization stays within acceptable limits you will be well-served to implement them as close to the user as possible.  For the purposes of this lab I will assume that I want visiting users to be able to use the following ports/protocols:

• DNS queries (UDP Port 53)
• HTTP
• HTTPS
• POP3
• SMTP
• Remote Desktop (TCP Port 3389)
• NAT-T (UDP Port 4500)
• Cisco UDP VPN (UDP Port 10,000)
• Cisco TCP VPN (TCP Port 10,000)
• IKE (UDP Port 500)

Note:  Configuring filters from the CLI on Cisco APs works just fine but you can’t see the filters in the web interface.  It’s more than just a little funky.  I tested them pretty extensively to make sure they were working even though there is no hint of them in the web interface.  If you create ACLs using the web interface, the actual commands written to the config are identical to what you see in the CLI.  I don’t know why it’s funky, it just is.  Cisco talks about the issue on this page: 
(http://www.cisco.com/en/US/products/hw/wireless/ps430/products_configuration_guide_chapter09186a0080606ce5.html). 
In short, they say you should do it from the web interface.  I suggest lameness is afoot.  When you configure from the CLI and then go to the filters page you will get a warning similar to this.

Figure 25 is a shot of the ACLs I made using the CLI.  Figure 26 is a screen shot of the web interface, showing no filters (ACLs).  Group them inbound on the radio interface(s) using the CLI and they work just fine.

Figure 25


Figure 26

If you’ve got part of your admin team using the web interface you will save yourself some headaches by standardizing on the web interface for configuration.  Anyone visiting the web interface and not the GUI won’t see your ACLs.

In this config, users on the corporate VLAN will not have access controls put in place on the AP.  We could put controls in place here, though.  It’s up to you if you do this in your own shop.

The CLI syntax to create a “filter” on an AP is the same as any other Cisco IOS device.  To allow the protocols listed above, enter the following commands starting from privileged exec:

Link the ACLs to the corresponding interfaces.

You can hook up on an ACL for your internal users if you’re feeling it.  Just lather, rinse, & repeat.

Testing the configuration

 Let’s test it out.  To keep it simple I will use Windows to configure the WLAN connections.  Use whatever 3rd party tool that makes you happy.

The screen shots below show the setup of the respective VLANs.  If you’ve read this much of this article and don’t know how to do this… I have nothing further for you.

For the dojo-visitor1 VLAN:

Figure 27 shows the static WEP configuration for visitor VLAN/SSID #1
Figure 28 shows the client connected to the network.
Figure 29 verifies that the IP address was obtained by the DHCP server

Figure 27


Figure 28


Figure 29

For the dojo-visitor2 VLAN:

Figure 30 shows the static WPA-PSK/AES configuration for visitor VLAN/SSID #2
Figure 31 shows the client connected to the network.
Figure 32 verifies that the IP address was obtained by the DHCP server

Figure 30


Figure 31


Figure 32


For the itdojo VLAN:

Figure 33 shows the static WPA/AES configuration for visitor VLAN/SSID #2
Figure 34 shows the authentication set to Protected EAP (PEAP)
Figure 35 show certificate selection for the PEAP client.
Figure 36 shows the client connected to the network.
Figure 37 verifies that the IP address was obtained by the DHCP server

Figure 33 


Figure 34


Figure 35


Figure 36


Figure 37

  

Summary

Being able to segregate users based on how well they can authenticate is very cool functionality.  We can take all of this in other directions, too.  You can, for instance, implement the exact same concept and use it to separate the different types of users in your network.  For years we have VLAN’d our users by department in the wired LAN; why not in the wireless LAN?

On a parting note you should consider that the issue of throughput has not been addressed.  The 3 separate AP solutions allowed for co-location with a minimum of channel interference.  The single AP/VLAN solution only makes use of one (1) radio.  All of the users are now on the same channel.  No matter how pretty your configuration is you can’t escape the fact that you’re sharing a half-duplex medium with multiple VLANs.  Hmmmm….

Colin Weaver
ITdojo, Inc.