Cisco H-REAP Local Authentication Improvements

A while back I wrote about Cisco H-REAP, how it works, and some considerations and feature limitations.

As a follow-up, I'd like to briefly cover some recent changes in how H-REAP access points perform client authentication, specifically with the H-REAP Local Authentication features since this topic is confusing for most engineers (in-part because of the name).

H-REAP Local Authentication in code version 7.0.116.0 encompasses three distinct options for authentication of clients when "connected" to a WLC or "standalone".

Backup RADIUS Servers (AP as NAS)
This is the long-standing H-REAP feature that allows the AP to source RADIUS authentication to external 'backup' RADIUS servers when in standalone mode and the WLC in unreachable. In this scenario, the AP is the authenticator which forwards requests to the authentication server (RADIUS server). The authentication server must have the APs defined as a NAS.

This permits the APs to accept new clients and successfully complete authentication without reliance on the WLC. This is really a high availability feature for the WLAN to prevent an outage if one or multiple controllers fail.

Define the H-REAP backup RADIUS servers from the H-REAP Group:

H-REAP Backup RADIUS Servers

Update - Based on feedback in the comments, it should be pointed out that the AP and RADIUS server must use the same shared secret as configured on the wireless LAN controller. The AP inherits the RADIUS server definition and configuration from the controller, and it cannot be configured separately. This applies to both AP as a NAS situations.

Local Authentication (AP as RADIUS)
This feature allows the H-REAP access point to assume the role of both the authenticator and the authentication server (RADIUS server). The AP is required to have local users defined and only support a few EAP types, notably EAP-FAST and LEAP.

This feature is what most engineers describe this feature as meaning, without knowledge of the 3rd option below. Having locally defined users and restricted EAP types makes this option not all that attractive for most organizations, but there are some who have obviously requested it from Cisco. It beats static pre-shared keys for security, but creates administrative burden on network administrators to define and manage local users on the H-REAP APs.

Many organizations already have user accounts stored in corporate directory systems such as Active Directory, and definition of users in an alternate database is not preferred or allowed. That said, this feature doesn't make a lot of sense for user accounts tied to real people since corporate security policies usually dictate that passwords are rotated regularly and support personnel don't have access to those passwords, preventing them from being replicated on H-REAP APs. However, it may make sense for non-user IDs attached to embedded devices such as IP phones, Vocera badges, or handheld scanners.

Enable H-REAP Local Authentication (AP as RADIUS) in the H-REAP Group:

Enable H-REAP Local Authentication by the AP

Additionally, define local users and configure EAP-FAST and LEAP:

H-REAP Local Auth User Definition

Local Authentication (AP as NAS)
Historically, when the H-REAP AP was connected to a WLC, all authentication flowed through the controller. In code version 7.0.116.0 this changed. Now administrators can configure H-REAP APs to source client authentication and bypass the WLC, even in connected mode. This is beneficial when the AP is logically closer to the RADIUS server than the WLC and should source authentication itself to improve performance. A remote site that contains both H-REAP APs and a RADIUS server, with a centralized controller across the WAN is one example.

Enable H-REAP Local Authentication (AP as NAS) in each WLAN:

Enable H-REAP Local Authentication in the WLAN

When this option is enabled, the AP sends client authentication requests to servers in this order:

1. WLAN AAA Servers
2. H-REAP Group Backup RADIUS Servers (primary/secondary)
3. AP Local Authentication (local users on the AP)

One other quick note is that the H-REAP APs also support RADIUS fallback. So if a primary RADIUS server fails and subsequently comes back online, the AP will recognize this and begin sending client authentications back to the preferred server.

Hopefully this clarifies some of these new features that aid both high availability and performance.

Cheers,
Andrew

Aerohive Credential Caching Improves Branch Office Availability

