Last time, we discussed the role of a WiFi/Access edge firewall in protecting your network, and how it complements your perimeter firewall. Today, let's talk about how that same firewall actually makes the job of the network architect and manager easier.
It may seem counter intuitive that maintaining the configuration of another firewall inside your network will save you time and make for a simpler, more scalable design, but bear with me for a few minutes and I will explain how Aruba's PEF firewall and related features do just that.
Simplifies Access Control
Building on the concepts we discussed last time, let's assume you have at least modest needs for restricting user access on the network. This could be as simple as giving guests internet-only access, or could include simple controls on employees' BYOD devices. Regardless of your needs, let's look at the alternative solutions.
VLANs and ACLs
The most common alternative to role-based, stateful access firewalls is the tried and true approach of mapping different users to different Virtual LANs (VLANs) and adding static Access Control Lists to try to herd the traffic away from places it shouldn't go. This solution has a few drawbacks that make it much more difficult to maintain and result in less security for more effort.
The largest problem with this solution is that the appropriate VLANs need to be provisioned everywhere a given class of user will connect to the network. This means that a given VLAN, or one with the same name/number, needs to exist across the entire edge of the network. This presents a couple of challenges. One, care must be taken to make sure that these VLANs are present everywhere. Second, if the exact same actual VLANs are used, then it is quite likely that the diameter of the network - as defined by the number of switch hops from one end to the other - will grow large enough that there is the potential for spanning tree problems causing network outages. This is one of the reasons so many extensions have been added to the spanning tree protocol, and why so many vendors have developed their own approaches to loop management.
Security, of course, is the other issue. Nearly all of these approaches rely on "static" ACLs - ones that look at each packet individually, with no state information - instead of a persistent knowledge of the user and their access rights. This approach is fine for coarse-grain access like blocking all access to specific networks. But it lacks the ability to do important things like map a user's incoming and outgoing sessions together, so that the server responses can safely be sent back to the client. This highly limits what can be done with these controls.
Another drawback of this lack of session awareness is a lack of accountability - that is, logging information. By being user and session aware, Aruba's PEF firewall is able to log who accesses resource when, and from where. It also allows mapping of users to applications, web browsing behavior, and Unified Communications calls. This information can be used for auditing, compliance, and troubleshooting purposes. Add a powerful network management tool like Airwave to the mix, and this data becomes an invaluable tool.
SSIDs and Application Control
A common requirement these days is to restrict the applications a given user community is allowed to use, or to restrict the amount of bandwidth they are permitted to consume. Typical motivations are enforcement of acceptable user policies, and concerns about maintaining optimal performance for critical applications.
Doing the deep packet inspection required to make this application identification can sometimes turn out to be the easy part of the exercise. How do we layer this control onto our existing set of controls - VLANs and ACLs? Maybe make a decision based on SSIDs instead? That's the one!
In all seriousness, this creates another set of configuration complexity at the edge. Now you need to worry about what SSID a given user connects to (something only the client can control), what VLAN they are then mapped to, and the underlying set of ACLs assigned to that VLAN. Need to change something, and you'll need to review all of these areas to ensure that the change has the desired affect.
Obviously, the best approach to adding application visibility and control to your network would be to add these controls to the existing concepts already established with the access firewall. Adding stateful Application ACLs to the existing roles accomplishes this in an Aruba network without the need for new SSIDs.
Dynamically downloaded ACLs
Because of these two huge drawbacks, some vendors have been extending their security model to include dynamic access controls. In this scenario, the user group or role of the user triggers the download of a set of access control lists onto the network at the time the user logs in. This eliminates the need for the user to land on a specific VLAN, and reduces the spanning tree issues we've discussed.
However, there are two problems with this approach. Firstly, the ACLs are still stateless. Secondly, implementing this type of an architecture is often quite complicated. Typically, a complex network management tool is required. This tool often has several required components that must be installed and configured correctly in order to pull this off. Secondly, the capability to receive the ACLs, and the appropriate configuration, must be present ubiquitously throughout the switched edge network in order for this approach to work.
Simplifies network design, increases reliability
One of the key elements of Aruba's WiFi architecture is the fact that the traffic from all the Access Points is sent back through the network to the controller via a GRE tunnel. Once in the controller, the firewall is the next step for all the traffic. This approach dramatically simplifies VLAN management and scalability.
In the Aruba architecture, the AP needs a local IP address at the edge. This is generally done via DHCP. This is the ONLY IP address that is consumed on the local VLANs. Instead of mapping the users to local VLANs, all user traffic is sourced from a VLAN that resides on the controller. This means that no VLANs need to be plumbed from the edge to the distribution layer for the client traffic. Furthermore, the controller can assign a VLAN to the user via a "VLAN pool" - a large collection of VLANs. This makes it very simple to add additional VLANs as the device community as the edge grows and IP addresses are depleted. Eliminating the proliferation of VLANs throughout the access layer reduces the complexity, configuration time, and significantly enhances the reliability of the Spanning Tree infrastructure at the edge.
