Home » Aruba Network

Aruba Network

Aruba Products

Network Segmentation

- Posted in Aruba Network by

Last week, while we were exhibiting at the Connecticut Education Network conference, one particular subject came up with visitors to our booth a couple of times: network segmentation-the separation of school networks or VLANs according to their function. The topic was motivated partly by new requirements from insurance companies for increased internal network security.

You can picture a segmented network as one where the firewall is pulled into the core and sits between different internal network segments. In the case of a school district, segmentation could separate administrator VLANs from student VLANS, or separate the BoE from the high school, as examples.

Network segmentation isn't a new idea, but the appearance of a couple of technologies in equipment that school districts are likely to use, plus the performance of firewalls and processors, are making it easier to accomplish.

To explain these improvements, it might be good to start with what's wrong with trying to use last year's firewall and core switch to accomplish the job. Say that we have the following common configuration: a layer-3 core switch that interconnects traffic coming from each school, and possibly multiple VLANs from the schools, which is trunked back to the head-end of the network.

              :                    :
          --------             --------
          |  FW  |             |  FW  |
          --------             --------
             |                    |
         ----------    -or-       |     ----------     
         |        |               |     |        |
         |  core  |               |     |  core  |
         |        |               |     |        |
         ----------               |     ----------
              |                   |      |   |
              |                   +------+   |
          user VLAN                 user VLAN
              |                              |

A typical configuration is for the core switch to forward internal traffic internally and to forward Internet-bound traffic to the firewall. The two devices could be in series or sit side-by-side. If we wanted to to segment the internal network so that some VLANs were forced through the firewall, how would we do it? The problem is that the core switch has a layer-3 interface on each of the segments, and would usually route the traffic internally.

To force traffic to a firewall requires policy-based routing, including a collection of policy-based routing ACLs that say "if traffic is from VLANx and bound for VLANy, forward to firewall interface on the local VLAN." This overrides the core switch's IP routing. The firewall has a routing table as well, and it probably lists the switch as the correct next hop, so it would be inclined to send an ICMP redirect back to the switch that says "go forward it yourself." In short, we'd have to force the traffic to the firewall and have the firewall forward it back. It's doable, but not graceful.

Another alternative would be to have the firewall act as the core switch. In that case all traffic would have to traverse the firewall, including layer-2 traffic, multicast, everything. This would be ugly, if it were possible; not all firewalls will forward at layer-2. Those that can, can also filter at layer-2. We'll return to that in a moment.

Some of the switches that you might consider for a core switch today, including Aruba Networks' CX line of switches, feature multiple, separate Virtual Routing and Forwarding domains (VRFs). A VRF is a virtual switch instance with its own routing table and ARP cache. Two VRFs running inside one switch cannot see each other and cannot trade traffic unless explicitly forwarded. A core switch with multiple VRFs can seamlessly forward traffic to a firewall without policy-based routing. And, the firewall can forward it back from one VRF to another. This is a graceful way to ingest a firewall into the core--particularly at layer-3 boundaries.

What about performance? Commercial hardware-based firewalls often contain dedicated silicon for fast-path, stateful forwarding of packets. As long as you don't turn on UTM features between internal segments, including intrusion prevention, layer-7 inspection for viruses or content, a firewall in the core should be able to keep up. The UTM features slow a firewall down because the increase the involvement of the CPU. Perhaps these are features that you want between VRFs, in which case a more powerful firewall may be called-for.

So far, we have described a core and firewall combination that can separate internal layer-3 networks or groups of layer-3 networks that share a VRF. Firewall policies can be applied between VRFs--some traffic can pass and some can be denied. What happens when someone from the board of education goes to the middle school and wants to connect back to their desktop? Suddenly, the all-too-familiar swiss cheese of firewall special exceptions gets worse because the firewall is inside the core!

Again, talking about Aruba Networks, there is a capability called Dynamic Segmentation that makes it possible to extend a VLAN from one part of the organization to a switch port in another. The VLAN is encapsulated into a GRE tunnel and then presented as an access VLAN on the switch at the far end. Dynamic Segmentation uses an Aruba wireless controller to forward tunneled traffic to the remote switch in the same way that it dynamically selects and tunnels a VLAN for a wireless user. Combining Dynamic Segmentation with a segmented network makes it possible to secure a network against itself yet still allow for exceptions for administrators and staff.

