Aruba Virtual Branch Network (VBN) RAPs

By Lisa Phifer

August 24, 2009

Wi-Fi networking expert Lisa Phifer takes an in-depth look at Aruba’s Interop Best of Show award-winning VBN RAPs.

Related Articles

Aruba Networks RAP-2WG and RAP-5WN

Price: RAP-2WG ($99) or RAP-5WN ($395), plus RN-licensed Aruba controller
Pros: Business-grade WLAN security and QoS without pre-provisioning or on-site IT

Cons: Zero-touch requires 3000/6000 controller, awkward end-user help, $99 only buys 11b/g

Highly-distributed businesses have long faced a choice of evils: ship skilled staff out to install pricey enterprise APs or let small branch and home office workers install their own consumer plug-n-play APs. For organizations with hundreds of storefronts or thousands of teleworkers, the former is prohibitively expensive. But for secure multimedia WLANs, the latter is unthinkable.

According to Aruba Networks, Virtual Branch Networks (VBNs) are a more palatable solution. Interop LV09 judges were impressed, awarding Best of Show in the Wireless/Mobile category to VBN. During our own test drive, we found VBN extremely promising—but we spotted a few rough edges that could use bit more honing.

Virtualizing remote WLANs

Aruba’s VBN is an architecture that enables centralized control over a large number of small remote office WLANs, up to 100 clients apiece. In the VBN architecture, every Remote Access Point (RAP) operates as a remotely-managed VPN gateway, enforcing role-based access policies and tunneling only permitted traffic back to the corporate network.

Sure, branch office VPNs can be built using many enterprise wireless routers. What differentiates Aruba’s VBN is entry-level gear with “zero-touch” provisioning. Aruba can drop-ship factory-default $99 RAPs to hundreds of destinations on your behalf. On first power-up, each RAP tunnels over the Internet to a user-designated Aruba controller. When the controller hears from a whitelisted RAP, it installs and activates IT-defined firmware and policies over a secure boot-strap tunnel. The end result: a business-grade WLAN, provisioned in less than ten minutes, with almost no end-user or IT assistance.

Eliminating advance or on-site IT provisioning from an otherwise lengthy, error-prone process speeds new site activation and reduces per-site investment. And, because RAPs are managed over that tunnel throughout their life, IT can remotely assert relatively sophisticated, dynamic role-based access controls. While $99 RAPs are ultimately constrained by inexpensive hardware, the policies they can enforce are far from consumer-grade.

Putting VBN into action

This architecture can be implemented using any combination of the following new VBN RAPs.

The RAP-2WG ($99) is a fist-sized single-radio 802.11b/g AP with two 10/100 Ethernet ports, targeted for use by “fixed telecommuters” and home offices with up to five users. (Pictured above.)

The RAP-5WN ($395) is a desktop/wall-mount dual-band 802.11a/b/g/n AP with five 10/100 Ethernet ports, slated for small branch offices with up to 256 users. (Picture below.)

The RAP-5 ($395, not tested) is a wired-only RAP-5WN, to incorporate small branches that require authenticated, secure Ethernet, but not wireless VBN access.

Older (non-VBN) Aruba RAPs can be added to the same network manually—for example, the dual-radio AP-125 for a branch requiring simultaneous dual-band operation. However, the zero-touch feature that appealed to us is only available in new VBN RAPs. To road-test VBN, we therefore installed an RAP-2WG and an RAP-5WN in over a dozen home and small office networks.

Building a foundation

No matter how provisioned, RAP firmware and policies must be supplied by an Aruba controller. Thereafter, RAPs treat that controller as their VPN hub, which processes tunneled traffic, applies central NAC and firewall policies, authenticates users, and aggregates intrusion alerts. Aruba sells six controller series, designed for different network sizes and topologies.

We had hoped to use a new 600 Series controller to activate our RAPs. We even trialed the Aruba 651 ($1495), a “branch-in-a-box” controller that incorporates a firewall/router/VPN gateway, 8-port PoE switch, file server, print server, and dual-band 802.11a/b/g/n AP. The 651 can be deployed solo at a medium office (256 users), supervising up to 64 RAPs. Alternatively, the 651 can participate in a bigger network, under the direction of a master controller like the Aruba 6000.

