Review: Aruba Virtual Branch Network (VBN) RAPs - Page 3

By Lisa Phifer

August 24, 2009

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).



Click to enlarge.



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.



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.


Pages: 1 2 3

Comment and Contribute
(Maximum characters: 1200). You have
characters left.