I mentioned layer-2 filtering with a core firewall, above. Aruba (again) recently acquired a company called Pensando that makes custom silicon for securing flows deep in the core. It is now available in the Aruba CX 10000-series switch (that lists for over $50K...). We're going to have to wait for it to come to an affordable core switch in your district, but it will be possible some time in the future.

-Kevin Dowd

Dynamic port configuration in Aruba OS-CX switches

- Posted in Aruba Network by

Aruba's OS-CX switches have the ability to profile devices connected to ports and dynamically assign roles and policies (ACLs) to those ports. The ACLs can include the usual stuff--filtering on source, destination and protocol. But, they can also include configuration parameters like VLAN assignment.

Here's a simple example that can be useful when deploying access points with bridged VLANs. In this example, the switch makes a profile of the connected device using LLDP (you can use CDP, too), parses the response and assigns a role to the port. The role has policies that assign VLANs.

To see how this would work, let’s say that we have an access point on port 1/1/10. Examining the LLDP query on the port, we get the following:

enter image description here

In our test for the presence of an AP, we will search the description for "IAP". To make the example a little more interesting, we will also skip any AP-305s we might find. The following are rules that will match our LLDP port access test. These are arranged like a sieve; the first pattern that matches wins.

 port-access lldp-group AP-lldp-group
      seq 10 ignore sys-desc 305
      seq 20 match sys-desc IAP

Next, we define the role and the policies that we want to associate with access points that match the above port-access tests. The block below says that the role is called "lldp-AP," and that the policies "create a trunk and allow VLANs 12,22,40 and 100, and make 100 be the native VLAN."

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native 100                                                                                                                                                                  
     vlan trunk allowed 12,22,40,100

This last section is the glue that pulls the port-access tests and the role assignment together. It says "if the device on port x matches AP-lldp-group tests then assign the role of lldp-AP."

 port-access device-profile AP-lldp-devprofile                                                                                                                                              
     enable                                                                                                                                                                                 
     associate role lldp-AP
     associate lldp-group AP-lldp-group

Dynamic profiling can be applied to other kinds of devices too, including printers, projectors and phones. When used in conjunction with Aruba Central or NetEdit, elements of the policies and port-access tests can be described using variables, such as this:

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native %_native_VLAN%                                                                                                                                                                  
     vlan trunk allowed 
     %_wireless_VLANs%,%_native_VLAN%

When used in conjunction with ClearPass and controllers, the ports can implement enhanced profiling, role assignment and dynamic segmentation whereby VLANs that don’t even exist on the switch can be tunneled from other parts of the organization.

Aruba AOS10

- Posted in Aruba Network by

Previous enterprise Aruba operating environments AOS 6.5 and AOS 8 were controller-based. Controller-based access points are the product of a time when APs were radio heads, capturing and producing wireless packets and ferrying them to a central controller. Little data processing was done at the access point—particularly in tunnel mode. Radio management, authentication and encryption were all performed centrally, at the controller.

Because of the increasing complexity of wireless networking protocols, the increasing speeds of wireless connections, and the increasing capability of access points, it is becoming advantageous to let the AP perform all of the processing and bridge traffic to the network at wire speed.

This is giving controllers the diminutive role of configuration and reporting. Configuration and reporting are less demanding than wireless network termination, and require much less bandwidth. Accordingly, it is possible to place portal anywhere, including out on the Internet.

Under Aruba AOS10, each access point is a controller. It gets it configuration from Aruba AOS10 Central. It acts in tandem with its neighboring access points to create a seamless wireless experience.

enter image description here

The picture above shows the components of an Aruba AOS10 network.

Access points (and switches) communicate with Aruba Central for configuration and logging. Each AP bridges traffic directly onto the network natively, via VLANs or both. Each AP communicates with its neighbors as far as several hops away. This enables roaming and forwarding of firewall state.

ClearPass, when in use, provides advanced authentication and security services, role-based access, network awareness and UEBA. ClearPass Policy Manager communicates with the access points directly, implementing RADIUS-based user access and Aruba firewall policies.

Controllers are not required, but they can be included in AOS10 for users who wish to have tunneled SSIDs or tunneled node 802.1x-based switch port access. The benefits of tunneled traffic are that data traverse the network fully encrypted and tunnels make it possible to extend access to remote layer-2 networks. Central on Prem(ises) duplicates the cloud-based AOS10 Central management capability onsite. It is offered particularly for those enterprises that, by choice or regulation, prefer to manage the network from within their own network.

  • Kevin Dowd