Alas, zero-touch is only supported today by 3000/6000 Series controllers running an “RN” ArubaOS image (e.g., v3.3.2-rn3.0). If we wanted to manually provision our 2WG or 5WN, our 651 could have supervised them like any other RAP. But we wanted to experience the benefits and limitations of a zero-touch VBN rollout. So we settled for a remote walk-through an Aruba-installed 6000 controller that supervised our zero-touch-provisioned RAPs.

That let us experience VBN RAP set-up and troubleshooting from IT’s perspective, without installing our own 3000/6000 controller. However, anyone contemplating their own zero-touch VBN rollout must include TCO for at least one 3000/6000 controller. To learn about designing and deploying an entire VBN from scratch (including controllers), consult Aruba’s 234-page, intensely detailed, but well-illustrated Virtual Branch Networks Validated Reference Design.

Many early adopters will be Aruba customers with existing controllers, now adding VBN RAPs to reach venues previously deemed too expensive. Zero-touch makes the biggest bang in large-scale unattended deployments, but we hope zero-touch provisioning gets added to smaller controllers. For example, SMBs with entirely-distributed workforces (e.g., insurance agents) might buy a pair of 651 controllers and dozens of RAPs, but can’t ask their one-and-only IT guy to baby-sit 100+ remote installs.

Planning a VBN deployment

Aruba’s VBN Reference Design breaks remote network deployment into six steps:

1) Deploy data center

2) Install pilot sites

3) Provision backhaul circuits

4) Train the help desk

5) Stage site equipment

6) Execute full deployment

We started at step 2 by adding two RAPs at our office to a demo network at Aruba HQ. To perfect network design and finalize configs, Aruba suggests piloting 5-20 venues that represent a variety of small branches and telecommuters, wired and wireless devices, and backhaul scenarios relevant to your business.

As in most pilots, we encountered a few bumps ironed out before full deployment. Only later did we receive the factory-shipped Install Guide or controller-generated QuickStart Guide. We then simulated step 6 by carrying our RAPs to over a dozen “real end-user” venues. At each, we had a volunteer use Install/QuickStart Guides to a freshly-reset 2WG without assistance.

We bypassed step 3 by using whatever Internet link was available at each venue, ranging from 3G and residential broadband to hotspot T1 and large enterprise LAN. Aruba had already completed step 5 by shipping us whitelisted RAPs, along with a VoIP phone configured to receive calls through the demo network.

That left step 4. To really cut TCO, most installs must go smoothly and any problems must be resolved quickly. Four of our approximately 18 installs required help—but that includes two “pilot” installs. A large-scale rollout might well achieve a higher success rate. Nonetheless, every Help Desk needs a “what can go wrong” RAP install and diagnostic checklist. The aforementioned Reference Design doc is an excellent place to start developing your own.

In our view, this otherwise thorough process overlooks a crucial step: end-user documentation. We strongly recommend supplementing Aruba’s printed and online end-user help. The Install Guide is written for network-savvy readers. For example, after connecting a WAN (but not LAN) cable, readers are told: “Once the boot cycle is complete you can connect to your company or corporate network. See the Provisioning-at-Home section if you are unable to connect successfully.”

At this point, every volunteer pondered “Boot cycle?” or “Connect how?” They were also confused by some RAP progress messages (see below). Simple questions like these are easily avoided by developing road-tested end-user instructions before full deployment—but could become costly if ignored.

Pulling the trigger

So what’s really required from end-users during zero-touch install? Connect Ethernet port 0 to Internet link, Ethernet port 1 to laptop/desktop, and plug in AC. Wait 1-2 minutes for port 1 to light persistently (i.e., DHCP done), then open a browser window to any URL. When the RAP’s Setup page appears, enter an employer-supplied Aruba controller IP or hostname. Sit back and watch a sequence of geek-speak appear (below), ending with a reboot pop-up.

So far, so good. Unfortunately, that pop-up promises to launch the RAP console when done, which never happened. Volunteers got impatient and resorted to browser refreshes, eventually ending up at a guest login prompt instead. Why? The policy activated upon reboot (usually a 5-8 minute wait) bridged Ethernet clients onto a guest network that prohibits console access.

