Pages

Tuesday, January 25, 2011

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

10 comments:

  1. The 3rd option is the most attractive, however I am not sure why you need the firewall options in the AP if you have a firewall between the APs and the gateway. We are looking to implement this on a WLC with a FWSM that holds the gateway IPs for the different backup wireless subnets. I fail to see the security issues with this.

    ReplyDelete
  2. we were trying to impliment something like #2 recently and found that we were having issues with APs in hreap mode doing local switching for remote office solutions. I actually discovered your blog via a comment you had about this being a longstanding bug. Is that still the case? and is there any public link for this issue on cisco's site that we can reference?

    ReplyDelete
  3. Hi mlit,
    Any of the three options are valid. The option chosen is heavily dependent on the requirements the solution must meet.

    The benefit of having a firewall integrated into the access point is that it allows for much more flexible policy control, easier changes to the environment, and reduces the number of VLANs and IP subnets that must be deployed to segment different user roles.

    Consider a situation where multiple user roles need to be supported using a single SSID. If the security policies are enforced at the upstream firewall or router, then each user role requires a separate VLAN and IP subnet. In large organizations, IP addressing space is often at a premium (even using RFC1918 private address space). Additionally, over time, client and user populations may shift. Accurately sizing several distinct IP subnets for different purposes gets tricky. Perhaps a /24 for each user role is adequate today, but with growth and shifting needs, they may need to grow over time. If all /24s are concurrently assigned, growth then requires a complete re-addressing of all the subnets. Additionally, initially there is usually "free space" in each subnet so that it is not maxed out right away. This leads to many small subnets having free space, and this adds up to wasted IP space in general.

    Also, consider client to client communication needs. Perhaps wireless clients need to communicate using only certain applications (say video collaboration and file sharing). With most enterprise wireless networks today, there are only two options: 1) allow all client to client traffic or 2) block all client to client traffic. This is a very coarse policy, and leaves no room for granular control to only allow certain applications. This could leave clients open to virus or worm propagation, etc.

    Now consider the security policy enforced at the access point with an integrated firewall. A central RADIUS server can pass back an attribute to specify the firewall policy name to be applied to each user or group of users. The AP enforces the policy right at the edge. On the back-end wired network only a single VLAN and IP subnet are required to support all user roles. Growth becomes easier since only one subnet needs to be modified, and overall capacity planning becomes easier when forecasting for the total amount of clients to be supported irregardless of user role, rather than attempting to forecast the amount of clients in each of multiple categories.

    Additionally, the firewall policies can include client to client communication using only specific applications defined by the organization, and block everything else. This approach reduces IP address waste and provides more granular policy control.

    Like I said, the option chosen really depends on the organizational requirements being planned for. Any of the 3 options are perfectly viable when designed correctly.

    Cheers,
    Andrew

    ReplyDelete
  4. Hi Brian,
    I am assuming you're referencing my H-REAP Feature Limitations post.

    At this time, AAA Override (Identity Based Networking) is still an unsupported feature with H-REAP access points. I have an open feature request with Cisco to address this need. Once I have an updates, I will be sure to share them with the community.

    Andrew

    ReplyDelete
  5. I especially appreciate the information you have provided, and the links shared on this topic. Your assistance has been invaluable to me during this process.IT Support in this day and age is of paramount importance for all those that are interested in taking their experience with technology to the next level.

    ReplyDelete
  6. Hello, are you able to share some configuration example of 2nd option? Thks

    ReplyDelete
  7. Hi Joao,
    For a configuration example of Dynamic VLAN Assignment, see my other post on that specific topic. Here is the link.

    Cheers,
    Andrew

    ReplyDelete
  8. wouldn't you be able to do the following? :

    - keep private vlan config for all wired clients, depicted as the servers above or other pcs. Nothing changes here.

    - put the wireless clients in a different vlan, say for example vl 103.
    - create an access port on the switch for vl 103
    - create another access port on the same switch using the private vlan host config with vlan 102 or 101, and associate to primary vl 100 (standard private-vlan host interface, configured as same as where the servers are plugged into)
    - use a x-over cable connect the access port vl103 with the private vlan host port which bridges the two vlans together essentially
    - enable pspf on bridge-group on AP to prevent wireless clients from talking together

    it would be cleaner to be able to soft-bridge the 2 vlans together (using a bridge group or something), but don't think that would fair well with IOS with private vlans enabled. Would probably have to use a physical cable (which is a bit of a hack...) but I think it would work. Just don't have the hardware to test it on :)

    ReplyDelete
  9. Hi Rich,
    Your scenario should technically work, but it is using a pretty ugly hack by bridging two different VLANs together. There are numerous opportunities for error in both configuration and cabling, not to mention trying to troubleshoot a problem should one arise.

    I also don't think this would be a scalable solution, and it wastes switch ports.

    I would highly recommend against that approach. Very clever thinking though!

    Andrew

    ReplyDelete
  10. Hi Andrew,
    I am setting up a wlan for large campus that does not have user role differenciation (at least for now) but there are ~3000 users. I am using single SSID with multiple backend VLANs to segment traffic only for performance concerns. Using coontroller-less architecture, with back-end RADIUS server for authentication only. I am using a separate SSID for Guest access. Is using multiple vlans only for performance a valid design goal?

    ReplyDelete