The Necessity for Highly Available WLANs
Wireless LANs are mission-critical, and have been for a while. More so than ever, the availability of the wireless network is important to operate business, educate students, and interact with consumers. Organizations across many industries have realized the benefits of that mobility, users increasingly expect ubiquitous network access, and machine-to-machine (M2M) communications are poised to grow the demand exponentially. In such an atmosphere, the wireless network must be high performing, resilient, adaptable, and highly available.

Many organizations provide highly available WLANs by using pre-shared key (PSK) security since there is no reliance on external systems for network access. EAP authentication provides higher security than PSK deployments, but suffers from higher complexity and reliance on AAA services external to the WLAN for network access. Modern wireless networks typically rely on RADIUS as this service. However, deploying local authentication services at each remote site can be cost prohibitive due to software licensing and server resources. This, coupled with higher latency involved with EAP authentication across a WAN circuit, typically leads many organizations to adopt central AAA services for non-mission critical applications, and forgo stronger EAP security and implement PSK for mission-critical applications such as VoWiFi or transaction processing. This results in a trade-off of security for availability, which is sub-optimal and introduces a much higher amount of risk to the organization.

Can't we have both high security using EAP with dynamic per-user authentication and keying coupled with the high availability of PSK networks? We can, using Aerohive credential caching!

Credential Caching Overview
Aerohive authentication cache provides remote branch offices the ability to cache successful client authentications from central directory services for use when the central site or services are unavailable, such as a WAN outage. This provides high availability of the WLAN for remote sites, enabling continuity of service for locally deployed applications, collaboration among users, and local Internet access (if deployed locally at branches and not tunneled back to the corporate head-end).

It does this by providing local RADIUS service within select HiveAPs and integrating with corporate directory services, including Active Directory, Open Directory, and native LDAP systems. In this scenario, the HiveAP provides EAP authentication for clients and functions as both the authenticator and authentication server simultaneously. EAP types supported include PEAP, EAP-TLS, EAP-TTLS, and LEAP. On the back-end the HiveAP is configured with directory access credentials to authenticate users and cache their login information locally from the directory server for offline use (similar to a Windows computer object joined to the domain). This may include Kerberos v5 if using Active Directory as the back-end directory service.

Aerohive Credential Caching Logical Diagram with Central Directory Services

Note - I know some of you will be wondering why I'm not discussing Private PSK (PPSK) or Dynamic PSK (DPSK) offered by Aerohive and Ruckus. While these are novel approaches for small scale solutions involving user interactive device platforms, these solutions cannot address many deployment scenarios involving embedded devices or non-user devices, as is typical with voice handsets and vendor transaction processing systems. A more robust and scalable solutions is required for such scenarios.

Deployment Requirements
To deploy credential caching, administrators must configure a the following settings on HiveAPs at the branch sites:

1. Determine the remote HiveAPs that will provide local AAA server (RADIUS) services
2. Assign static IP addresses to the HiveAPs providing AAA services
3. Create certificate(s) for HiveAP AAA servers to use during EAP authentication
4. Integrate the HiveAP AAA servers with user directory services
5. Create the HiveAP AAA server (RADIUS) configuration
6. Create AAA client settings for all other NAS client APs, which point to the HiveAP AAA server(s) for RADIUS authentication
7. Deploy configurations to all HiveAPs

First, determine which HiveAPs at each remote site will be AAA servers providing RADIUS and EAP termination. One or multiple HiveAPs may provide AAA services for other HiveAPs. Multiple APs are recommended to provide fault tolerance at each branch location.

Second, the selected HiveAPs must be configured with static IP addresses since they will be providing services that other NAS client APs will rely on for user authentication. Assign static IP addresses from within individual AP configuration settings in the "Interface and Network Settings" section (be sure to also configure DNS servers in the WLAN profile when using static IP addresses to ensure name resolution for HiveManager discovery).