Thus, our best case always included brief confusion, but yielded a fully-functional RAP, auto-magically configured with three demo WLANs: a captive-portal rn-demo-guest SSID, a best-effort WPA2-PSK rn-demo-employee SSID, and a prioritized WPA2-PSK rn-demo-voice SSID. In any VBN rollout, IT decides how to divvy, secure, prioritize, and monitor remote wireless/wired access by creating AP Group policies. The RAPs assigned to each AP Group enforce those policies at the VBN edge, based on each client’s role.

Our RAPs were configured to give teleworkers clientless demo network VPN access and guest/family Internet access. They filtered and prioritized incoming calls to our VoIP phone without exposing that sensitive service to remote misuse. the features required to support these policies—WPA2, WMM, VLAN, RADIUS, role-based access controls—are enterprise AP table-stakes. VBN makes it easier to apply these complex policies to smaller remote sites, in larger volume, at lower cost.

Under the hood

Any controller can install policies on local or pre-provisioned APs. The challenge is to install them on factory-fresh RAPs from afar, securely and reliably. Here’s how VBN does it.

1) Configure an Aruba controller with AP Group policies. As RAPs are purchased, add their MAC addresses to the controller’s RAP whitelist, either individually or using a wizard. Each whitelisted RAP is given an AP name, user’s name, and assigned to an AP Group.

2) When a fresh RAP boots, it tries to find an Aruba controller. It uses DNS to look for aruba-master. If that fails (as in most small/home offices), a controller’s IP or hostname must be supplied by the end-user.

3) The RAP establishes an IPsec tunnel to the controller, using the RAP’s certificate to complete IKE phase 1 and supplying its MAC address via XAUTH. If the RAP’s MAC is on the whitelist, XAUTH passes and a secure IPsec “bootstrap” tunnel is established.

4) The controller uses that tunnel to upgrade RAP firmware (if necessary) and push a full RAP config (based on AP Group). The RAP reboots a few times before reestablishing a “real” IPsec tunnel to its controller.

5) Thereafter, the RAP uses provisioned WLAN, firewall, and routing rules to decide who can connect and where traffic should go. For example, split-tunneling can allow intra-LAN communication (e.g., printing) with everything else tunneled into the corporate network. (At the far end, upstream controller(s) apply their own rules.)

6) Wireless or wired clients must authenticate to the RAP as defined by policy. For 802.1X and captive portal authentication, requests are tunneled to a corporate RADIUS/LDAP server. Every authenticated client is placed into a role that determines what it can reach.

Few speed bumps, one road block

This zero-touch process works transparently and reliably, so long as the site has Internet access, DNS/controller reachability, and a wired laptop/desktop with compatible browser. So what can go wrong?

Every so often, users are going to mix up LAN and WAN ports, encounter connections that don’t renew after RAP reboot, or run into down routers and uplinks. The RAP console offers diagnostic tools like ping and nslookup to assist with the latter. However, Aruba’s Install Guide could use a basic connectivity checklist and user-oriented diagrams.
During our first pilot install, an incompatibility with OpenDNS caused our RAP to reboot itself repeatedly. Aruba fixed this and all RAPs now ship with newer firmware.
Next, our RAP let us enter a controller hostname but could not establish a tunnel. The RAP said “RC_ERROR_IKE_XAUTH_AUTHORISATION_FAILED”—which means “Your RAP isn’t whitelisted.” We’d prefer to see the raw log messages displayed by the RAP console converted to user-friendly trouble-shooting hints.
After provisioning, we connected to both RAP guest WLANs and to our 2WG but not 5WN employee WLAN. Why? The 2WG is 802.11b/g only; the 5WN supports 802.11a/b/g/n. Both had been provisioned with an employee WLAN requiring WPA-PSK—forbidden for 11n’s high-throughput data rates. Aruba refined that policy to use WPA2 instead (pushed immediately to all RAPs) and that did the trick. This shows the benefit of centralized control, although scheduling selected RAP updates would be a nice addition.
Aruba’s IPsec supports NAT traversal and seems relatively robust, but one install did encounter an office network that blocked everything except HTTP and DNS, prompting the RAP to complain “RC_ERROR_IKEP1.” As a visitor, we did not have the authority to modify that upstream firewall to allow IKE, so had to abandon that RAP install.