Next, create one or multiple RADIUS server-side certificates for use by the HiveAP AAA servers. The server-side certificates are required during TLS tunnel setup between the RADIUS server and client during EAP authentication. This can be accomplished by creating a Certificate Signing Request (CSR) either from HiveManager or using an external utility such as OpenSSL. Using HiveManager is a simple process; navigate to Advanced Configuration > Keys and Certificates > Server CSR. Fill out the form and click "Create". 

Then send off the CSR file to the Certificate Authority for verification and certificate creation. Once the CA has issued the certificate, navigate to Advanced Configuration > Keys and Certificates > Certificate Mgmt to import the certificate into HiveManager. The private key file will automatically be generated with the CSR and listed in this section. No manual merging of the private key and issued certificate are required, but may be performed if desired. Also import the CA certificate to send the complete certificate chain to clients during outer TLS tunnel establishment. It will also be used to verify trust of client certificates if using EAP-TLS authentication. The certificate, private key, and CA certificate files will be pushed to HiveAP AAA servers later during the configuration.

Aerohive Certificate Management, Showing the Private Key,
CA Certificate, and Issued Certificate Files

Integration with AAA user directory services is accomplished in the Advanced Settings > Authentication > AAA User Directory Settings section. In this section, you will define a profile that HiveAP AAA servers will use to query a back-end directory to authenticate users. This may include Active Directory, Open Directory, or native LDAP. In this example we will use Active Directory since this is very common. Create a new profile to get started.

Aerohive HiveManager AAA User Directory Settings

Select the directory type from the option buttons and select or define a new IP address / host name network object for the Directory Server. Multiple directory servers may be configured for redundancy.

For Active Directory integration, specify the default domain in which the HiveAP computer object, AD server, and user objects to be authenticated reside (select the root domain of the forest). If users in multiple domains need to be supported, configure the "Multiple Domain Info" section at the bottom. Configure the BindDN account (user object) that HiveAP AAA server(s) will use when authenticating itself to the directory server to lookup user accounts. This allows the HiveAP RADIUS service to authenticate wireless users. Additionally, in order to perform credential caching, configure the Admin User account which is used by the HiveAP to login to Active Directory and add itself as a computer object in the domain or computer OU specified. This allows the HiveAP to cache user NTLM credentials locally in access point RAM for use when the directory server(s) are not available. The admin user specified must have rights to add computer objects into the domain or OU specified.

Note - Using this method, the admin user account information is stored in HiveManager and in the flash configuration file of HiveAPs. If this is not desirable, HiveAPs may be joined individually to the domain from the CLI which does not get stored in any configuration files. Issue the following command: "exec aaa net-join { primary | backup1 | backup2 | backup3 } username USER password PASSWORD".

Next, create a HiveAP AAA Server profile for the access points providing RADIUS service from the Advanced > Authentication > HiveAP AAA Server Settings section. Here you will define what EAP methods are supported, the certificate files to be used during EAP, database access settings, and NAS clients. For the database access settings, select the configured directory service type and previously configured AAA user directory profile. Enable RADIUS Server Credential Caching and set a cache lifetime which determines how long cached credentials will be used when the directory server(s) are not available. The remaining three interval timers determine how long an individual directory server is marked down before being retried (default 600 sec.), how long to use the local database if all directory servers are down before retrying (default 300 sec.), and how long to keep retrying an unresponsive remote directory server in the list before moving on to the next server in the list (default 30 sec.).

Enable Credential Caching in the HiveAP AAA Server Settings

In the NAS settings section be sure to configure the IP address of every NAS client AP  that needs to use the HiveAP RADIUS server to authenticate clients, or configure a IP network object for broader access by multiple APs in the same subnet range.

Finally, create a AAA Client Settings profile which will be deployed to all of the other NAS client APs instructing them to contact the HiveAP AAA Server(s) for RADIUS authentication services. This is configured from the Advanced > Authentication > AAA Client Settings section.

Once all configuration is complete, assign the HiveAP AAA Server Settings profile to APs designated to be RADIUS servers from within individual AP configuration settings in the "Service Settings" section. Also embed the AAA Client Settings profile within SSID profile(s) as the assigned RADIUS server(s), and deploy configurations to all APs.

Verification
Once the configuration for HiveAP RADIUS servers and HiveAP NAS clients have been deployed to access points, verify directory integration by reviewing access point and directory server logs. Logs in both locations will show successful bind to the LDAP server and computer object creation.

Active Directory Logs Showing Successful Bind, and HiveAP Computer Object Creation

Finally, verify correct credential caching operation by performing client authentication while directory services are available and then re-testing once directory services are unavailable using the local AP cache. Issue the "show auth" command to view currently authenticated clients as well as cache entries created. Below we can see one current user session followed by an entry for the same client in the local cache table.

HiveAP02#show auth
Authentication Entities:
if=interface; UID=User profile group ID; AA=Authenticator Address;
idx=index; PMK=Pairwise Master Key; PTK=Pairwise Transient Key;
GMK=Group Master Key; GTK=Group Transient Key;

if=wifi1.1; idx=11; AA=0019:7729:57a0; SSID=HiveMind; default-UID=0;
PTK-rekey=0; GTK-rekey=0; GMK-rekey=0; strict=no; preauth=no; replay-window=0;
proactive-pmkid-response=disabled;
Reauth-period=n/a; PTK-timeout=4000; PTK-retry=4; GTK-timeout=4000; GTK-retry=4;
Local-cache-timeout=86400
Protocol-suite=WPA2-AES-802.1X;

No. Supplicant UID PMK PTK Life State Reauth-itv Cipher User-Name
--- -------------- --- ----- ----- ----- ------- ---------- --------- --------------------
0 0019:7e9d:871d 0 4f76* ec43* -1 done 0 WPA2/CCMP HiveUser

Local Cache Table:
No. Supplicant UID PMK PMKID Life TLC User-Name
--- -------------- --- ----- ----- ----- ----- --------------------
0 0019:7e9d:871d 0 4f76* 0850* -1 86232 HiveUser

Issue the same command after disconnecting the client and the current session entry will be removed, but the local cache table entry will remain (up to the configured cache lifetime).

HiveAP02#show auth
Authentication Entities:
if=interface; UID=User profile group ID; AA=Authenticator Address;
idx=index; PMK=Pairwise Master Key; PTK=Pairwise Transient Key;
GMK=Group Master Key; GTK=Group Transient Key;

if=wifi1.1; idx=11; AA=0019:7729:57a0; SSID=HiveMind; default-UID=0;
PTK-rekey=0; GTK-rekey=0; GMK-rekey=0; strict=no; preauth=no; replay-window=0;
proactive-pmkid-response=disabled;
Reauth-period=n/a; PTK-timeout=4000; PTK-retry=4; GTK-timeout=4000; GTK-retry=4;
Local-cache-timeout=86400
Protocol-suite=WPA2-AES-802.1X;

Local Cache Table:
No. Supplicant UID PMK PMKID Life TLC User-Name
--- -------------- --- ----- ----- ----- ----- --------------------
0 0019:7e9d:871d 0 f7ad* b08f* -1 86386 HiveUser

Finally, disable the back-end directory services and re-test client authentication using the credential cache on the access point. The following log output is in reverse chronological order, and shows the HiveAP AAA server unable to bind to the directory server at 10.22.33.44, then successfully authenticating the client "HiveUser" via RADIUS using the local credential cache from the NAS client at 10.108.30.18, which is its own IP address.