During the initial stages of a zero-touch install, cable/connectivity problems must be resolved by the end-user, aided by RAP console messages and tools. After the controller is reachable, admins can use central status windows and logs to spot and debug more complex problems, like IPsec, NAT, or bridge/tunnel forwarding issues.

For example, the VoIP phone Aruba supplied connected and registered with a SIP server but still did not receive incoming calls. On the remote end, there wasn’t much we could do to diagnose the problem—and that’s intentional. At the controller, tech support had all of the information and tools needed to examine policies, trace traffic, and fix the root cause (an upstream issue).

In short, zero-touch simplicity does not make the RAP harder to support after provisioning—every RAPs, whether provisioned manually or automatically, is centrally-managed in the same way, using the same tools. But if something should ever go mysteriously wrong, the user can always punch the RAP’s reset button to repeat zero-touch install. Frankly, having dealt with many slightly-crippled pre-provisioned devices over the years, we really love that kind resilience.

The flip side

After road-testing the end-user side of zero-touch VBN rollout, we took a brief peek at the controller support required for zero-touch provisioning. As previously noted, RAPs can be added to the controller’s whitelist one by one or in bulk, using an AP wizard (below).

In addition to bulk whitelisting, the wizard offers several important features. First, the admin adds RAPs by importing a CSV file of MAC addresses or selecting from a list of previously-provisioned RAPs. Associated text attributes can be modified—for example, to give each RAP a readily-recognizable AP and user name.

Next, the wizard can specify a login/password for first access after RAP provisioning. This one-time authentication can be useful in venues where clients like RFID scanners don’t routinely authenticate, but you still want to ensure that a whitelisted RAP is installed by an authorized user.

Finally, the wizard can generate a custom QuickStart Guide—a one-page PDF that tells end-users how to enter their controller’s hostname when prompted. In our view, QuickStart is a step in the right direction, but Aruba still needs to polish this. Custom text is quite limited; we spent all 256 characters telling volunteers how to react to that confusing reboot pop-up. We would have preferred RTF output for easy inclusion in our own documentation. Finally, we would really love to specify custom text to be displayed by the RAP when provisioning concludes.

After a RAP is provisioned, maintenance activities may include policy refinement and deactivation. For example, any active RAP is easily and immediately disconnected from the VBN by deleting it from the whitelist—that is, blacklisting the RAP. If a RAP is placed in an AP Group but requires some kind of policy exception (like access to an additional service or subnet), the easiest solution is to move that RAP into its own (cloned and modified) AP Group.

The only aspect of group-based RAP provisioning that troubled us was captive portal credentials. In theory, our RAPs required captive portal authentication for guest/family Internet access. In practice, every RAP in a given AP Group shares the same user database. So how would teleworker Jane define a guest login for husband John? She wouldn’t—John would probably just use a generic “visitor” login. While Jane’s admin could add John to the corporate AAA server, that seems rather unlikely.

Conclusion

Those early glitches did not concern us—they helped us appreciate cases that might normally be encountered in a VBN pilot, and tools available to help resolve them. Subsequent problems like receiving a RAP that someone forgot to whitelist or bumping into a firewall that blocks IKE no doubt occur in a large rollout but are probably rare. Overall, we were impressed by how quickly and reliably we could bring up a wide variety of small sites using zero-touch-provisioned RAPs.

When it comes to large-scale rollouts, $99/RAP is a really attractive price-point. However, the 11n-capable 5WN rings in at roughly quadruple that price. Sure, many teleworkers don’t really need 11n. But some companies will balk at investing in new 11b/g APs at this point in time—even tiny self-sufficient ones.

Ultimately, we concluded that Aruba’s zero-touch VBN approach is off to a promising start. We would like to see broader controller support for zero-touch provisioning and more/better end-user-oriented guidance (both electronic and printed). The former would make VBN more accessible, while the latter could further boost TCO.

Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. She has been an avid fan of wireless technology since the mid-90’s, and has participated in hundreds of Wi-Fi network design, implementation, and testing projects over the years.

Author
Recent Posts

Eric Sandler