2011-05-10 10:11:20 notice ah_rt_sta_modify: 0019:7e9d:871d(ip=10.108.30.96)
2011-05-10 10:11:20 notice Station 0019:7e9d:871d is authenticated to 0019:7729:57a0 thru SSID HiveMind
2011-05-10 10:11:18 info [mesh]: set proxy : 0019:7e9d:871d 0019:7729:5780 wifi1.1 flag 0x1c03
2011-05-10 10:11:18 info set proxy route: 0019:7e9d:871d -> 0019:7729:5780 ifp wifi1.1 upid 0 flag 0x1c03 monitor(0/0) pkt/sec ok
2011-05-10 10:11:18 info receive event STA JOIN: 0019:7e9d:871d associate wifi1.1 upid 0 vlan 1 flag 0x00000000
2011-05-10 10:11:18 notice ah_rt_sta_add: 0019:7e9d:871d(ip=10.108.30.96)
2011-05-10 10:11:18 info [Auth]STA(0019:7e9d:871d) login to SSID(wifi1.1) by user_name=HiveUser
2011-05-10 10:11:18 notice ah_auth_radius_check_nas_ip: updated nas_ip(10.108.30.18)
2011-05-10 10:11:18 info radius_msg_get_vendor_attr: select vhdr(type=17, len=52)
2011-05-10 10:11:18 info radius_msg_get_vendor_attr: select vhdr(type=16, len=52)
2011-05-10 10:11:18 info RADIUS: The RADIUS server accepted user 'HiveUser' through the NAS at 10.108.30.18.
2011-05-10 10:11:18 info RADIUS: eap auth for STA=0019:7e9d:871d user=HiveUser successfully with type peap
2011-05-10 10:11:18 warn RADIUS: User 'LDAPLAB\HiveUser' do LDAP_search under baseDN 'dc=ldaplab,dc=abccompany,dc=com' from server '10.22.33.44' failed
2011-05-10 10:11:18 warn rlm_ldap: (re)connection attempt failed
2011-05-10 10:11:18 err rlm_ldap: cn=HiveAPBind,ou=people,dc=ldaplab,dc=abccompany,dc=com bind to 10.22.33.44:636 failed: Can't contact LDAP server
2011-05-10 10:11:16 notice ah_auth_radius_check_nas_ip: updated nas_ip(10.108.30.18)
2011-05-10 10:11:16 info RADIUS: eap auth for STA=0000:0000:0000 user=HiveUser successfully with type mschapv2
2011-05-10 10:11:16 warn RADIUS: User 'LDAPLAB\HiveUser' do LDAP_search under baseDN 'dc=ldaplab,dc=abccompany,dc=com' from server '10.22.33.44' failed
2011-05-10 10:11:16 warn rlm_ldap: (re)connection attempt failed
2011-05-10 10:11:16 err rlm_ldap: cn=HiveAPBind,ou=people,dc=ldaplab,dc=abccompany,dc=com bind to 10.22.33.44:636 failed: Can't contact LDAP server

Therefore, using the Aerohive credential caching feature, EAP authentication services can be maintained during a WAN outage or central site service disruption. This feature bridges the gap for branch sites, allowing continued WLAN network access by clients during temporary service disruption. The cache lifetime setting dictates the tolerable duration of a service outage.

Revolution or Evolution? - Andrew's Take
Industries from retail, education, hospitality, healthcare, and transportation are relying on mission-critical wireless networks to operate business. They expect a highly secure and highly available network at reasonable cost and with minimal complexity. And they won't tolerate trade-offs between these features. The status quo from most WLAN vendors is to provide basic RADIUS integration for client authentication. Aerohive has gone further, integrating native LDAP and Kerberos functionality which provides user credential caching enabling a highly available WLAN network without compromising security to get there.

Aerohive isn't rewriting the book on RADIUS, LDAP or Kerberos. These are existing, mature protocols. However, Aerohive has applied these features in a new and unique way that can dramatically improve WLAN availability and provides tremendous benefits for distributed organizations with branch offices.

Cheers,
Andrew


Other Posts You Might Like:

• Aerohive HiveAP Provisioning Basics
• Wireless Tech Field Day - Day 1 Recap (MetaGeek, Cisco, Aerohive)
• Aerohive HiveManager Configuration Workflow
• Aerohive HiveAP Initial (Guided) Configuration

Dynamic VLAN Assignment

In my previous post, Wireless Network Segmentation Options, I described the need to minimize wireless SSIDs and provided 3 options for practical network segmentation within complex networks.

As a follow-up, I would like to briefly show administrators how to implement the second option, dynamic VLAN assignment. This allows a single SSID to serve multiple user roles tied to separate back-end network VLANs (as long as the same wireless authentication, key management, and encryption ciphers are used).

To prevent client devices from associating to the access point using an unauthorized VLAN, you can assign the user or group to a VLAN on your RADIUS authentication server.

The VLAN-mapping process consists of these steps:

1. A client device associates to the access point using any SSID configured on the access point.
2. The client begins RADIUS authentication.
3. When the client authenticates successfully, the RADIUS server maps the client to a specific VLAN, regardless of the VLAN mapping defined for the SSID the client is using on the access point. If the server does not return any VLAN attribute for the client, the client is assigned to the VLAN specified by the SSID mapped locally on the access point.

The RADIUS attributes to configure for VLAN assignment are IETF RADIUS attributes 64, 65, and 81, which control VLAN assignment of users and groups. See RFC 2868 for more information.

• 64 (Tunnel-Type) should be set to VLAN (Integer = 13)
• 65 (Tunnel-Medium-Type) should be set to 802 (Integer = 6)
• 81 (Tunnel-Private-Group-ID) should be set to the VLAN number. This can also be set to VLAN name if using a Cisco IOS device (excludes Aironet and Wireless Controllers however).

Cisco Autonomous Environment Notes
Unicast and multicast cipher suites advertised in WPA information element (and negotiated during 802.11 association) may potentially mismatch with the cipher suite supported in an explicitly assigned VLAN. If the RADIUS server assigns a new VLAN ID which uses a different cipher suite from the previously negotiated cipher suite, there is no way for the access point and client to switch back to the new cipher suite. Currently, the WPA and CCKM protocols do not allow the cipher suite to be changed after the initial 802.11 cipher negotiation phase. In this scenario, the client device is disassociated from the wireless LAN.

Cisco Unified Environment Notes

The Allow AAA Override option of a WLAN allows you to configure the WLAN for identity networking. It allows you to apply VLAN tagging, QoS, and ACLs to individual clients based on the returned RADIUS attributes from the AAA server.

Cisco wireless LAN controllers also support Airespace vendor specific attributes that can allow an administrator to define a WLC Interface-Name, QoS-Level, or Access Control List (ACL) to be applied to the user or group being authenticated.

Radius attribute 26 (Vendor Specific Attribute) should be used to configure the Airespace values. The Airespace Vendor ID is 14179.

• Aire-Interface-Name (Type 5) should be a string matching the name of the WLC interface to map the user into
• Aire-QoS-Level (Type 2) should be a value (0-3) mapping to the following QoS levels:
• 0 = Bronze (Background)
• 1 = Silver (Best Effort)
• 2 = Gold (Video)
• 3 = Platinum (Voice)
• Aire-ACL-Name (Type 6) should be a string matching the name of the ACL to apply to the user session

Also, ensure that the RADIUS server is using a NAS type of "Cisco-Airespace" when returning Airespace VSAs, otherwise the attributes will not be returned to the controller. If not using Airespace VSAs, a NAS type of "Cisco-Aironet" will work.

Cheers,
Andrew

Wireless Network Segmentation Options

Wireless Network Segmentation Requirements
Wireless networks often have as one of their many goals the secure segmentation of different user roles. This is typically due to various reasons including distinct device capabilities (or lack thereof), varying network/application/data access rights among user classes, support for guest or partner Wi-Fi networks, or separation of user classes from one another.

Traditionally, wireless network segmentation has been accomplished by creating separate Extended Service Set Identifiers (ESSID / SSID), and mapping each to a different network VLAN with access restrictions performed by some upstream device such as a firewall or router.

However, that approach is increasingly ill-suited for today's complex wireless networks, which are tasked with supporting multiple user roles, device classes, and information security distinctions over the same network infrastructure equipment. Creating separate SSIDs for each security scenario can quickly tailspin a Wi-Fi network into sluggish performance due to the overhead created to support each virtual BSS.  For an overview of this issue, see "Limit SSIDs and Data Rates to Maintain Network Performance." And the need for segmentation is only growing with the expanding Consumerization of Enterprise Wi-Fi and IT in general. If your organization hasn't seen an influx of smartphones, tablets, and personal computing devices, it will soon.

Couldn't we just use a single SSID to support all these various user roles, you may ask? The good news is that you can. A single SSID can be used for all similarly capable device classes, such as all devices that support 802.1x / EAP authentication with WPA2, but user role distinctions do not necessarily need different SSIDs (a few SSIDs may still be required to advertise and support varying authentication and encryption security methods, but in general many similarly capable devices can be collapsed into the same SSID). Centralized RADIUS can be used to distinguish user-roles based on group mappings and return security attributes to the wireless network for enforcement. This is called Identity Based Networking, and it has traditionally involved RADIUS servers returning a dynamic VLAN assignment for the authenticated user to the network.

The downside to this method is that multiple back-end VLANs, IP subnets, and security enforcement points are still required on the wired network. This causes increased administrative management and support, wasted IP addressing space, difficulty in appropriately sizing various network segments (especially considering the tremendous growth and fluctuation of wireless endpoint requirements), and leaving a disconnect between policy assignment (at the wireless AP) and policy enforcement (at an upstream firewall / router).

Private VLAN Concepts

Private VLANs are one method to provide network segmentation between hosts without wasting IP addressing space. This is accomplished by creating one large Layer 3 subnet and using special (Cisco proprietary) Layer 2 VLAN segmentation at the port-level to create security boundaries between hosts, rather than rely on a static one-to-one mapping of VLAN to IP subnet as is traditionally done.

Essentially, one 'Parent' VLAN is mapped to the IP subnet for all hosts, then secondary 'Child' VLANs are used to segment traffic between different security domains. These child VLANs can be either 'Isolated' or 'Community'. Isolated child VLANs allow the host(s) on assigned ports to only communicate with the default gateway. Community child VLANs allow the host(s) on assigned ports to communicate with the default gateway as well as other hosts in the same community child VLAN. For a good primer on Private VLANs see Jeremy Stretch's article on Basic Private VLAN Configuration over at PacketLife.net.

Private VLANs and Wi-Fi Networks
Using Identity Based Network integrated with Private VLANs would seem to be a logical extension of identity based networks for wireless networks. First, since wireless networks involve user mobility, using a single large client VLAN is appealing to reduce Layer 3 roaming requirements between subnets. As clients move throughout the wireless environment they need to retain the same IP address to maintain application sessions and provide a good user experience. Second, the large growth of wireless endpoints on corporate networks makes reducing IP address and VLAN ID waste attractive. Third, the requirement to support various external user roles on the same network is growing as more organizations need to support various business partners and vendors on the corporate wireless infrastructure. In essence, private organizations are leveraging their wireless infrastructure like a managed service provider, facilitating business processes that involve external entities. All of these external entities may need similar network access such as Internet, VPN, and on-site collaboration capability within their group, yet should be segmented from other external entities also at the customer / partner site.

However, using Private VLANs for wireless users is not possible due to capability limitations of Cisco wireless equipment. As Jeremy Stretch pointed out in Private VLANs on Trunks and SVIs, when PVLAN information is tagged across 802.1q trunk links the Parent VLAN ID is used for traffic sourced from promiscuous ports, and the Child VLAN ID is used for traffic sourced from child ports. This incongruity in VLAN tagging breaks down on trunk ports to wireless access points.

Let's use the following illustration to demonstrate:

Here we can see that the Private VLANs are setup with VLAN 100 as the Parent, and VLANs 101 and 102 as Child Community VLANs. The goal is to have clients be able to communicate with other hosts in their child VLAN, but not hosts in other child VLANs. However, we see that wireless integration with PVLANs breaks down because wireless equipment does not understand the PVLAN concept of parent and child VLAN associations, as wired switches do. In order for communication to function correctly across trunk links, both ends must understand the child to parent relationship, since only the source VLAN is tagged across the trunk link.

In this example, the client in VLAN 102 associates to the AP and issues a DHCP Request. This frame transits the trunk link using a tag of 102. The wired switch understands the parent and child VLAN association and is able to forward the frame out of the promiscuous port to the router (default gateway) without any tag since this is an access port in VLAN 100. The router responds with a DHCP Offer frame, which transits the trunk link using a tag of 100 (the parent VLAN). The AP receives this frame and drops it because no SSID is associated with VLAN 100. Creating another SSID tied to VLAN 100 also won't help because the client will still be associated to the VLAN 102 SSID. And moving the client into an SSID tied to VLAN 100 causes the client to be considered "promiscuous" and defeats the entire purpose of private VLAN segmentation.

Therefore, we end up with one-way communication. Ultimately, the lack of wireless equipment's ability to understand private VLAN concepts prevents the association of parent and child VLANs. This prevents the use of private VLANs with Cisco Autonomous, Lightweight (local mode), and Lightweight (H-REAP) wireless networks.

Note - Routers do not understand private VLAN concepts either, which requires them to be connected to the switch using an access port rather than a trunk port.

Wireless Network Segmentation Options
The options left for wireless network segmentation include:

1. Multiple SSIDs mapped to separate VLANs and IP subnets (the traditional solution)
   Benefits - secure segmentation between user roles; straight-forward network administration and support.
   Drawbacks - increased wireless network overhead and reduced performance; wasted VLAN IDs and IP address space; static policy definitions are not flexible to address changing needs.
   
   
2. Single SSID integrated with identity based networking concepts, RADIUS dynamic VLAN assignment, spearate VLANs and IP subnets, and upstream firewall or router policy enforcement.
   Benefits - secure segmentation between user roles; reduced wireless network overhead and improved performance.
   Drawbacks - wasted VLAN IDs and IP address space; complex network administration and support; disconnect between policy assignment and policy enforcement implemented in different equipment.
   
   
3. Single SSID integrated with identity based networking concepts, RADIUS policy definition, and edge firewall policy enforcement capabilities in the access points, and a single wired VLAN and IP subnet for wireless clients.
   Benefits - secure segmentation between user roles; reduced wireless network overhead and improved performance; preservation of VLAN IDs and IP address space; straight-forward network administration and support; integrated policy assignment and enforcement in the same equipment.
   Drawbacks - limited wireless vendor support for integrated firewall capability in access points; may require more powerful access point hardware to maintain performance.

Option 1 is clearly the traditional and most well-understood of the three options. However, it suffers from lack of scalability and fairly rigid user classifications and policy enforcement that is not easily changed without major effort. This option has broad market support in almost every enterprise-class Wi-Fi product.

Option 2 improves the situation by reducing wireless network overhead, but adds complexity by requiring correct centralized policy assignment through RADIUS attributes in order for security access to be controlled correctly. It also fails to address the back-end wired network complexity and similarly suffers from lack of scalability and rigid policy enforcement. However, this option also has broad market support.

Option 3 is clearly the best of all options, as it combines improved wireless network performance, easily scalable growth, simplifies back-end wired network complexity by reducing VLAN IDs and preserving IP addressing space, centralizes policy management, and integrates policy assignment and enforcement in the same equipment. However, this option may require more powerful access points to process user traffic, inspect and apply appropriate security controls, and maintain throughput and low-latency performance. This option also has limited market support, with only a handful of vendors supporting integrated firewall capability in access points.

Any of these three options will provide adequate network security when designed properly.

Cheers,
Andrew