Virtual Branch Networks

Virtual Branch NetworksVersion 3.3.2-rn3.0

Virtual Branch Networks Validated Reference Design

Copyright© 2009 Aruba Networks, Inc. AirWave®, Aruba Networks®, Aruba Mobility Management System®, Bluescanner, For Wireless That Works®, Mobile Edge Architecture®, People Move. Networks Must Follow®, RFProtect, The All Wireless Workplace Is Now Open For Business, Green Island, and The Mobile Edge Company® are trademarks of Aruba Networks, Inc. All rights reserved. All other trademarks are the property of their respective owners.

Open Source CodeCertain Aruba products include Open Source software code developed by third parties, including software code subject to the GNU General Public License (“GPL”), GNU Lesser General Public License (“LGPL”), or other Open Source Licenses. The Open Source code used can be found at this site:

http://www.arubanetworks.com/open_source

Legal NoticeThe use of Aruba Networks, Inc. switching platforms and software, by all individuals or corporations, to terminate other vendors' VPN client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, Aruba Networks, Inc. from any and all legal actions that might be taken against it with respect to infringement of copyright on behalf of those vendors.

www.arubanetworks.com

1344 Crossman AvenueSunnyvale, California 94089

Phone: 408.227.4500Fax 408.227.4550

Aruba Networks, Inc. 2


Contents

Chapter 1: Introduction 9About the Aruba Virtual Branch Network 9Aruba Validated Reference Designs 9Design Validation and Testing 11Reference Documents 11

Chapter 2: Virtual Branch Theory of Operations 13Virtual Branch Network Overview 13

The Fixed Telecommuter—A One-Person Branch 13Medium and Small Branch Offices 14The Aruba Virtual Branch Network Solution 14

Understanding the Aruba Virtual Branch Network Architecture 16Components of the Architecture 16Operation of the Architecture 20

Design Considerations for Remote Networks 24Remote Networks Key Benefits 25

Chapter 3: The Network Technology Lifecycle 27The Network Technology Lifecycle 27

Chapter 4: Defining Requirements for Remote Networks 31Step 1 – Quantify Facility Requirements 31Step 2 – Quantify Device Connectivity Requirements 32Step 3 – Define RAP Equipment Requirements 36

Chapter 5: Physical Design 39Aruba Physical Architecture for Remote Networks 39

Remote Site Physical Architectures 41Data Center Physical Architecture 45

Required Equipment 46Access Points 47Local Controllers 48Master Controllers 50AirWave Appliance 52

Required Licenses 52Local Controllers 52Master Controllers 52AirWave Appliance 53

Aruba Networks, Inc. Contents | 3


3G Modem Selection 53Wide-Area Network Considerations 54

Bandwidth Constraints 54Latency Constraints 553G Wireless Constraints 55Recommendations for Minimizing Constraints 55

Regulatory Compliance for International Deployments 56Access Point Compliance 56Controller Compliance 57

Chapter 6: Logical Design 59Aruba Logical Architecture for Remote Networks 59

Fixed Telecommuter Logical Design 60Branch Office Logical Design 62Data Center Logical Design 63

Forwarding Modes 64Split-Tunnel Mode 64Tunnel Mode 66Bridge Mode 68Operating Modes 69Combined Forwarding and Operating Modes 70

AP/AM Data and Control Tunnels 71AP Tunnels 71AM Tunnels 72IP Ports Used by Aruba Devices 72Establish a Routable IP Subnet to the Master Controller 72

RAP Bootstrapping and Load Balancing 73Controller High Availability 75

Master Controller Redundancy 76Local Controller Redundancy (VRRP Layer 2 Method) 78Local Controller Redundancy (LMS-IP Layer 3 Method) 80

VLAN Design 82Choosing the Default Router 83

Chapter 7: Authentication and Security Design 85Authentication Methods (Wired and Wireless) 85

Authenticating with 802.1X 86Authenticating with Captive Portal 88MAC Address Authentication 88

Authentication Methods (Wireless Only) 89SSIDs for Secure WLANs 89



SSIDs 89

Role Derivation 90Configuring Roles for Different Users 92

Secure Role for Mobile Wireless Data Terminals 92Secure Role for Stationary Wired Devices 92Voice Handset Role 92Guest Access Role 93

Putting It All Together: Building an Authentication Design 94What Is A Profile? 94Aggregating Profiles into a Complete Configuration 96Planning AAA and SSID Profiles 97Example 802.1X Profile Configuration 98Best Practices for Profiles 99

Wireless Intrusion Detection System Operation and Design 100Detection of Rogue APs 100Classification of Rogue APs 101

Chapter 8: Deploying Aruba Remote Networks 103Aruba Deployment Process for Remote Networks 103

Step 1 – Deploy Data Center 103Step 2 – Install Pilot Sites 104Step 3 – Provision Backhaul Circuits 105Step 4 – Train the Help Desk 106Step 5 – Stage Site Equipment 107Step 6 – Execute Full Deployment 107

Recommended Provisioning Methods 108Zero Touch Provisioning 109Pre-Provisioning 109

Site Procedure for Zero Touch Method 109Pre-Installation Checklist 110Site Installation 110Provisioning the RAPs 110

Site Procedure for Pre-Provisioning Method 111Pre-Installation Checklist 111Provisioning the RAPs 111Site Selection 111Site Installation 111

Site Validation Considerations 112Cabling and RAP Validation 112Client Device Validation 112



Chapter 9: Example Configuration for the Fixed Telecommuter Scenario 113Simplified Design for the Fixed Telecommuter 113Configuring the Aruba Fixed Telecommuter Solution 116

Configure the Master Controller 116Configure Local Controllers 141Deploy RAP(s) 154

Chapter 10: Example Configuration for the Branch Office Scenario 159Simplified Design for the Branch Office 159Configuring the Aruba Branch Office Solution 162

Configure the Master Controller 162 Configure the Local Controller 175Provision and Deploy RAPs 176

Chapter 11: Reporting and Management 177Remote Management 177

Managing Both Legacy and New Network Elements 180Role-Based Management 180Planning and Location Services for Wireless Clients 182Scalability 184Trend Reporting 185Diverse WAN Environments 186

Chapter 12: Troubleshooting Remote Access Points 187Troubleshooting Categories 187Troubleshooting Zero Touch Provisioning Problems 188Troubleshooting Basic Connectivity Problems 189

Working from the RAP 189Working from the Controller 191Troubleshooting the IPsec Tunnel 192Checking the IP Address Pool and Usage 206

Troubleshooting RAP Bootstrapping Problems 207Checking the VPN Role Policies 207Checking the RAP Role Transition 208Common Problem Symptoms 210

Troubleshooting Wired Port Configuration Problems 212Checking for an Enabled Wired Port 213Checking the Port Profile 214Checking the Authentication Profile 215

Troubleshooting Split-Tunnel Mode Problems 216Is the RAP Configured in Split-Tunnel Mode? 217



Is the Split-Tunnel SSID Active on the AP? 218Does the Split-Tunnel SSID Have a GRE Tunnel with 802.1X? 218Has the Client Succeeded with 802.1X Authentication? 219Has the Client Received a DHCP IP Address from the Local LAN? 221Does Split-Tunneling Work at the Client End? 224

Troubleshooting Bridge Mode Problems 225Checking the Configured Mode 227Bridge Mode with Dynamic Encryption 227Troubleshooting Tips 229Bridge Mode with Static Encryption (Pre-Shared Key) 232

Appendix A: Forwarding Mode Feature Matrix 235

Appendix B: Provisioning Parameters for Verified USB Modems 237

Appendix C: Requirements Worksheets 239

Appendix D: Sample Configuration Files for Fixed Telecommuter Example 243Design Summary 243Annotation Conventions 244

Active-Master Configuration 245Active-Local Configuration 245

Appendix E: Aruba Contact Information 257Contacting Aruba Networks 257

Aruba Networks, Inc. | 7


Aruba Networks, Inc. | 8


Chapter 1: Introduction

Aruba Networks delivers secure enterprise networks wherever users work or roam. Our mobility solutions bring the network to you—reliably, securely, and cost-effectively—whether you work in a sales area, at home, in a branch office, or in an enterprise office. Aruba Remote Networks products facilitate data center consolidation and virtualization initiatives, providing lower operating costs. Remote Network technology brings the network to fixed or temporary remote work locations with plug-and-play simplicity—all the heavy lifting stays at the data center. Our AirWave multi-vendor management tool allows seamless management of old and new networks from a single console.

About the Aruba Virtual Branch NetworkWith the wide variety of remote locations and devices other than PCs used by today’s users IT departments find it increasingly difficult and expensive to deliver full-featured and secure network access and services to all the locations where users work. Aruba addresses the complexity, security, compliance, and management challenges of these deployments, enabling IT to cost-effectively support today's highly distributed workforce.

The Aruba Virtual Branch Network solution virtualizes the complex security, configuration, software management, and troubleshooting operations within the data center and then transparently extends those services to each branch office and teleworker. This provides the control and seamless user experience associated with dedicated network infrastructure hardware, but with the security and price point of client VPN. Remote deployments become simple for IT to set up, secure, and manage.

Aruba Validated Reference DesignsAn Aruba Validated Reference Design is a package of product selections, network decisions, configuration procedures, and deployment best practices that comprise a reference model for typical customer deployment scenarios. Each Aruba VRD has been constructed in a lab environment and thoroughly tested by Aruba engineers. By using these proven designs, customers can deploy Aruba solutions rapidly, with the assurance that they will perform and scale as expected.

Aruba Networks, Inc. Introduction | 9


Aruba publishes two types of validated reference designs, Base Designs and Incremental Designs. Figure 1 illustrates the relationship between these two types of documents in the Aruba Validated Reference Design library.

Figure 1 Aruba Validated Reference Design Library

A Base Design is a complete, end-to-end reference design for common customer scenarios. Aruba publishes the following Base Design validated reference architectures:

Campus Wireless Networks VRD: This design guide describes the best practices for implementing a large campus wireless LAN (WLAN) serving thousands of users spread across many different buildings joined by SONET, MPLS, or any other high-speed, high-availability backbone.

Retail Wireless Networks VRD: This design guide describes the best practices for implementing retail networks for merchants who want to deploy centrally managed and secure WLANs with wireless intrusion detection capability across distribution centers, warehouses, and hundreds or thousands of stores.

Virtual Branch Networks VRD (this guide): This design guide describes the best practices for implementing small remote networks serving fewer than 100 wired and wireless devices that are centrally managed and secured in a manner that replicates the simplicity and ease of use of a software VPN solution.

An Incremental Design provides an optimization or enhancement that can be applied to any Base Design. Aruba publishes the following Incremental Design validated reference architectures:

Optimizing Aruba WLANs for Roaming Devices VRD: This design guide describes best practices for implementing an Aruba 802.11 wireless network that supports thousands of highly mobile devices (HMDs) such as Wi-Fi phones, handheld scanning terminals, voice badges, and computers mounted to vehicles.

Wired Multiplexer (MUX) VRD: This design guide describes the best practices for implementing a wired network access control system that enables specific wired Ethernet ports on a customer network to benefit from Aruba role-based security features.

High Density Wireless Networks VRD: This design guide describes the best practices for implementing coverage zones with high numbers of wireless clients and access points (APs) in a relatively small geographic area such as classrooms, lecture halls and auditoriums, and in ultra-dense spaces such as financial trading floors.

RN

SG

_190

CampusWirelessNetworks

RetailWirelessNetworks

VirtualBranch

Networks

OptimizingAruba WLANsfor Roaming

Devices

WiredMultiplexer

(MUX)

High DensityWirelessNetworks

IncrementalDesigns

BaseDesigns



Design Validation and TestingThe VRD presented in this document provides best-practices architectures for two broad categories of remote network deployments:

Small or medium branch office “Fixed telecommuter” deployment for customers with hundreds or thousands of remote workers

Test cases for this Virtual Branch Networks VRD were executed against the physical architecture recommended in this Guide using a mix of client devices and interconnect methods. ArubaOS release 3.3.2.11-rn3.0 was used to conduct these tests.

Reference DocumentsThe following reference documents provide an in-depth review of the key products described in this guide.

Document Title Version

ArubaOS User Guide 3.3.2

ArubaOS CLI Guide 3.3.2

ArubaOS Release Note 3.3.2.x-rn3.0

ArubaOS Quick Start Guide 3.3.2

AMP QuickStart Guide 6.2

AMP User Guide 6.2

AMP Release Notes 6.2

RAP-5 Installation Guide n/a

RAP-5WN Installation Guide n/a

RAP-2WG Installation Guide n/a



Chapter 2: Virtual Branch Theory of Operations

Virtual Branch Network OverviewEnterprises today support the technology needs of two broad categories of remote network users. Remote users are those who work at a location other than an organization’s primary headquarters or a large regional office. One remote network category is the small branch office or retail store, typically with up to 100 employees. The other category is the “fixed telecommuter,” an individual who works from his or her home 8 hours or more a day during the workweek. A fixed telecommuter may be thought of as a “branch of one.”

Traditionally, IT organizations have used very different remote network architectures to serve each of these categories. The small branch typically utilized a branch office router to interconnect an IP subnet at the remote site to the enterprise network core. Telecommuters, who had only a single PC or laptop and limited needs, have been served with a software Virtual Private Network (VPN) client.

These solutions are no longer satisfactory. The complexity of remotely configured and managed branch office router solutions is too high. To reduce operating costs, IT needs the simplicity and centralized management offered by the VPN solution. Meanwhile, the telecommuter increasingly needs a full IT network footprint including an IP phone and wireless service with appropriate security policies. The VPN client does not meet this requirement. The requirements of each of these remote user populations are converging. A completely new remote networking architecture from Aruba Networks offers a single solution that blends the simplicity of a centralized network-based VPN with the flexibility of sophisticated role-based access control for all users at a remote site.

The Fixed Telecommuter—A One-Person Branch

Most telecommuters access the data center through a software VPN client connection via Internet Protocol Security (IPsec)/Secure Sockets Layer (SSL) protocols from remote locations. These locations can include customer offices, employee homes, and wireless LAN hotspots or anywhere that 3G wireless service is available. In these cases the VPN connection effectively “virtualizes” data center services to wherever the user is located. From the user’s perspective, the data and applications appear exactly as they would on their enterprise network. Because they are centrally managed, VPN solutions are well known for their low operating costs.

This access methodology met the requirements of enterprise users when most applications were accessed from a single PC-based device—a desktop or a laptop. The recent explosion of device types and operating systems such as VoIP phones, video conferencing terminals, and smartphones with enterprise applications renders the VPN solution incompatible. In addition to the growth of the number of devices for a single user, there is also a growing need for distributed, temporary, and mobile business offices. In all of these remote settings, it is more important than ever to equip distributed workers with the same productivity tools as their LAN or WLAN-connected counterparts.

Aruba Networks, Inc. Virtual Branch Theory of Operations | 13


Medium and Small Branch Offices

Historically, most branch offices have received less-sophisticated and lower-performance network technology and IT services than enterprise core network workers. Paradoxically, the configuration and management costs are much higher as a whole for remote sites. Three reasons for this cost elevation are:

1. The networks servicing these remote environments are tethered to a WAN, which—until recently—has been inherently slower and more latency-prone than local area networks.

2. This slow WAN performance drove a network architecture employing discrete IP subnetworks at each branch office. This architecture in turn created a requirement for a scaled-down site router, firewall, and other network elements, which router manufacturers are only too happy to reinforce.

3. Remote work environments have evolved incrementally during periodic field technology refreshes. As a result, they contain inconsistent equipment and service sets across many locations.

These factors add a layer of complexity for new services deployment, particularly in organizations without IT staff to service remote workers. Evolving business conditions make it necessary to elevate remote workers’ network experience to be equivalent to that of employees connected directly to the enterprise core LAN.

Existing network infrastructure vendors have often taken the approach of attempting to retrofit the existing network infrastructure equipment and downscale it for these small branch offices and home offices. This practice leads to an architecture in which a new network is created for every new location and connected back to the enterprise core network. These new networks then replicate all network services that have already been created in the core network for every remote location. This replication tends to include routing, switching, firewalls, and other security services. These remote networks are then inter-connected using various WAN technologies—including frame relay, MPLS, and dedicated circuits. Network administrators are faced with the increased costs and complexities of deploying, operating, and maintaining these networks and their complicated interconnections.

The Aruba Virtual Branch Network Solution

The Aruba virtual branch network (VBN) architecture paradigm focuses on maintaining the simplicity and ease of a software VPN solution while delivering full IP network services to multi-device/user offices. This paradigm leverages two technologies for which Aruba is well known:

Secure Data Tunnels: In this architecture, a remote access point (RAP) provides similar functionality to a VPN client but allows for shared access to multiple devices through wired and wireless LAN interfaces. The controller acts in an analogous manner to a VPN concentrator. Each RAP communicates with the controller over one or more secure, encrypted IPsec VPN tunnels. This communication provides access to the devices/users connecting through the RAPs to the enterprise core network and to the applications and services that exist there.

Role-Based Access Control (RBAC): The Aruba controller has an integrated, ICSA-certified stateful firewall capable of up to 20 Gbps (cleartext) or 8 Gbps (encrypted) performance. Each RAP also includes the same firewall functionality. With the firewall, each user is assigned a “role” with associated policies. Policies follow the wired or wireless user and are centrally managed for simplicity. Deep packet inspection makes sure that roles are strictly enforced on a per-packet, per-flow basis. Devices violating a policy are automatically blacklisted.



The Aruba secure data tunnel and RBAC technologies work together to deliver the VBN experience, as shown in a logical diagram in Figure 2:

Figure 2 Virtual Branch Network and Role-Based Access Control

This architecture shatters the cost and complexity barriers that exist today in establishing new remote offices for multiple devices and users, providing businesses with the following advantages:

Greater flexibility and agility in business operations Lower total cost of ownership to establish new branch offices Justification for a “branch of one,” making “work from home” initiatives viable Ability to embrace “going green” by supporting initiatives that allow employees to work from

home

RN

SG

_066

Internet or WAN Firewall/NAT-T

Controller

Voice

Voice

Enterprise

Remote AccessPoint

VLAN B

VLAN C

VLAN A

EnterpriseNetwork

InternetServices

SplitTunnel

Enterprise LAN

Branch Office /Telecommuter Home

Guest / Family

Guest /Family

Bridge VLAN



Understanding the Aruba Virtual Branch Network Architecture

Components of the Architecture

The Aruba Virtual Branch Network architecture consists of the following logical components: Remote Access Point (RAP): Aruba RAPs serve as on-ramps to aggregate user traffic onto the

enterprise LAN and direct this traffic to Aruba controllers. When provisioned as a RAP, APs extend the enterprise LAN to any remote location by enabling seamless wired or wireless data and voice wherever a user finds an Internet enabled Ethernet port or 3G cellular connection. RAPs are ideally suited for small to medium remote offices, home offices, telecommuters, mobile executives, and for business continuity applications. The major modules of the RAP are shown in Figure 3.

Figure 3 RAP Modules

VPN client: Included with the RAP software license, this feature provides VPN client capability to securely communicate with the VPN server located in the local controller on the enterprise DMZ.

PEF (Policy Enforcement Firewall): Provides a stateful policy enforcement firewall for restricting access to enterprise core network resources. A role-based access rights policy is configured on the controller and then applied upon completion of RAP authentication and establishment of an IPsec connection. This policy contains control traffic protocol, traffic type within GRE tunnels, the types of traffic permitted from the RAP to the controller (L2TP, TFTP, FTP, for example), and NTP and syslog protocol and ports.

Wireless LAN interface(s): Provide Wi-Fi enterprise features supporting single and dual radio 802.11 b/g, 802.11 b/g/n, 802.11 a/b/g, and 802.11 a/b/g/n, depending on model selection.

Wired LAN interface(s): Provide Network Access Control (NAC) capable 10/100 Mbps or 100/1000 Mbps RJ-45 Ethernet ports, depending on model selection.

RN

SG

_064

To Controller

VPNClient

USB Modem

LAN

Internet

Ethernet

SecuredWired“NAC”

EnterpriseWi-Fi

& WIPSLAN

DynamicRole

Assignment

Internet

Enterprise

LAN

Internet

EnterprisePEF

(Per-User StatefulPolicy Forwarding)

Enterprise



WAN Interface(s): Provide wide-area connectivity including EVDO/HSDPA 3G USB modems or Ethernet, depending on model selection.

Controller: Aruba Networks high-performance controllers are built specifically to scale ArubaOS software module capabilities for enterprise networks of all sizes. All Aruba controllers share a common hardware architecture that includes a dedicated control processor, a high-performance programmable network processor unit, and a unique programmable encryption engine. Controllers aggregate network traffic from APs, process it using Aruba software, and deliver it to the network.The controller resides in the data center or the DMZ, depending on the network design. RAPs connect to the controller using secure tunnels. The data is transmitted from the remote locations to the enterprise LAN through these secure tunnels. After the controller receives the data, it processes it and routes the data into the core network. In other words, the controller is the “gateway to the enterprise LAN” for the remote users and devices connecting to the RAP. The major modules within the controller are shown in Figure 4.

Figure 4 Controller Modules

VPN server: Included with the RAP software license, this feature provides VPN server functionality to communicate with RAP VPN clients. The Aruba controller must have VPN server functionality configured to terminate the secure RAPs. The configuration consists of authentication protocols, an address pool for RAPs, DNS information, shared secret for RAPs, and a policy governing the shared secret including priority, encryption, hash algorithm, authentication, group and life time.

RN

SG

_065

To EnterpriseNetworkTo RAPs

Mobility Controller

EncryptionAuthentication

Rich Networking

QoS Redundancy

Management

Integrate with NetworkVRRP for ControllerHigh Availability

RADIUS / Active Directory / LDAP

PEF(Policy

EnforcementFirewall)

VPNServer Central

Wireless& WIPS

CentralWireless &Wired NAC

Policy Definitionand

System Management



PEF (Policy Enforcement Firewall): Aruba is currently the only vendor to integrate an ICSA-certified stateful firewall into its wireless LAN, ensuring that parameters such as security, suitability for a task, default configuration, and logging/audit trails have been validated.

Authentication/Encryption modules: Work with the PEF module to authenticate users and enforce roles. Provide an internal authentication (AAA) server that is enabled by default on each controller; external authentication can be configured for enterprise authentication servers (RADIUS, Active Directory—AD or Lightweight Directory Access Protocol—LDAP). The encryption module supports WEP, dynamic WEP, TKIP, WPA, WPA-2, DES, 3DES, AES-CCMP, AES-CBC, EAP, PEAP, TLS, TTLS, LEAP, EAP-FAST, and xSec-L2 AES.ArubaOS uniquely supports AAA FastConnect™, which allows the encrypted portions of 802.1X authentication exchanges to be terminated on the controller where the Aruba hardware encryption engine dramatically increases scalability and performance. Supported for PEAP-MSCHAPv2, PEAP-GTC, and EAP-TLS, AAA FastConnect™ removes the requirement for external authentication servers to be 802.1X-capable and minimizes authentication latency, which is advantageous when leveraging centralized AAA infrastructure for remote network deployments.

Centralized Wired NAC services: Provides centralized secure-jack capability for tunneling of wired Ethernet traffic.

Redundancy: To scale to large networks where multiple controllers are required, Aruba supports the concept of a master controller-local controller cluster hierarchy among controllers. This hierarchy allows the administrators to use the master controller as the central point of all policy configurations while the local controllers are used to scale the “data plane” by terminating active connections from RAPs and users.

AirWave Management Platform (AMP): The AMP is a management server that provides highly scalable and centralized total solution management. This multi-vendor management tool can monitor some versions of branch office routers, wired switches, and other devices. An AMP implementation provides IT administrators full visibility into the remote networks—including users, activity, and helpdesk operations.

Role-Based Security

Aruba customers use a role-based security model that facilitates extending a trusted IP footprint into a home or branch office.

The Aruba controller authenticates a user or device, rather than the port or VLAN. For wired users, multiple profiles and roles can be configured for a single port so that user/device security granularity is provided.

For wireless devices, role-based security generally begins by offering several Service Set Identifiers (SSIDs) simultaneously from the same AP. Each SSID has its own authentication and encryption settings based on the capabilities of the clients and the services that each client needs.



A typical fixed telecommuter home has three wireless SSIDs available for association via the RAP (Figure 5):

Enterprise, for the employee’s PC and data devices Family, for non-employee users and devices to route directly to the Internet using specific

protocols (for example, HTTP, HTTPS), and to access local family resources such as servers and printers

Voice, for enterprise voice devices, which receive a restricted role

Figure 5 Fixed Telecommuter SSIDs

A typical branch office will also have four SSIDs. The Family SSID is replaced with a Guest SSID, which can utilize a Captive Portal feature to direct guests to a log-in page that is user name and/or password protected. A pre-shared key SSID is added for legacy devices that are not capable of modern encryption methods.

Figure 6 Branch Office SSIDs

EnterpriseSSID Family/Guest

SSID

RN

SG

_145

Voice/VideoSSID

High SecuritySSID

Pre-Shared KeySSID

GuestSSID

RN

SG

_144

Voice/VideoSSID



For detailed examples of both the fixed telecommuter scenario and the branch office scenario, refer to Chapter 6: Logical Design on page 59.

All users connect to the RAP and authenticate with the RADIUS server that already exists in the network. The stateful firewalls in the controller and RAPs enforce the role and policy associated with each user and device. Users are only able to access those resources they have permissions for, and only after they have successfully authenticated to the network.

Operation of the Architecture

To understand the mechanisms employed in branch network virtualization, the following steps explain how a RAP connects to a controller and then how users and devices connect to the enterprise LAN through the RAP.

Connection Establishment

In this architecture, the RAP, using any of four standard discovery mechanisms (Aruba Discovery Protocol-ADP, Domain Name Service-DNS, Dynamic Host Configuration Protocol-DHCP, or statically configured IP or host name), initiates an IPsec connection to the controller over any public or private IP network. This connection is analogous to the VPN connection initiated by a VPN client on a laptop or desktop to a VPN concentrator. However, in the case of a RAP, there is no single user to be authenticated. Instead, the RAP itself is authenticated on the controller—either by using a pre-provisioned user name and password on the RAP or by using certificates that are installed on the RAP.

Bootstrap Protocol Between Controller and RAP

A key difference between the Aruba virtual branch network (VBN) solution and branch router networks is that all configuration is centralized and uploaded to the RAP in real time. No remote configuration is required. After RAP authentication is completed by the controller and the IPsec tunnel has been established, all communication between the controller and the RAP occurs through this secure channel. This encrypted tunnel is now used to upgrade the image on the RAP (if there is an image mismatch with the controller image version) and then to push the RAP configuration from the controller to the RAP. This configuration includes all security settings, firewall roles and policies, wired port policies, and wireless LAN policies. This process is referred to as “bootstrapping” the RAP in this architecture. For more information about this process, refer to Chapter 6: Logical Design on page 59.

Network Access Control

Once the RAP has successfully bootstrapped to a controller, the RAP applies the configuration it has received to the wired ports and wireless interfaces. Users and devices can now connect to the wired ports and wireless SSIDs as provided for in the bootstrapped policies.

Administrators can control the exact access provided to the users and devices through these ports and SSIDs by using authentication mechanisms such as 802.1X or MAC address authentication. Using WPA or WPA2 on wireless SSIDs also provides an additional level of security by encrypting all frames in the wireless medium.



When 802.1X authentication is used to authenticate wired or wireless users, the authentication frames are sent through the IPsec tunnel to the controller, which then authenticates and authorizes the user/device credentials by using RADIUS or LDAP protocols to communicate to the existing AAA server infrastructure. Depending on the result of the authentication the user/device is placed in the appropriate “user role.” Aruba enforces the principle of least privilege by identifying users or devices, placing them into separated roles, and permitting or denying access to network resources or protocols based on those roles. The user role is mapped to a series of firewall policies that define the network access that the user is provided.

For detailed information about network access control, refer to Chapter 7: Authentication and Security Design on page 85.

Figure 7 802.1X Authentication Handshake

IP Routing

The IP address management and routing design for the RAP solution is one of the major differentiators from a traditional branch office solution. Similar to the manner in which a VPN client is “assigned” an IP address from an enterprise pool by the VPN concentrator, all enterprise users connecting to a RAP may be assigned IP addresses from the controller. This mechanism extends the simple IP routing model of a software VPN solution to the virtual branch network, making the client device connecting to a RAP a part of the enterprise LAN. Guest or family devices are assigned an IP address from a local address pool on the RAP.

This design is in contrast to a branch office router model that uses separate IP subnets for every branch office network and then interconnects these subnets to the enterprise LAN for access to business applications and data. This traditional model introduces a set of issues that includes:

Complicated VPN routing protocols Complicated IP address management Application issues related to going through NAT (for example, VoIP) Requirement for special protocols for enabling multicast over these connections

RN

SG

_057

Associate

Associate response

EAP request identity

EAP response

EAP exchange

RAPStation

802.11 Association 802.1X Authentication 4-way Handshake

Key1

Key2

Key3

Key4



The Aruba virtual branch network architecture avoids all these concerns and provides centrally managed enterprise LAN application functionality, thereby reducing the cost and complexity of deploying and managing branch and home offices.

Firewall

The firewall service in the RAP provides flexible policy-based forwarding access control list (ACL) for split-tunnel forwarding mode. Split-tunnel is the recommended and the most flexible mode for interconnecting RAPs with their local controller. The benefits of split-tunnel mode include:

Enterprise traffic is tunneled to the controller over an encrypted IPsec tunnel. The IPsec tunnel is trusted and shared by all wireless Virtual APs (VAPs) and wired ports. All other traffic is locally source routed (NATed) and forwarded on wired uplink and downlink

ports according to user roles and session ACLs.

The RAP firewall implementation also provides a bridge forwarding mode that restricts local traffic locally but permits split-tunnel users access to selected resources. Access and trunk modes are supported on RAP wired ports.

For remote voice applications, minimizing latency is critical. A low latency tunnel forwarding mode is supported where all traffic is tunneled to the enterprise network. For this forwarding mode, wireless encryption is performed on the wireless client as usual and these encrypted frames are sent directly to the local controller, where decryption is performed and forwarding policies are applied. This feature is also of value to customers who have a compliance requirement to see all traffic from their employees. Refer to Chapter 7: Authentication and Security Design on page 85 for detailed information about these features,

Redundancy

The Aruba virtual branch network architecture was designed from the ground up for high availability. Redundancy may be configured at either the controller or the Remote Access Point or both. Controller redundancy is achieved through standards-based Virtual Router Redundancy Protocol (VRRP) in which controllers share a virtual IP address so that planned and unplanned outages are transparent to remote users. RAP redundancy is achieved by configuring both an active and a standby master controller IP address during the provisioning process. If for any reason the active master becomes unreachable, the RAP can automatically failover to the standby master.

These configuration options provide network administrators with significant flexibility to design virtual branch networks that leverage existing data center and WAN investments while fitting within available budgets. From simple RAP failover between two standalone controllers at a single data center, to fully redundant controller pairs at geographically diverse data centers, Aruba enables customers to meet high service level expectations. Redundancy is considered fully in Chapter 6: Logical Design on page 59.

Scaling to Multiple Controllers

For RAPs operated as a production IT service that must meet uptime and availability Service Level Agreements (SLAs), there may be a requirement to deploy more than one controller to accept the RAP connections. Aruba supports “clustering” controllers using the “master/local” concept.

In a master/local design, one of the controllers is configured to be the “master” controller. This controller is responsible for providing centralized configuration and coordination for the entire network.



The “local” controller is the aggregation point where RAP tunnels terminate, and where security policies are applied. All global settings (such as authentication profiles, firewall policies, and WLAN policies) can be configured on the master controller. These settings are then automatically propagated to all the local controllers. Aruba supports full 1+1 redundancy via VRRP for both the master and the local controller levels.

The master controller can be viewed as the “control and management plane” of the network. RAPs initially connect to the master controller and receive their configuration as described above. The local controllers can be viewed as the “data plane” of the network, where the policies are actually applied and all user traffic flows through these controllers.

Designing large-scale networks using these concepts is explained further in Chapter 6: Logical Design on page 59.

Licensing and Software Updates

One of the ways that Aruba reduces the IT labor requirement associated with managing remote networks is by centralizing licensing and software updates for all branch locations at the controller. As we have seen, traditional branch network solutions create mini-enterprise networks at each location with separate routing, firewall, VPN and other equipment. Many of these devices must have software licenses installed. Also, their operating software must be kept up to date, which can require careful planning and consume significant IT resources.

The Aruba virtual branch network architecture eliminates these requirements by overlaying the enterprise network securely across the WAN, managed by controllers located in the data center. Software license keys are installed only on the controllers, and the controller automatically upgrades RAPs any time they authenticate to the network if a code change has taken place. Remote Access Point licenses can be purchased in increments from 1 through 512, and there is no need to purchase more than are needed. Additional remote sites can be added at any time. Choosing the right software licenses is addressed in Chapter 5: Physical Design on page 39.

Deployment

The virtual branch network architecture dramatically reduces deployment costs through its Zero Touch provisioning capability. Provisioning refers to the process of programming the APs to find their controller and optionally assigning their physical location on an electronic floor plan in order to show real-time heat maps on a controller.

The Aruba RAP-5, RAP-5WN, and RAP-2WG products are preloaded with a unique security certificate at the factory. When combined with the 3000-series standalone controller or the M3-series blade that also include a factory-installed certificate, a low-cost provisioning model becomes possible. This model is particularly attractive for telecommuter deployments.

Aruba calls this feature zero touch provisioning, meaning that the IT organization simply pre-programs the MAC address of each authorized RAP into a white list on the master controller before shipping it to the end user. The IT professional can do this without having to plug the AP into the controller, and the AP remains in its packaging untouched. Once received at the site, the end user simply enters the IP address/hostname of the local controller into the provisioning screen on the RAP. The RAP exchanges keys automatically with the controller and completes the provisioning process with no further manual intervention.

For customers who prefer to stage equipment in advance, Aruba supports a pre-provisioning model. Pre-provisioning refers to the process of staging the APs before they arrive at a site. This staging is



most often done when an IT team or system integrator will be traveling to each location to install or refresh multiple pieces of equipment, and it is not possible or not desirable for site employees to perform IT tasks themselves. With pre-provisioning, a staging center is required to prepare equipment to be delivered to the remote locations. The Aruba RAPs are unpacked, configured, and verified at the staging center prior to final delivery. The staging center should have secure LAN connectivity to the data center where the controllers are housed so that RAPs can connect to the controller.

The choice of deployment methodology is generally determined by two factors: the cost to send installers onsite, and whether the end user can or should be expected to perform a few simple tasks to activate an Aruba RAP. For detailed information on deploying an Aruba virtual branch network, see Chapter 8: Deploying Aruba Remote Networks on page 103.

Design Considerations for Remote NetworksThe following are general considerations when designing an Aruba virtual branch network for scenarios discussed in this chapter. Typically in a branch office environment, the majority of devices will be enterprise owned. These may include:

Employee wireless laptops Wired and wireless VoIP phones Employee wired desktops and servers Handheld scanning terminals Shared wired and wireless printers Local application server and network attached storage (NAS)

In the telecommuter home environment, in addition to the employee laptop and desktop and wired and wireless VoIP phone, there may be:

Wired family desktops Wireless family laptops Family multimedia devices (XBox, Media Center, TiVo, for example) Shared wired and wireless printers Shared wired and wireless network attached storage (NAS)

Planning appropriate connectivity and security for these devices is easily accomplished with inventory design worksheets and example configurations, the details of which are covered in subsequent chapters.

VLANs and IP Addressing

For both the fixed telecommuter and branch office solutions presented in this VRD, the following IP, VLAN, and routing configurations are implemented:

A single VLAN can be configured for wired and wireless access. Separate VLANs are configured for enterprise access and for family and guest access. A separate VLAN is configured for enterprise voice access. For enterprise users and devices, IP addresses are obtained from the enterprise DHCP server

regardless of the device type (wired or wireless) or the tunnel forwarding mode configuration.



For family and guest users and devices, IP addresses are obtained from the DHCP service provided locally by the RAP.

For the fixed telecommuter solution, enterprise users are permitted unidirectional access to local family devices such as printers via policy settings pushed down to the RAP.

Remote Networks Key BenefitsIn summary, the Aruba virtual branch network architecture centralizes access control, authentication, encryption, and management, thereby simplifying network management and enhancing security while providing remote workers and their multiple network devices with access to centralized services. Key features of this architecture include:

Operational simplicity. The RAP provides a similar functionality to a software VPN client but allows for shared access to multiple devices through standard wired and wireless Ethernet interfaces. The centralized controller acts in an analogous manner to a VPN concentrator for multiple RAPs and provides access to the devices/users connecting through the RAPs to the enterprise network and to the applications and services that exist there.

Flexibility and agility. The unique combination of security mechanisms and Aruba Role-Based Access Control (RBAC) gives an Aruba Remote Network far greater granularity of control over wired and wireless user traffic than traditional port-based approaches.

Scalability. The Aruba remote network architecture accommodates the needs of a single teleworker all the way up to a medium size branch office. This solution offers flexible configurations and price points that meet the needs of remote networks regardless of size, while delivering high-performance throughput and transparent enterprise application access.

Low total cost of ownership. The Aruba Remote Network architecture requires just one device at the remote location to service many remote devices/users, allowing the organization to reduce the IT footprint and associated management cost for each remote location.



Chapter 3: The Network Technology Lifecycle

Successive generations of wired and wireless voice and data communications systems have been deployed by a wide variety of organizations over many years. Early generations of Ethernet LANs used coaxial cable, which subsequently gave way to layer 1 (L1) hubs for aggregating wired ports over standard inside wiring. The development of Ethernet switches greatly reduced forwarding latency and the processing load on the network device. Switching also provided the capability for collision domain segmentation into Virtual LANs (VLANs). VLANs have since become the cure-all for moves, adds, and changes as well as providing segmentation in an otherwise flat network.

In a similar way, early generations of WLANs used autonomous or “fat” access points (APs) with Frequency-Hopping Spread Spectrum (FHSS) or Direct Sequence Spread Spectrum (DSSS) radios. Until very recently, deployments were based on 802.11a/b/g technology. The current widespread rollout of the latest 802.11n technology is being driven by its capacity to deliver wire-speed performance and increased reliability.

With a new generation of remote access points (RAPs) supporting combined wired and wireless connectivity for small branch offices and employee homes, Aruba is poised once again to deploy a new wave of technology that promises to reduce costs and improve efficiencies for remote networking environments.

The Network Technology LifecycleThe lifecycle of an enterprise network typically moves through four distinct phases over a period of 4 to 5 years. The organization of this guide’s contents follows this lifecycle, beginning with the Define phase and moving sequentially through the Design, Deploy, and Operate phases.

Figure 8 Network Technology Lifecycle

RN

SG

_110

Define

Deploy

Design

Operate

Aruba Networks, Inc. The Network Technology Lifecycle | 27


Each new evolution of the lifecycle begins by defining the objectives, requirements, and constraints facing the organization. The Define phase may also include pre-deployment wired/wireless site surveys.

The requirements definition process addresses the broad project-level, infrastructure-level, and application-level drivers and dependencies for the network. Common examples (explored in depth in Chapter 4: Defining Requirements for Remote Networks on page 31) include:

Remote site types, locations, and regulatory domains WAN backhaul speeds, latencies, and redundancy options User populations, authentication modes and device types Quantification of key design or scale parameters Financial, technical, and scheduling design constraints

Centralized controller-based remote network architectures offer significant security, self-healing, performance, and flexibility advantages. They also offer vital automation features that greatly reduce the workload for shorthanded IT organizations. These capabilities require new types of design and architectural

decisions that are different from legacy branch router or software VPN solutions.

Aruba recommends segmenting the Design phase for a remote network into the following parts, each of which is described in a separate chapter in this guide:

Physical Network Design. In a RAP architecture, controllers and APs work together as a system that is overlaid on the existing wired LAN and WAN infrastructure. The network architect must choose where to physically locate controllers and APs within that infrastructure, identify the equipment and software licenses required, perform capacity planning for controllers and WAN links, and make sure that optional AP radios comply with local laws. For more information, see Chapter 5: Physical Design on page 39.

Logical Network Design. The network architect must determine how the network endpoints will communicate logically at layer 2 (L2) and layer 3 (L3), choose how to configure controller and AP redundancy, and complete a VLAN design. For more information, see Chapter 6: Logical Design on page 59.

Authentication and Security Design. The network architect must determine how to integrate the centralized controller with the existing Authentication, Authorization, and Accounting (AAA) infrastructure. He or she must also decide how to detect, classify, and potentially contain unauthorized or ‘rogue’ devices in both the wired and wireless spaces. For more information, see Chapter 7: Authentication and Security Design on page 85.

Large organizations face deployment challenges when migrating network technology and refreshing network software. Hundreds or thousands of locations must be accommodated, typically in narrow pre-scheduled time windows, sometimes by remote technicians with limited IT skills, and usually at the lowest possible cost. Project management and logistics excellence are required.

Aruba offers system administrators a choice of provisioning methods specifically designed to enable customers to successfully undertake rollouts with thousands of remote locations. The choice of method is driven by the number of locations, geography, and WAN link characteristics of each site. For



detailed information about deployment methods, refer to Chapter 8: Deploying Aruba Remote Networks on page 103.

To reduce the workload of network administrators who must manage far-flung equipment and respond promptly to alerts and notifications, the Aruba controller-based architecture is able to independently manage all authenticated wired and wireless devices, user sessions, and roaming states. When the Aruba WIP module is deployed, the controllers will automatically blacklist rogue devices. If the RAPs

include optional radios, Aruba provides for automated dynamic RF management of settings for wireless devices and users.

Rapid resolution of remote user and device issues is a basic function of any IT support desk. Support personnel must obtain actionable information about the health of specific client device connections in order to resolve problems. Long-term trending is necessary for accurate capacity planning. The Aruba Remote Networks architecture provides the tools required for supporting short-term troubleshooting and long-term trend analysis.

Finally, automated operational and compliance reporting is a key requirement for many organizations because their IT groups must support large numbers of users and devices with very limited personnel. Remote networking potentially increases site counts by an order of magnitude. The AirWave Wireless Management Suite offers powerful centralized reporting, management, and forensic tools that enable customers to support tens of thousands of RAP locations. See Chapter 11: Reporting and Management on page 177 for a discussion of AirWave capabilities. See Chapter 12: Troubleshooting Remote Access Points on page 187 for detailed information about troubleshooting a remote network deployment.



Chapter 4: Defining Requirements for Remote Networks

This chapter presents a three-step process that can be used by organizations to define the business and technical requirements that drive the design and rollout of an Aruba remote network solution. The information gathered in the Define phase will be used in subsequent chapters to successfully design and deploy the remote network solution.

Step 1 – Quantify Facility RequirementsBegin by determining what kind of remote sites will be served by the deployment. To generate the equipment bill of materials, you need to know the number, location, and type of facilities that will be covered.

Remote Network facility types fall roughly into these categories: Fixed telecommuters Remote call center agents Medium branch offices and stores Small branch offices and stores

Some organizations may have only one type of remote site, while others may have all of these. In addition, global organizations may vary their site types and distributions on a country-by-country basis. For each facility type, answer the following questions:

How many of each type of facility exists? In how many separate country and regulatory domains does this facility type exist? Is guest access required? How many wired devices need to be supported at each facility? What is the minimum and maximum WAN backhaul link speed for each facility type? What WAN technologies (for example, frame relay, point-to-point, and VSAT) are in use for each

facility type? What is the associated WAN link latency for each link type?

In addition, you must plan which of two possible provisioning methods will be used—Zero touch provisioning or pre-provisioning. With zero touch provisioning, the MAC address of the RAP is entered on a whitelist on the controller. The RAP is drop-shipped directly to the user, who installs the RAP and initiates an automatic provisioning process using the web GUI. With pre-provisioning, the RAP is connected to a controller at a staging site and programmed with required provisioning parameters. It is then shipped “ready to go” to the installation site. For more information about selecting a provisioning

Aruba Networks, Inc. Defining Requirements for Remote Networks | 31


method, refer to Recommended Provisioning Methods on page 108. Be sure to plan for anticipated usage four or five years into the future, and not just for today’s requirements. These requirements apply both to the number of individual sites and to the number of devices at each one. Construct a worksheet similar to the following sample to capture the answers to these questions.

This information is used to construct the logical and physical architecture discussed in Chapter 5: Physical Design on page 39 and in , “Logical Design” on page 59. This information is also used to plan the logistics of the deployment covered in Chapter 8: Deploying Aruba Remote Networks on page 103.

Step 2 – Quantify Device Connectivity RequirementsCompleting an inventory of present and future applications and the devices on which those applications run is the second step in the planning process. The inventory assists you in properly forecasting device populations and RAP hardware capabilities, and in developing the network design.

Table 1 Facility Inventory Worksheet Example

Facility Type

Usage Requirements WAN Link Requirements Provisioning

Site Count

Max Devices per Site

Guests Family Existing or New Link Type Speed Latency Provisioning

Method

Fixed Telecommuters

USA 100 20 n/a Yes Existing Cable 2 Mbps < 25 ms Zero Touch

Canada 50 20 n/a Yes New DSL 1 Mbps < 25 ms Zero Touch

Mexico 20 20 n/a No New DSL 768 Kbps < 25 ms Zero Touch

Remote Call Center Agents

USA 10 2 n/a No New DSL 2 Mbps < 25 ms Zero Touch

Canada 2 2 n/a No New DSL 1 Mbps < 25 ms Zero Touch

Mexico 2 2 n/a No New DSL 768 Kbps < 25 ms Zero Touch

Small Branch Offices

USA 302 10 No n/a Existing Frame 256 Kbps < 50 ms Pre-Provision

Canada 47 5 No n/a New Frame 256 Kbps < 50 ms Pre-Provision

Mexico 22 5 No n/a New 3G 512 Kbps < 100 ms Pre-Provision

Medium Branch Offices

USA 56 35 Yes n/a Existing Frame 768 Kbps < 25 ms Pre-Provision

Canada 21 15 Yes n/a Existing Frame 768 Kbps < 25 ms Pre-Provision

Mexico 11 15 Yes n/a Existing Frame 768 Kbps < 25 ms Pre-Provision



For each facility or site type, complete a worksheet that captures all current and future networked application use. Use the following example application summaries as a tool to facilitate planning meetings between IT, department managers, and executive management.

For each application and device identified, estimate the average number of users in each location today, as well as several years into the future.

Note whether each device is wired or wireless, along with the relevant interfaces. All RAPs have the ability to broadcast multiple virtual Service Set Identifiers (SSIDs) from a single physical AP. Each SSID may have different encryption and traffic flow (forwarding mode) settings. In addition to wireless devices, Aruba RAPs support wired devices for which specific profiles and user roles can be created and applied, providing a uniform, managed, and secure remote network solution for branch offices and fixed telecommuter implementations.

Define the different authentication modes by interface and device type required in the remote location. Choose the strongest authentication supported by the device class. For wireless devices, SSIDs can be used to further segment devices based on security requirements: A high security SSID (WPA2/802.1X) for employees with individual login IDs and devices

such as PDAs. This requires an external AAA server to integrate with the Aruba controller. A voice SSID (WPA/WPA2 with PSK) to support voice handsets optimized for QoS and

battery conservation. In branch offices, a guest SSID (captive portal authentication with no encryption) for vendors or

customers to access the Internet. This SSID has explicit firewall access control lists (ACLs) applied to limit access to unauthorized networks and has bandwidth contracts to limit airtime usage.

In fixed telecommuter homes, a family SSID (WPA/WPA2 with Pre-shared Key).

The following examples show the user authentication and device type requirements for a generic medium branch office and a fixed telecommuter site to help you determine your particular requirements. Aruba recommends completing worksheets separately for each category of branch office and fixed telecommuter site.



For detailed information about the different forwarding modes and their respective benefits and limitations, refer to , “Logical Design” on page 59.

Table 2 Site Template Example—Medium Branch Office

Forecast Connection Method Logical & Security Design

DescriptionMax

Devices (Today)

Max Devices(5 Years)

Wired

Wireless

Interface Auth Mode

Forwarding Mode

Operating Mode

DHCP Source2.4

GHz 5 GHz

Enterprise Devices

Local Server 1 1 X fe/2 MAC Bridge Always RAP

Local Printer 2 2 X fe/1 (L2 switch)

MAC Bridge Always RAP

Wired POS* 5 1 X fe/1 (L2 switch)

MAC Bridge Always RAP

Voice Handset

1 5 X Voice SSID MAC Tunnel n/a Enterprise

Scan Terminal

3 9 X Pre-shared Key SSID

PSK Bridge Always RAP

Manager Laptop

1 2 X High Security

SSID

802.1X Split-Tunnel n/a Enterprise

Guest Devices

Wired PCs 2 5 X fe/3(L2 switch)

Captive Portal

Split-Tunnel n/a Enterprise

Wireless Laptops

2 10 X X Guest SSID Captive Portal

Split-Tunnel n/a Enterprise

Total Devices

17 35

*Over time, wired devices transition to wireless.



The following is an example of an application worksheet for the fixed telecommuter site.

Table 3 Site Template Example— Fixed Telecommuter


DescriptionMax

Devices (Today)

Max Device

(5 years)Wired

Wireless

Interface Auth Mode

Forwarding Mode

OperatingMode

DHCP Source2.4

GHz 5 GHz

Enterprise Devices

Wired PCs* 1 0 X fe/1 802.1X Split-Tunnel n/a Enterprise

Wired IP Phone

1 0 X fe/2 MAC Tunnel n/a Enterprise

Employee Laptop

0 1 X Enterprise SSID

802.1X Split-Tunnel n/a Enterprise

Voice Handset

0 1 X Voice SSID MAC Tunnel n/a Enterprise

Family Devices

Shared Printers

1 3 X fe/3 (L2 switch)

Open Bridge Always RAP

Wired Devices

2 5 X fe/3 (L2 switch)


Wireless Devices

2 10 X X Family SSID


Total Devices

7 20

*Over time, wired devices transition to wireless.



Step 3 – Define RAP Equipment RequirementsWith completed templates for each type of remote facility, the final step is to itemize the hardware and software requirements for each one. This information is needed in order to select the best RAP model. In most cases, the same model will be used for all sites in a given category in order to keep management as simple as possible. Sometimes, it is desirable to deploy different RAP models for different user classes. For example, if wireless is not supported at a given location, it may be more economical to deploy APs that do not include radios but support the number of wired ports required.

Construct a table similar to the one in Table 4 on page 37 to capture these items.

In determining the model of AP that is required for each site, consider the following important factors: Are any wired devices to be supported at the site?

The RAPs can support layer 1 (L1) hubs downstream The RAPs can support a PC downstream connected to a wired IP phone (802.1Q trunk)

Does the site require support for wireless devices? Which bands need to be supported (2.4 GHz or 5 GHz or both)?

Follow the decision tree in Figure 9 to select the optimal AP model for each class of remote site.

Figure 9 RAP Selection Decision Tree

RN

SG

_155

SelectPower Supply

(US, EU orROW)

SelectRAP-2WG

SelectPower Supply(US or ROW)

SelectRAP-5WN

SelectAP-125

SelectPower Supply(US or ROW)

SelectRAP-5

YesStart

Yes

Yes

Yes

No

No

No

No

IsWireless

Required?

IsDual-RadioRequired?

Is802.11n

Required?

Over 5Users Per

AP?



Table 4 RAP Requirements Worksheet Example

Facility Type Local Wired Ports

USB Required

Wireless Required

Radio Regulatory

Domain

AP Model(with

Power Supply)

WIPS Required


USA 3 No Yes USA RAP-5WN-US Yes

Canada 3 No Yes Canada RAP-5WN Yes

Mexico 3 No Yes Mexico RAP-5WN Yes


USA 3 No No n/a RAP-5-US No

Canada 3 No No n/a RAP-5 No

Mexico 3 Yes No n/a RAP-5 No

Fixed Telecommuter

USA 3 No Yes USA RAP-5WN-US No

Canada 3 No Yes Canada RAP-5WN No

Mexico 3 No Yes Mexico RAP-5WN No


USA 1 No No n/a RAP-2WG-US No

Canada 1 No No n/a RAP-2WG No

Mexico 1 No No n/a RAP-2WG No



Chapter 5: Physical Design

Aruba remote wireless networks are designed to support users at large numbers of sites with high reliability and security levels. To enable IT network architects to successfully plan deployments, Aruba has developed a Virtual Branch Networks Validated Reference Design (VRD) that leverages the experience of customer deployments, peer review by Aruba engineers, and extensive laboratory

performance testing. This VRD leverages and extends the familiar enterprise wired core/distribution/access model so prevalent in most enterprises today.

A complete Aruba VRD base design typically consists of three major elements: Physical network design Logical network design Authentication and security design

In this chapter, we discuss the first element, physical network design. This element encompasses selecting the appropriate access points (APs) and controllers, choosing software licenses, WAN link capacity planning, and regulatory compliance for international networks. Aruba recommends the general architecture shown in this chapter as a best practice for remote networks. This architecture presents the optimal combination of cost savings, performance, and reliability.

Aruba Physical Architecture for Remote NetworksAs we have seen, organizations increasingly deliver IP network services to remote workplaces that do not have local IT support. It is common for these sites to have private, untrusted WAN connectivity to a central data center. Remote sites may have varying redundancy requirements, depending on their size, geography, and whether a local server exists. Therefore, any remote networking physical architecture must be flexible enough to accommodate multiple site requirement categories.

The diagram shown in Figure 10 depicts a high level view of the physical architecture recommended by Aruba and embodied in this VRD. This architecture is intended to serve a variety of branch office and fixed telecommuter scenarios, such as:

Medium branch office (10-50 wired or wireless client devices with wired WAN link) Small branch office (1-10 wired or wireless client devices with 3G wireless or wired WAN link) Fixed telecommuter (1-10 enterprise and family devices with a broadband Internet link) Remote call center agent (one data and one voice device via broadband Internet)

Aruba Networks, Inc. Physical Design | 39


Each remote site communicates over an untrusted WAN link that is directly connected to a remote access point (RAP). There is no need for an intermediate router or firewall device between the RAP and the wide-area customer-premises equipment (CPE) device. These links all home to the enterprise DMZ where redundant Aruba controllers are located.

Figure 10 Aruba Remote Network Physical Architecture

RN

SG

_120

Application

RAP-5 RAP-2WG

RAP-5WNRAP-5WN

Branch Office Sites

Medium Branch Small BranchRemote CallCenter Agent Fixed Telecommuter

Fixed Telecommuter Sites

Internet orWAN

CableProviderBroadband

Carrier

3GEVDO/GSM

Carrier

3GEVDO/GSM

Carrier

AirWave ManagementPlatform

Masterstandby

Data Center

Masteractive

DHCP/DNS

RADIUSPBX

Localactive

Localactive

DMZ



The key components of the physical architecture are: Master Controllers. Two Aruba controllers located at the data center are configured to use

master redundancy. Each controller has redundant gigabit Ethernet links into the data center distribution switches, and shares a Virtual Router Redundancy Protocol (VRRP) address.

Local Controllers. Local controllers are managed by master controllers. They are installed inside the data center DMZ. An Aruba recommended best practice is for two local controllers to run in “active-active” redundancy, with two VRRP addresses shared between them. Very large RAP deployments may require clusters of local controllers. All Aruba controllers share a common hardware architecture that includes a dedicated control processor, a high-performance programmable network processor unit, and a unique programmable encryption engine. Local controllers aggregate network traffic from APs, process it using Aruba software, and deliver it to the network based on defined security polices.

Remote Access Points. Aruba APs serve as on-ramps to aggregate user traffic onto the enterprise network and direct this traffic to Aruba local controllers. APs extend the enterprise network to any remote location by enabling seamless wired or wireless data and voice wherever a user finds an Internet-enabled Ethernet port or cellular connection. While all Aruba AP models support the RAP service, this VRD assumes the exclusive use of Aruba dedicated RAP models. RAPs are selected based on the required number of wired ports, wireless service band (5 GHz/2.4GHz), and 802.11 mode (a/b/g/n).RAPs operate in “hybrid mode” to provide intrusion detection services. This means that the AP performs security and air monitoring functions on a part-time basis between serving client traffic. Hybrid APs are used in the physical design for this Virtual Branch Networks VRD.

AirWave Management Platform. The AirWave console provides a single user interface that enables administrators, help desk staff, security analysts, and other IT staff to have full visibility into and control over the wireless network and users. For more information, see Chapter 11: Reporting and Management on page 177.

Remote Site Physical Architectures

The physical designs of the fixed telecommuter and branch office deployment scenarios have many similarities. For maximum clarity, we consider them separately in each of the design chapters in this VRD.

Fixed telecommuter implementations generally fall into one of two categories: Fixed telecommuter home environment Fixed telecommuter call center environment



The Fixed Telecommuter Home Environment

The fixed telecommuter home environment includes two facets: the employee accessing enterprise resources, the Internet, or shared family resources such as printers; and the family accessing personal resources or the Internet. The following diagram shows an Aruba RAP-5WN AP providing all of these services.

Figure 11 Fixed Telecommuter Home Network

To create enterprise and family access from the home environment, customers deploy an Aruba RAP that is plugged directly into the WAN via a Digital Subscriber Line (DSL) or cable modem. The RAP is configured to support both secure enterprise access and shared family access using the role-based access control capability inherent in ArubaOS. Wired devices are connected directly to one or more secure jacks on the AP and wireless devices associate to one of three secure SSIDs.

Employee PC and laptop devices are assumed to use 802.1X whether wired or wireless, while enterprise voice devices use the strongest authentication mode that they are capable of using. The security design will be explored in greater detail in Chapter 7: Authentication and Security Design.

Family wireless users access the family SSID and family wired devices are connected directly to or via a hub or switch that is uplinked to a secure jack on the RAP that is statically configured for family and Internet access. The built-in firewall inside the RAP is configured with unidirectional ACLs so that the

RN

SG

_108

DSLMPLSFrame Relay

3GWWAN

EnterpriseLAN

DataCenter

Family SSID

EnterpriseSSID

VoiceSSID

EnterpriseWired Access

EnterpriseIP Address Pool(Remote DHCP)

Remote AccessPoint

IP Address Pool(Local DHCP)

FamilyWired Access

Internet orWAN

SharedPrinter

Family PC

Game Console/DVR

IP Phone

Wired PC

InternetServices

RolesEnterpriseVoiceGuest



family printer can be accessed from the employee devices. Internet access is implemented via split-tunnel for both employee and family devices.

For family devices, a third-party hub (e.g. a layer 1 repeater) or layer 2 switch may be installed on a wired RAP port to aggregate traffic from multiple devices. Identical authentication methods and roles must be in use on each of the devices, however, because all users sharing the same wired port will also share the same role, policies, and VLAN settings.

A layer 2 switch must never be used for enterprise wired devices if 802.1X authentication is in use, because 802.1X EAPOL frames are processed by the switch rather than forwarded.

The Fixed Telecommuter Call Center Environment

The Aruba remote networking solution offers great flexibility to the enterprise with respect to the services it wishes to offer to its employees. To illustrate this flexibility, we present as part of the reference design a remote call center agent with a restricted configuration.

Home-based agents can be implemented as a special case of the home environment with two important differences:

Very low cost AP with only two wired ports No family access

The Aruba RAP-2WG is recommended for this scenario. To create wired access to the call center environment, the RAP is configured so that the IP phone connects to a second secure jack on the AP via an 802.1Q trunk. The wired PC then connects to the phone. Internet access for the employee PC is allowed via split-tunnel, as seen in Figure 12. The RAP-2WG includes a 802.11b/g radio that can be enabled if the organization wishes.

Figure 12 Fixed Telecommuter Call Center Application

N O T E

In this VRD, it is assumed that each wired port is preconfigured for the specific device that will be plugged into it. Aruba calls this “Per Port” configuration.

N O T E

Do not use a layer 2 switch in front of a RAP wired port if 802.1X authentication is in use.

RN

SG

_109

DataCenter

RolesEnterprise

EnterpriseAccessInternet or

WAN

InternetServices

IP PhoneRAPWired PC

802.1Q Trunk

Voice



Figure 12 shows how the versatility of the Aruba RAP solution can support various enterprise postures with respect to providing home Internet connectivity to employees, at low cost to the organization.

The Branch Office Solution

The Aruba remote network solution provides an extension of the enterprise LAN into the branch office without the complexity of enterprise LAN routing, firewall, and VPN equipment. In this use case, an Aruba RAP is wire-connected to a Frame Relay, DSL, MPLS, or other service provider premise device for its WAN uplink. On the downlink side, three devices are connected to the RAP:

Branch office employee wired devices are connected to a hub or switch that is uplinked to a secure jack configured for enterprise and Internet access

Guest (vendors and customers, for example) wired devices are connected to a second hub or switch that is uplinked to another secure jack configured for controlled Internet access

A local server is connected to a third secure jack, which allows for convenient traffic control via locally enforced security policies

This reference design requires an Aruba RAP-5WN access point to provide the number of secure jacks required for this application. This design is illustrated in the following drawing.

Figure 13 Remote Branch Office Network

Wireless services can be offered on either the 2.4 GHz or 5 GHz bands for maximum compatibility and performance; Aruba offers a flavor of the RAP5 that does not include any radio for wired-only deployments. Aruba also offers dual-radio access points to meet requirements for simultaneous 802.11 a/b/g/n deployments.

RN

SG

_107

GuestSSID

HTTPSApplication

ServerEnterprise

Wired Access

GuestWired Access

EnterpriseSSID

VoiceSSID

EnterpriseIP Address Pool(Remote DHCP)

Remote AccessPoint

IP Address Pool(Local DHCP)

DSLMPLSFrame Relay

EnterpriseLAN

DataCenter

3GWWAN

InternetServices

Internet orWAN

RolesEnterpriseVoiceGuest



Data Center Physical Architecture

Production remote networking deployments are IT services that are expected to maintain high availability and performance levels. Therefore, Aruba recommends deploying two master controllers in the data center. These master controllers are configured in an “active-standby” configuration that provides 1:1 redundancy. In the Virtual Branch Networks VRD, the master controllers do not terminate APs. The redundant local controllers are located on the DMZ and terminate the RAPs in the remote network. The AirWave appliances are also located in the data center.

Colocating Remote Network and Campus Controllers

Aruba offers special-purpose code trains such as Remote Networking (RN) and Federal Information Processing Standard 140-2 (FIPS) in addition to our mainline releases. This VRD is based on the RN code train. The RN release is required to manage the RAP-5WN, RAP-5, and RAP-2WG hardware, as well as to provide many of the remote networking features described in this VRD such as zero touch provisioning. Controllers running the RN code train are not intended to manage locally-connected, or “campus” access points. Therefore, separate controller clusters are required for remote network and campus deployments.

Adding a new Aruba master/local cluster to a data center with an existing master/local cluster serving campus APs is very simple. Two pairs of master controllers should have redundant connections to the core network. One pair runs the RN code train, and the other runs mainline ArubaOS.

The local controller pair that manages the remote access points must run the RN code train and should be located in the DMZ with one-armed connections to DMZ switches. The other pair of local controllers is typically connected to distribution layer switches via one-armed connections. This controller pair runs mainline ArubaOS.

Figure 14 Aruba Remote Network Physical Architecture

RN

SG

_114Internet

or WAN

ApplicationAirWave Management

Platform Masteractive

CampusLocalactive

CampusLocalactive

Masterstandby

Masterstandby

Masteractive

DHCP/DNS

Remote Network

RADIUSPBX

RAPLocalactive

RAPLocalactive

DMZDistribution Layer

Data Center Campus Network



During the staging process, RAPs must communicate with a master controller running RN code in order to be provisioned. Aruba customers that are already using DNS autodiscovery of “aruba-master” for bootstrapping of campus APs must use DHCP Option 43 for RAPs to discover the proper master controller. The simplest method is to use a private IT testing subnet with a local DHCP server that is configured to offer the IP address of the RN master controller. This is only required if you plan to use the pre-provisioning deployment method described in Chapter 8. By contrast, zero touch provisioning uses either a static public IP address or an externally-resolvable FQDN that is entered by the remote user after plugging the RAP into a broadband WAN link.

Required EquipmentTo adapt the general physical design shown in Figure 10 on page 40 for your organization, you must make a series of hardware selections. Aruba recommends that you proceed from the AP level inward to the local controller and then to the master controller levels. Follow this decision tree as you work through the process.

Figure 15 Equipment Decision Tree

RN

SG

_153

MultiplyClient Device Count

by Site Count(using Table 1)

SelectLocal Controller Modelequal to 150% of TotalClient Device Count

(each)

MultiplyClient Device Count

by Site Count(using Table 1)

Assign all Localsto separate

Master/Local clusters

SelectRAP Model(s)

SelectRAP Model(s)

EstimateClient Device Count

(using Table 2)

EstimateClient Device Count

(using Table 3)

MultipleMasters

required?

SelectMaster Controller Model

(using Table 3)

SelectAirWave Server Appliance

equal to 150% ofAll APs & Controllers

Branch Office

RemoteSites

DMZ

DataCenter

Fixed Telecommuter

Yes

No



Access Points

This VRD assumes the use of Aruba dedicated RAP models for large-scale, production deployments. We also assume the use of APs that offer at least two Ethernet ports to provide for a secure wired jack. This use provides maximum flexibility and allows for local wired bridging applications. As of this writing, these APs include:

Figure 16 Aruba Dedicated Remote Access Point Product Family

These models include features specifically designed and tested for remote deployments such as certificate-based zero touch provisioning. These AP models are not intended or supported for local campus deployments.

N O T E

All Aruba campus AP models can be deployed in a RAP. However, campus APs such as the AP-AP70 and AP-120 series do not contain certificates and do not support zero touch provisioning.

Aruba RAP-5 Remote Access Point4 Wired Ports + 1 Uplink Port

No Wireless RadioUp to 256 users/devices

1 USB PortPoE or 12V DC Powered

Aruba RAP-5WN Remote Access Point4 Wired Ports + 1 Uplink Port

Single 3x3 MIMO Radio, 802.11a/b/g/nUp to 256 users/devices

1 USB PortPoE or 12V DC Powered

Aruba AP-125 Access Point1 Wired Port + 1 Uplink Port

Dual 3x3 MIMO Radios, 802.11/a/b/g/nUp to 256 users/devicesPoE or 5V DC Powered

Aruba RAP-2WG Remote Access Point1 Wired Port + 1 Uplink Port

Single 802.11 b/g RadioUp to 5 users/devices

12V DC Powered



With Aruba Software-Defined Radio (SDR) technology, APs can be used anywhere in the world. It is not necessary to stock different AP models on a per-country basis for regulatory reasons. Regulatory compliance on Aruba products is managed at the controller level, as we will discuss later in this chapter.

Please note that RAPs can be ordered as US and ROW (Rest of World) models based on electrical requirements. The available SKUs are:

Local Controllers

To build the Aruba VRD as shown in (Figure 10 on page 40) appropriately sized local controllers are deployed in the enterprise DMZ. Local controllers terminate AP tunnels and serve as an enforcement point for security policies. The reference design assumes full 1+1 redundancy, which requires a pair of identically configured local controllers in support of failover.

Figure 17 Aruba Controller Blades for MMC-6000 Chassis

Table 5 RAP-5 and RAP-2 SKUs

SKU Description

RAP-2WG-US Aruba Remote Access Point Model 2WG, US power supply

RAP-2WG-EU Aruba Remote Access Point Model 2WG, EU power supply

RAP-2WG Aruba Remote Access Point Model 2WG, International power adapter kit

RAP-5WN-US Aruba Remote Access Point Model 5WN (Wired and Wireless), US power supply

RAP-5WN Aruba Remote Access Point Model 5WN (Wired and Wireless), International power kit

RAP-5-US Aruba Remote Access Point Model 5 (Wired Only), US power supply

RAP-5 Aruba Remote Access Point Model 5 (Wired Only), International power kit

Aruba M3 BladeUp to 2,048 RAPs (8,192 users)

10 1000Base-X Ethernet ports (SFP)2 10GBase-X Ethernet ports (XFP)1 1000Base-T Ethernet port (RJ-45)

Aruba 3600 ControllerUp to 512 RAPs (2,048 Users)

4 Gigabit Ethernet (1000Base-T or 1000Base-X SFP)



In order to utilize zero touch provisioning and/or certificate-based authentication, it is necessary to use either an Aruba 3000-series controller or M3-series blade. Like the RAP-2 and RAP-5 access points, these controllers include an integrated security certificate.

Controller Sizing

This Virtual Branch Networks VRD assumes that local controllers to reside in the DMZ will be sized according to the number of RAPs they terminate, as well as the total number of client devices on all the RAPs. As we will discuss later in this chapter, in full 1+1 redundancy deployments, each controller must be capable of assuming the entire load of APs in remote sites that are assigned to it. Therefore, local controllers should be sized and licensed so that 50% of the RAP population terminates on each unit during normal operation.

For large RAP deployments, the VRD assumes the use of either the MMC-3600 standalone controller or M3-series controller blade in an A6000-series chassis with redundant 400W power supplies. Two identically configured chassis are installed in the DMZ in a 1+1 redundancy model. Up to 4 M3 blades can be installed in a single chassis to serve up to 8,192 remote sites and 32,768 users or devices.

N O T E

Certificate-based provisioning and zero touch provisioning are only supported on the M3 Blade and 3000 series controllers.

Table 6 Controller Product Line Matrix

FeaturesMMC-3000 Series MMC-6000 Series

MMC-3200 MMC-3400 MMC-3600 M3 Blade Chassis (4 Blades)

Max number of campus-connected APs per controller

32 64 128 512 2,048

Max number of RAPs per controller 128 256 512 2,048 8,192

Max number of users or devices per controller 512 1,024 2,048 8,192 32,768

MAC addresses 64,000 64,000 64,000 64,000 256,000

Maximum number of concurrent tunnels 128 256 512 2,048 8,192

Maximum number of VLANs 128 256 512 2048 8,192

Zero touch provisioning supported Yes Yes Yes Yes Yes



The user and RAP limits from Table 6 can be combined in matrix form. Use the following table to select the appropriate model and quantity of controller for your deployment. Use the same model for both active local controllers.

A quantity of the appropriate SFP and/or XFP modules may also be required; Aruba offers a complete line of modules on its price list.

International Regulatory Compliance

The United States and Israel restrict the Aruba controller to managing only APs that are located within those countries. Aruba offers country-specific SKUs for these two areas. All other countries in an international deployment can be managed from a single Rest of World (ROW) controller. When ordering Aruba controller SKUs, be careful to order the appropriate country SKU for the location where the controller will be installed. For additional information, see the Regulatory Compliance section later in this chapter or consult your Aruba representative.

Master Controllers

Master controllers serve as a central point of configuration for the system. Masters also offload network management, wireless IDS (WIDS), and RF decision making from the local controllers. This VRD assumes either the MMC-3600 standalone controller or M3-series controller blade in its 6000-series chassis with redundant 400W power supplies.

Figure 18 Aruba MMC-6000 Chassis with 4 M3 Blades

Table 7 Local Controller Sizing by License Count

RAP Site Count50 100 250 500 1,000 2,000

Dev

ices

per

Site 1 MMC-3200 MMC-3200 MMC-3400 MMC-3600 1xM3 1xM3

5 MMC-3200 MMC-3200 MMC-3600 1xM3 1xM3 2xM3

10 MMC-3200 MMC-3400 1xM3 1xM3 2xM3 3xM3

15MMC-3400 MMC-3600 1xM3 1xM3 2xM3 4xM3

N O T E

Certificate-based provisioning and zero touch provisioning are only supported on the M3 Blade and 3000 series controllers.



Controller Sizing

The proper size of a master controller is determined by both the number of connected or associated wired and wireless user devices as well as the number of APs managed by all of the downstream locals. Even though AP tunnels do not terminate on the master, each RAP transmits WIDS and RF telemetry directly to the master. Aruba has thoroughly tested all of its controller models in a master role supporting various AP and local controller loads.

The user or device and AP limits from these tables can be combined in a matrix form. Use the following table to select the appropriate controller model for your deployment. Use the same model for both the active master and the standby master.

Very large deployments that require more than one M3 blade for a master should be divided into clusters of locals, each with its own master. Use one M3 blade configured as the active master for each cluster, with a second M3 blade configured as a standby master. Up to four active masters or standby masters can be installed in a single A6000 chassis. Aruba does not recommend collocating active and standby masters in the same chassis.

International Regulatory Compliance

The United States and Israel restrict master controllers to managing only local controllers that are located within those countries. Aruba offers country-specific SKUs for these two areas. All other countries in an international deployment can be managed from a single Rest of World (ROW) controller. When ordering Aruba controller SKUs, be careful to order the appropriate country SKU for the location where the controller will be installed. For additional information, see the Regulatory Compliance section later in this chapter or consult your Aruba representative.

Table 8 Maximum Number of APs and Users or Devices per Master Controller Model

Master Maximum APs Maximum Users or Devices

M3 Blade/MMC-3600 4,500 15,000

MMC-3400 2,250 7,500

MMC-3200 1,500 4,500

Table 9 Master Controller Sizing by Client Device Count

Number of RAP Sites50 100 250 500 1,000 2,000

Dev

ices

per

Site 1 MMC-3200 MMC-3200 MMC-3200 MMC-3200 MMC-3200 MMC-3200

5 MMC-3200 MMC-3200 MMC-3200 MMC-3200 MMC-3400 MMC-3600

10 MMC-3200 MMC-3200 MMC-3200 MMC-3400 MMC-3600 M3 Blade

15 MMC-3200 MMC-3200 MMC-3200 MMC-3400 M3 Blade M3 Blade



AirWave Appliance

AirWave offers two different hardware appliance models. They are sized based on the number of APs and controllers being managed. For large deployments, you purchase and deploy multiple AirWave appliances, and the software will automatically cluster the controllers together and distribute the processing workload appropriately. The SKUs are: AMP-HW-ENT, AirWave Management Platform for managing up to 2,500 devices, and AMP-HW-PRO, AirWave Server Appliance for managing up to 1,000 devices.

Required LicensesTo support RAPs, the local controllers must have RAP licenses to provide IPsec encryption and split-tunnel or local bridging features. All controllers in a Master/Local cluster must be running the same version of software.

Local Controllers

To build this Aruba VRD as depicted, the following licenses are required on each of the local controllers, assuming that there are a total of 2,048 Aruba RAPs being managed, with an MMC-6000 Multiservice Aruba Controller acting as a backup to a second MMC-6000:

LIC-2048-RAP Remote Access Point License (2048 RAPs) LIC-WIP-2048 Wireless Intrusion Protection Module License (2,048 AP Support) LIC-PEF-4096 Policy Enforcement Firewall Module License (4,096 Users, 2:1 PEF users to

RAPs)

The ratio of PEF users to RAPs is 2:1 and is determined by the number of devices accessing the network through each RAP.

Master Controllers

The following licenses should be applied to the master controllers, assuming a MMC-3600 controller with no APs terminating and not acting as a backup for any local controller:

LIC-1-RAP Remote Access Point License (1 RAP) LIC-WIP-8 Wireless Intrusion Protection Module License (8 AP Support) LIC-PEF-128 Policy Enforcement Firewall Module License (128 Users1)

It should be noted that each RAP counts towards the RAP License count, while each SSID on a radio plus each wired port in use counts as one (1) tunnel against the total concurrent tunnel capacity of the controller serving as the local. Concurrent tunnel capacity is indicated on the datasheet for each Aruba controller.

N O T E

Aruba has released a dedicated code train for Remote Networking deployments. This VRD is based on ArubaOS 3.3.2.11-rn3.0. The mainline ArubaOS code train does not include many of the remote networking features discussed in the VRD and should not be used.

1. Users on a tunnel in bridge forwarding mode need not be added to the total user count for a controller PEF license.



AirWave Appliance

The AirWave Management Platform (AMP) is licensed using the same sizing criteria as the hardware appliance:

AMP-ENT, AirWave Management Platform software for a single server with no limit on processor cores. Recommended for managing up to 2,500 devices such as controllers, wireless access points, or switches.

AMP-PRO, AirWave Management Platform software for a single server with up to four processor cores. Recommended for managing up to 1,000 devices such as controllers, wireless access points, or switches.

Both SKUs include the full selection of AirWave modules, including the AirWave Management Platform (AMP), Visualization and mapping software module (Visual RF), and RAPIDS (Rogue detection software).

3G Modem Selection3G service providers supply lists of wireless modems that are supported in their networks. The availability of 3G service from wireless carriers continues to increase rapidly, and more modems are being introduced by a variety of manufacturers.

USB cellular modems are supported via the USB port on the AP-70, RAP-5, and RAP5-WN. ArubaOS 3.3.2.0-rn3.0 supports several EVDO (Evolution Data Optimized, up to 3.1 Mbps, CDMA) and 3G HSPA (High-Speed Packet Access, 3G data service) modems. This software release, with its built-in flexibility, can support future USB modems and protocols without a software code change. 3G HSPA is provided by AT&T in the United States and by numerous other 3G providers worldwide. The following USB modems are verified in this release:

Manufacturer Model

AT&T USBConnect 881 (Sierra 881U)

Mercury (Sierra Compass 885)

Quicksilver (Globetrotter ICON 322)

Huawei E272, E170, E220

Sprint Compass 597 (Sierra)

USB 598 (Sierra)

Ovation U727 (Novatel)

U300 (Franklin wireless)

Verizon USB U727 (Novatel)

USB U720 (Novatel/Qualcomm)

UM175 (Pantech)

UM150 (Pantech)

U597 (Sierra)



Please see Appendix B: Provisioning Parameters for Verified USB Modems on page 237 for detailed information on USB modem dial strings. For detailed modem provisioning procedures, please see the ArubaOS 3.3.2.x-rn3.0 Release Notes.

Wide-Area Network ConsiderationsThe speed and latency of the connection between the RAP and the controller have a significant impact on the applications that can be supported on the RAP. Typical fixed telecommuter applications include office productivity suites, VoIP, and video conferencing. Branch offices, in addition, may utilize remote server or batch upload applications.

Aruba recommends a broadband connection of 1 Mbps or higher with latency of 100 ms or less.

Bandwidth Constraints

Specific design guidelines and controller configurations are required to maximize performance for low-speed links such as ISDN, fractional T1/E1, and many frame relay WAN connections.

RAPs and controllers transmit “heartbeat” or “keepalive” packets between themselves to achieve high reliability and fast failover in the event of a network or controller outage. Depending on the forwarding modes in use, failure to receive these heartbeat packets can cause RAPs to “re-bootstrap,” re-establishing tunnels with the controllers. During the bootstrap process, the AP shuts off all radios for approximately 20 ms, and all clients are required to re-associate.

If a low-speed link is saturated, heartbeat packets can be dropped, causing the RAP to re-bootstrap. This is the primary cause of connectivity problems for APs connected across low-speed links.

There are no hard rules to categorize what will work and what will not. A number of Aruba customers have deployed RAPs across 64 Kbps WAN links without difficulty, because packet loss is low and the throughput requirements are not high. Other customers with unpredictable traffic loads have experienced some problems due to RAP heartbeat timeouts.

Customers with a low-speed link requirement must analyze and test realistic traffic patterns before deployment to minimize risk of link saturation.

Telecom (New Zealand) Tstick C597 (Sierra)

TataIndicom (India) SXC-1080 (Qualcomm)

Telenor (Sweden) Globetrotter ICON 225

Vodafone/SmarTone (HK) Huawei E272

NZ and JP Huawei E220

T-Mobile UMG181

N O T E

Aruba has tested and verified the modems listed above. While a modem not in this list may operate as expected, Aruba can only assure the proper performance and interoperability of the modems listed above.

Manufacturer Model



Latency Constraints

When deploying RAPs across high-latency links of 100 ms or greater, special considerations are required due to the timing constraints of some client devices. Certain wireless clients are known to have very tight timing requirements that cause the association process to time out if an association response is not received within 100 ms. Please check with your device vendor for the latest versions of firmware and drivers that are designed to be less sensitive to WAN latency.

Aruba recommends that customers needing tunnel forwarding mode test high-latency links to confirm that timing issues will not become a problem. The split-tunnel and bridge forwarding modes can also be used to reduce or eliminate certain WAN traffic and delays. Refer to Forwarding Modes on page 64 for more details about which mode to deploy in cases where high latencies are unavoidable.

3G Wireless Constraints

The minimum signal level required to be received by the handset in order for it to “see” the Primary CPICH (common pilot channel) within a coverage area is a function of multiple factors including the transmitter power of the base station, the receiver sensitivity of the 3G modem, the separation distance between the 3G modem and the base station, carrier frequencies, antenna heights of the base station, terrain features such as buildings, tall structures, trees, lakes, and other bodies of water, the width of the streets traversed by the 3G modem, and the angle at which the signal is incident at the receiving antenna. Typically, 3G service providers engineer their networks so that across the entire stated coverage area to a better than 99% probability, a 3G modem will “see” the signal when the receiver sensitivity of the 3G modem is < -90 dBm.

Many 3G modems have indicators of signal strength, usually colored bars that provide information about the 3G signal detected by the modem’s receiver. In environments where signal strength is insufficient for the modem’s receiver to detect (absence of bars or other signal strength indicators) or to lock onto (blinking bars or other indicators) for sustained transmission and reception, it is possible to increase reception through the use of external antennas. These antennas are typically neither tested nor endorsed by the 3G modem vendors or the 3G service providers, but are available as after-market accessories.

Recommendations for Minimizing Constraints

Aruba recommends the following best practices when deploying RAPs across low-speed or high-latency links:

Adjust the RAP bootstrap-threshold if the network experiences packet loss. The RAP will recover more slowly in the event of a failure, but it will be more tolerant to loss of heartbeat packets. The recommended bootstrap-threshold setting is 30.

Limit the number of tunnel mode SSIDs to reduce the number of GRE tunnels traversing the WAN link. Use split-tunnel mode SSIDs, or a combination of split-tunnel and tunnel. Split-tunnel SSIDs create a single GRE tunnel, regardless of how many split-tunnel SSIDs are configured on the RAP. In contrast, tunnel mode SSIDs create a separate tunnel for each SSID.

If high-latency links such as transoceanic or satellite are used in the network, deploy a second local controller geographically proximate to the RAPs. For example, deploy one controller per continent. Geographical deployment may also be required by regulatory requirements.



For 3G modem locations, Aruba recommends completing a 3G wireless site survey prior to deployment. Simply plug the same USB modem into a laptop at each location and verify that the signal strength meets minimum requirements.

Make sure that all client devices install the most current firmware and driver updates from device manufacturers to reduce the sensitivity to link latency.

Regulatory Compliance for International DeploymentsAP radios must meet government regulatory compliance requirements in the countries where they are installed. The geographical areas of the world for regulatory compliance purposes are broken down as follows:

USA Israel Rest of World (ROW)

This section provides guidance on how to design international fixed telecommuter solutions.

In addition, certain Aruba controller models are prohibited from being shipped to or operated in other countries.

Access Point Compliance

RAPs must be assigned proper country codes to comply with local regulatory requirements. AP radios must comply with specific limits on channel use and transmit power established by regulatory bodies in the countries where they are installed.

This requirement is accomplished through the AP Group feature. Each Aruba RAP is assigned to one AP Group. The AP Group is assigned a country code, which determines the regulatory rules applied to the AP radio, including the 802.11 wireless transmission spectrum. Most countries impose penalties and sanctions for operators of wireless networks with devices set to improper transmission spectrums.

Aruba uses Software Defined Radio (SDR) technology so that any of its access points can be used in any country that has granted approval. Aruba RAPs are approved for operations in more than 100 countries. There is no need to keep different AP models for different countries because the country code can be changed as needed and is enforced by the Aruba controller.

N O T E

Please note that the RAP-5, RAP-5WN and RAP-2WG can be ordered as US and ROW (Rest of World) models based on local electrical requirements. This is not related to radio regulatory compliance, which is managed at the controller.



Controller Compliance

When ordering an Aruba controller, customers specify a geographic region: United States, Israel, or ROW.

Aruba controllers sold in the United States or Israel are physically restricted from managing RAPs in other regulatory domains; administrators cannot assign another regulatory domain to the RAPs that terminate at these controllers. However, a ROW controller can properly manage RAPs from any unrestricted country and enforce the correct regulatory radio rules.

For example, a US-based controller may not terminate or manage RAPs based in Canada or Mexico, nor can it failover using Virtual Router Redundancy Protocol (VRRP) to a non-US controller. But a ROW controller may failover to an identically configured ROW controller for redundancy purposes.

Figure 19 United States Controllers Cannot Manage RAPs In Other Countries

RN

SG

_071

Italy_AP_group

Spain_AP_group

FRG_AP_group

UK_AP_group

France_AP_group

ROWController

Rest-Of-World ControllerManaging APs in

Multiple Regional Domains

USAController

Region-Specific Country Code



A single Aruba ROW controller can manage RAPs in France, Germany, Italy, and Spain as long as the APs in each country are properly assigned to separate AP Groups. Each AP Group must be assigned an RF Management Profile with the correct country code corresponding to the physical location of the APs.

Figure 20 Rest of World (ROW) Controller

Recommendations for International Deployments

Use this checklist to verify that your Aruba design complies with the host country laws and regulations:1. Review all controllers participating in VRRP clusters to confirm that all models have identical

country SKUs.2. Review all RAPs terminating on US-based controllers and make sure that they are all in the US.3. Review all RAPs terminating on Israel-based controllers and verify that they are all in Israel.4. Make lists of all RAPs by country to create Regulatory Domain profiles.5. Purchase any additional controllers necessary to achieve regulatory compliance.

RN

SG

_070

Italy_AP_group

Spain_AP_group

FRG_AP_group

UK_AP_group

France_AP_group

ROWController

Rest of World ControllerManaging APs in

Multiple Regional Domains



Chapter 6: Logical Design

This chapter describes the validated reference logical architecture for an Aruba remote network for organizations with hundreds or thousands of sites. As with the physical architecture, each type of facility communicates to an enterprise data center. Due to differences in the requirements for fixed telecommuters and branch offices, each of the logical designs is considered separately.

Aruba Logical Architecture for Remote NetworksA reference wired network architecture that defines “core,” “distribution,” and “access” elements has become a well-established architecture among IT network professionals. These elements form the building blocks of large-scale, highly available networks. Vendor validation of their products against this conceptual reference architecture provides IT organizations with assurance that products will perform and interoperate as expected.

From a logical perspective, the Aruba Virtual Branch Networks VRD introduces three new layers that overlay the familiar core/distribution/access framework:

Management. The management layer provides a control plane for the Aruba system that spans the physical geography of the wired network. It consists of redundant master controllers and the AirWave system. Critical functions provided by the management layer controllers include centralized configuration management and the offloading of ARM and IDS processing from the aggregation layer to the management layer.

Aggregation. This layer is the interconnect point where remote access point (RAP) traffic bound for the enterprise network is aggregated. For a RAP deployment, the layer consists of local controllers using 1+1 redundancy. Secure IPsec-encrypted, generic route encapsulation (GRE) tunnels from RAPs at the network access layer terminate on controllers at the aggregation layer. This method provides a logical point for enforcement of roles and policies on remote traffic that enters or exits the enterprise LAN. The traffic traversing these IPsec-encrypted and GRE-encapsulated tunnels consists only of tunneled or split-tunneled traffic. With bridged SSIDs or wired profiles, traffic is bridged locally and does not traverse the WAN.

Network Access. The network access layer is comprised of RAPs, which work together with the aggregation layer controllers to overlay the VBN over the WAN. RAPs offer a choice of three different traffic forwarding modes. Tunnel forwarding mode backhauls all traffic to the Aggregation layer for processing. When split-tunnel or bridge forwarding modes are used, firewall ACLs in the RAP provide the front line of policy enforcement. Bridge mode traffic never leaves the RAP, while split-tunnel traffic is only forwarded to the Aggregation layer for enterprise destinations. RAPs serve as air monitors on a part-time basis.

The management, aggregation, and network access layers overlay the core, distribution, and access enterprise network across any public or private wide-area network, effectively virtualizing the remote branch network in a seamless, secure, and high-performance manner.

Aruba Networks, Inc. Logical Design | 59


Fixed Telecommuter Logical Design

The operation of these layers for the fixed telecommuter use case can be seen clearly in the logical architecture depicted in Figure 21. The Network Access layer is made up of RAPs deployed at each site. The wired ports and/or wireless SSIDs that are enabled on the RAP form the edge of the network.

Figure 21 Remote Network Logical Architecture–Fixed Telecommuter

RN

SG

_121

NetworkAccess

Aggregation


IP PhoneWired PC

SharedPrinter

FamilyPC

Game Console/DVR

EnterpriseSSID Voice

SSID

FamilySSID

Localactive

Localactive

Masterstandby

Data Center

DMZ

Masteractive

Application

EnterpriseLAN

VoiceLAN

Management

PBX

InternetServices

Internet orWAN Overlay

RADIUSDHCP /

DNS



Key components of this logical design include: Each RAP is placed directly on the Internet. It obtains an IP address via DHCP, PPPoE or static

configuration during the provisioning process. The AP performs NAT/PAT for Internet-bound traffic.

The local controllers in the DMZ are reachable via dst-nat NAT-T (udp/4500). The local address may be resolvable by DNS, or preconfigured in the ap-system-profile.

High security split-tunnel VLAN for 802.1X authenticated wired and wireless enterprise data devices. Wireless traffic on the Enterprise SSID is decrypted at the AP, where policies are applied. All frames bound for the core network are then encrypted using IPsec and routed to the aggregation layer local controllers.

Direct tunnel VLAN for MAC authenticated wired or wireless enterprise voice devices. WPA or WPA2 wireless traffic on the Voice SSID is encapsulated and forwarded directly to the aggregation layer without local decryption.

Locally bridged VLAN for family wired or wireless devices. Aruba recommends setting a pre-shared key on the family SSID. Bridged traffic never leaves the RAP. Split-tunnel enterprise users can access shared family devices such as printers via unidirectional ACLs.

Management tunnel to the management layer master controller for processing of WIPS and Adaptive Radio Management (ARM) telemetry. This tunnel is also used during bootstrapping to authenticate the RAP to the network.

The DHCP server for the enterprise and voice VLANs is located in the core network. The RAP internal DHCP server provides IP addresses for the family VLAN.

From a traffic flow perspective, these components work together to overlay the enterprise LAN across a wide-area network in a secure and high-performance manner.



Branch Office Logical Design

The logical design for the branch office use case is generally similar to the fixed telecommuter design, with some variations to accommodate a local server and authentication differences. Figure 22 shows the logical architecture for branch offices for normal operation.

Figure 22 Remote Network Logical Architecture–Branch Office

NetworkAccess

RN

SG

_105

Aggregation


Localactive

Localactive

Masterstandby

Data Center

DMZ

Masteractive

Application

EnterpriseLAN

VoiceLAN

Management

PBX

InternetServices

IP PhonePC Printer

GuestLaptop

GuestLaptops

Internet orWAN Overlay

EnterpriseSSID Voice

SSID

HTTPSApplication

Server

RADIUSDHCP /

DNS



As with the fixed telecommuter scenario, each RAP is placed directly on the Internet, while the local controllers are reached via NAT-T across a DMZ firewall. From a traffic flow perspective, key elements of the branch office design include:

Guest traffic and enterprise traffic are segregated onto different L2 switches. An onsite application server is directly connected to a secure jack on the RAP. Security policies

limit access to the server to authenticated enterprise devices. Split-tunnel VLAN for wired and wireless enterprise devices. MAC authentication is used for

wired devices. Wireless traffic from scanning terminals, tablets and other data devices is secured using WPA/WPA2 with a pre-shared key, and decrypted locally at the AP, where policies are applied. All frames bound for the core network are encrypted via IPsec and sent over the WAN.

Direct tunnel VLAN for MAC authenticated wired or wireless enterprise voice devices. Locally bridged VLAN for guest devices. A captive portal is implemented for both wired and

wireless guest users. Aruba offers multiple login modes, from simply agreeing to an Acceptable Use Policy, to username or username and password restricted access.

Management traffic and DHCP services work just as in the fixed telecommuter scenario.

If the WAN connection is lost, the AP constantly attempts to rebuild the connection without interrupting local connectivity. Only direct tunnel VLANs are affected in this type of outage. The bridge-mode VLAN will continue to operate for local devices with no interruption.

Data Center Logical Design

In an Aruba network employing a master/local design, all configuration is performed on the master, and then pushed down to the locals. RF planning and real-time RF visualization take place on the master or in AirWave. The master controls ARM decisions and is responsible for radio power and channel settings at the network access layer. The RAP and user troubleshooting is done on the controller where the AP's are terminating their tunnels, which in this case is the local controller. The master controller can be used to globally see AP states, such as what controller the RAPs are terminating on and their Up/Down status.



Figure 23 Data Center and DMZ Logical Design

The master processes wireless intrusion detection system events and presents the event and the corresponding wireless vulnerability and exploit (WVE) identifier. The master also handles location services correlation algorithms that compute the position of clients as well as rogue APs, using signal strength measurements from APs in the network. The master can also work in conjunction with the AirWave server to offload these functions (WMS offload).

If the master becomes unreachable, the network will continue to operate as expected, but without the ability to perform operations such as configuration, heat map analysis, or location services, until connection to the master controller is restored. However, RAPs will not be able to bootstrap and authenticate to the network while the master is unreachable.

Forwarding ModesA RAP supports three different forwarding modes for wireless SSIDs and wired ports: split-tunnel, tunnel, and bridge. Forwarding modes can be combined as desired on a port-by-port and SSID-by-SSID basis. This section provides guidance on how to choose the appropriate forwarding mode for different applications.

Split-Tunnel Mode

Split-tunnel mode offers the most flexibility to the end user in terms of supporting applications and deployment scenarios. Split-tunnel also offers the highest performance for mixed destination traffic

RN

SG

_154

Aggregation

AirwaveManagement Platform

Control

VRRPLocalactive

Localactive

Masterstandby

Data Center

DMZ

Masteractive

Application

RADIUSDHCP /

DNS

EnterpriseLAN

VoiceLAN

Management

PBX

WMS DB Sync

802.1X Authentications

WMS Offload

VRRP



and slow links (less than 128Kbps). This forwarding mode allows access to local servers and the Internet without incurring the performance penalty of a round trip to the controller in the central DMZ or data center.

With split-tunnel, the Aruba firewall operates inside the RAP as well as in the controller. In this mode, wireless traffic is first decrypted at the AP. This decryption allows role-based forwarding policies to be applied by configuring a series of ACLs tied to a user role or a wired port. Some form of derivation rules will also be required to place the end user in the desired role during the authentication process. Such rules can include assigning roles on the basis of wired interface, wireless SSID, authentication method, or RADIUS attributes, among other criteria.

Figure 24 Split-Tunnel Mode

RN

SG

_124

VoiceSSID

EnterpriseSSID

IPsec/AES-CCM Encrypted Control Channel

EnterpriseIP Phone

Guest/FamilySSID

LAN PC

Voice SSID

Enterprise HQ

EnterpriseSSID

(Split TunnelMode-802.1X)

EnterpriseSSID

(Split TunnelMode-802.1X)

RAP(with firewall)

RAP(with firewall) Firewall /

NAT-T

Internet orWAN

Websites

Shared UsePrinter

RemoteLocation



Split-tunnel mode offers specific advantages that generally provide better performance than tunnel mode even after latency due to wireless decryption is factored in.

Split-tunnel mode SSIDs process 802.11 management frames locally, when local probe response is enabled. For latency-sensitive clients such as voice devices or mobile data terminals running character-based applications, this produces a more consistent user experience. In tunnel mode, these management frames are tunneled to the controller which can increase end-to-end latency.

Split-tunnel mode traffic is multiplexed on a single GRE tunnel back to the controller, regardless of the number of split-tunnel wired ports or wireless SSIDs. This multiplexing can significantly reduce management overhead on the WAN link, leaving more bandwidth for application traffic. By contrast, in tunnel mode, a separate GRE tunnel is established for each SSID on each radio.

Split-tunnel mode provides support for split DNS and corporate DNS domain.

However, these advantages are offset by the time required to decrypt wireless frames, make forwarding decisions, and then encrypt frames with IPsec. While split-tunnel is the best choice in many cases, this extra latency must be considered.

Tunnel Mode

Tunnel mode offers the lowest latency for wireless traffic between the RAP and the controller. In tunnel mode for SSIDs that use WPA/WPA2or WEP with encryption, the RAP acts as a relay and simply forwards the pre-encrypted wireless frames on to the controller, encapsulated with GRE. All of the heavy lifting related to encryption is performed by the client and the local controller.

Table 10 Management Frame Processing–Split-Tunnel Mode

Management Frame Type Open, Static WEP, PSK Processing Location

802.1X Processing Location

Probea

a. Requires that local probe response be enabled.

RAP RAP

802.11 Auth RAP RAP

802.11 Assoc RAP Controller

EAP n/a Controller

Key Exchange RAP Controller

N O T E

Each device on split-tunnel mode VLANs counts towards the PEF license limit on the local controller.



Tunnel mode does not incur the incremental decrypt/encrypt latency inherent with split-tunnel or bridge mode. However, tunnel mode requires traffic bound for the public Internet to first travel to the Aruba controller. Tunnel mode VLANs are completely isolated from split-tunnel and bridge VLANs, and so may not share local devices.

Figure 25 Tunnel Mode

Typically, Aruba recommends that most customers who want to send all traffic to the controller use split-tunnel mode with a policy-based ACL. However, tunnel mode is the best choice if the deployment has either of the following requirements:

Higher performance than split-tunnel mode can provide on the particular AP platform Layer 2 encryption across the WAN/Internet link

N O T E

Tunnel mode traffic from the wired port is always IPsec encrypted, regardless of the double-encrypt settings.

Table 11 Management Frame Processing–Tunnel Mode


802.1XProcessing Location

Probea


RAP RAP

802.11 Auth RAP RAP

802.11 Assoc Controller Controller

EAP n/a Controller

Key Exchange Controller Controller

RN

SG

_122

VoiceSSID

EnterpriseSSID

EnterpriseSSID

VoiceSSID

Guest/FamilySSID

Remote Location

Firewall /NAT-T

Internetor WAN

Websites

IPsec Tunnel

Enterprise LAN

RAP(no

firewall)

Internet Traffic

EnterpriseIP Phone

Shared UsePrinter

LANPC



Bridge Mode

Bridge mode wired ports or wireless SSIDs act in a similar fashion as a regular fat AP. While no traffic is forwarded to the controller, the RAP is managed centrally.

In bridge mode, wireless and wired traffic is bridged locally at the AP. Clients receive IP addresses from a local DHCP server in the RAP. Firewall ACLs are applied to traffic inside the AP, instead of at the controller. This mode is commonly used for the following applications:

SSID to serve non-enterprise family or guest users. In this case, the Aruba RAP can be configured to be the wireless network to serve the “rest of the family”, eliminating the need to have a separate AP for this purpose and providing a valuable benefit to employees.

SSID to provide backup connectivity when the link to the controller is down.

Bridge mode provides the highest resiliency from a failure to the link between the RAP and the controller. Therefore bridge mode is used in cases where the following conditions apply:

All traffic is local and the client can obtain IP addresses locally. Wireless service must be available even if the link between the controller and the AP is down.

N O T E

Each device on a tunnel mode VLAN counts towards the PEF license limit on the local controller.

Table 12 Management Frame Processing–Bridge Mode


802.1XProcessing Location

Probea


RAP RAP

802.11 Auth RAP RAP

802.11 Assoc RAP Controller

EAP n/a Controller

Key Exchange RAP Controller



Figure 26 Bridge Mode

Operating Modes

Each wired port and wireless SSID on a RAP has both a forwarding mode and an operating mode. The operating mode governs AP availability when the controller is not reachable, with a corresponding impact on the authentication types supported. For tunnel and split-tunnel modes, the “Standard” operating mode applies. For bridge mode, the network engineer has a selection of four different operating modes (including standard). These are summarized in Table 13.

N O T E

Devices on bridge mode VLANs do not count towards the PEF license limit on the local controller.

Table 13 Operating Modes

Standard Persistent Backup Always

Description Classic Aruba thin AP operation

Provides SSID continuity during temporary controller outages

Provides a backup SSID for local access only when controller is unreachable

Provides an SSID that is always available for local access

Forwarding Modes Tunnel Split-tunnel Bridge

Bridge Bridge Bridge

ESSID Availability Up only when controller is reachable

Must reach controller to come up; stays up if connectivity is temporarily disrupted.

Up only when controller cannot be reached

Always up when the AP is up, regardless of controller reachability

RN

SG

_123

VoiceSSID

EnterpriseSSID


Enterprise HQ

Voice SSIDVoice SSID

Guest/FamilySSID

(Bridge Mode-PSK)

Guest/FamilySSID

(Bridge Mode-PSK)

EnterpriseSSID

EnterpriseSSID

LAN PC

RAP(with firewall)RAP(with firewall)

Firewall /NAT-T

Internet orWAN

Websites

RemoteLocation Shared

UsePrinter

LocallyBridged

Data



Combined Forwarding and Operating Modes

The three forwarding modes presented in this section can be combined as desired to meet the needs of specific customer use cases. Each wireless SSID and wired port offered by an Aruba RAP may have a different forwarding mode. In the case of the fixed telecommuter, we typically see three roles, each using a different forwarding mode.

Figure 27 Mixed Wired and Wireless Forwarding Modes–Fixed Telecommuter

Enterprise Role (Split-Tunnel Mode with 802.1X Authentication)

The employee’s laptop uses this role to obtain a good balance of performance between corporate resources and addresses that are reachable directly over a public IP network. A local or family IP printer can easily be used by configuring the proper ACLs in the firewall policies on the RAP.

Voice Role (Full-Tunnel Mode with MAC Authentication)

If the company provides a Voice over Wi-Fi (VoFi) handset, this role provides service to that device with appropriate settings and encryption.

Family Role (Bridge Mode with PSK Authentication)

For the “rest of the family,” this role provides always-on access to the Internet. This role works regardless of whether the controller is reachable over the WAN. In addition, wireless traffic on this role can be bridged to a small switch located in front of the RAP to enable local peer-to-peer exchanges with other devices in the house, as well as local printing.

Supported Authentication Modes

802.1X supported 802.1X supported PSK ESSID only PSK ESSID only

SSID Configuration Obtained from controller Obtained from controller Stored in AP flash memory

Stored in AP flash memory

Table 13 Operating Modes (Continued)

Standard Persistent Backup Always

RN

SG

_128

VoiceSSID

EnterpriseSSID


EnterpriseIP Phone

Enterprise HQ

Voice SSID(Full TunnelMode-PSK)

Voice SSID(Full TunnelMode-PSK)

Guest/FamilySSID

(Bridge Mode-PSK)

Guest/FamilySSID

(Bridge Mode-PSK)

EnterpriseSSID

(Split-TunnelMode-802.1X)

EnterpriseSSID

(Split-TunnelMode-802.1X)

LANPC

RAP(with firewall)RAP(with firewall)

Firewall /NAT-T

Internet orWAN

Websites

Shared UsePrinter

RemoteLocation



AP/AM Data and Control TunnelsAruba APs and Air Monitors (AMs) maintain a variety of data and control tunnels with their active local and master controllers. It is important for network engineers to understand the various types of tunnels and where they terminate inside an Aruba architecture.

AP Tunnels

Figure 28 shows a RAP configuration with a mix of wired ports, wireless SSIDs and forwarding modes that various client devices use to connect. Data from these devices is tunneled through to the local controller in the DMZ using IPsec-encrypted GRE data tunnels. The air monitoring function uses Aruba Process Application Programming Interface (PAPI) control channels for ARM and Wireless Intrusion Detection System (WIDS) communication to the master controller. A separate PAPI control channel connects to the local controller where the SSID tunnels terminate.

Figure 28 Aruba WLAN AP/AM Communication and Tunneling

RN

SG

_106

Master

Local

GRE DataTunnels PAPI Control Tunnels

IPsec NAT-T UDP 4500

SSID“Enterprise”

(2.4 GHz)Split-Tunnel

Mode

SSID“Enterprise”

(5 GHz)Split-Tunnel

Mode

SSID“Voice”

(2.4 GHz)TunnelMode

SSID“Voice”(5 GHz)TunnelMode

Secure Jack(IP Phone)

TunnelMode

Secure Jack(Guest PC)

Bridge Mode

Secure Jack(Wired PC)

Split-TunnelMode

SSID“Guest”(2.4 GHz)

BridgeMode

SSID“Guest”(5 GHz)BridgeMode

AirMonitor

WIP Detection & Containment Traffic

Adaptive Radio Management Traffic

Management

NetworkAccess

Aggregation

Control



The number of tunnels that the AP constructs depends on the forwarding mode on each SSID. Tunnel mode: One GRE tunnel per SSID per wireless radio; plus one GRE tunnel per wired

port. Split-tunnel mode: All split-tunnel wired ports and wireless SSIDs are multiplexed onto a single

IPsec-encrypted GRE tunnel after the decrypt/encrypt process. Bridge mode: No GRE tunnel. PAPI control channel only.

Each GRE tunnel and each PAPI control channel has a separate heartbeat mechanism used to assess the health of the AP connection. The control overhead is approximately 1 Kbps per tunnel or channel. Be sure to factor this in when planning for RAP deployments over slow speed or high-latency links.

AM Tunnels

Dedicated AMs are not used in RAP deployments. Instead, RAPs are typically deployed in “hybrid” mode where they perform AM services part-time in between serving clients. The air monitor process running on the AP constructs two PAPI control tunnels back to the active master controller via the active local controller in the DMZ. One control tunnel is used for telemetry by the Aruba ARM system to select the clearest radio channel for each AP. The second PAPI tunnel transmits information used by the Aruba WIDS to guard against wireless threats.

IP Ports Used by Aruba Devices

This section describes the network ports that need to be configured on the firewall to allow proper operation of the Aruba network.

Between any two controllers: IPsec (UDP ports 500 and 4500) and ESP (protocol 50)

IP-IP (protocol 4) and UDP port 443 if layer3 mobility is enabled GRE (protocol 47) if tunneling guest traffic over GRE to DMZ controller

Between a RAP (IPsec) and a controller: NAT-T (UDP port 4500) TFTP (UDP port 69)

Establish a Routable IP Subnet to the Master Controller

For this reference design to operate properly, certain limited communication must be permitted between Aruba devices across the interior DMZ firewall. For example, the local controller periodically communicates with the master controller to report management information and to receive

N O T E

Split-tunnel and bridge mode are only available for RAPs. All campus-connected APs with onsite local controllers use tunnel mode.

N O T E

PAPI between a master and a local controller is encapsulated in IPsec in ArubaOS 3.x



configuration updates. RAPs also transmit ARM and WIP telemetry to the master on a regular basis. Therefore the network administrator is required to ensure that the master has IP connectivity to both the local controller and RAP inner IP address pool.

Specifically, ACLs should be added to the interior DMZ firewall to allow the following: The master-IP address must be routable from the local controller The L2TP pool used to assign RAP IP addresses must also be routable UDP port 8211 must be permitted between these endpoints

RAP Bootstrapping and Load BalancingThe bootstrapping process of a RAP occurs in phases:

The RAP obtains an IP address on the wired interface by using DHCP. In a telecommuter/home office scenario, the IP address is typically provided by the Internet service provider when directly connected to the Internet.

If the RAP has been provisioned with an FQDN for the master controller, the RAP resolves the host name by using DNS, otherwise it uses a static master IP address.

The RAP attempts to form an IPsec connection to the master controller through the Ethernet interface. The IKE PSK is used to complete phase 1 negotiation. The RAP's certificate or IKE PSK is

used to complete IKE phase 1 negotiation. The user name and password (device credentials) are used to authenticate the AP to

complete the setup of the IPsec tunnel. If IKE PSK is used then XAUTH will authenticate with user name/password. If authentication is successful then the RAP will get an inner IP address and an IKE SA is established between it and the controller.

N O T E

If it is not desirable to add a routable IP address to the Aruba controller, use an external router or firewall address and forward the traffic to an existing interface on the controller. Only NAT-T traffic (udp/4500) needs to be forwarded.



If certificate is used then XAUTH will authenticate with the MAC address in the CERT. If authentication is successful then the RAP will get an inner IP address and an IKE SA is established between it and the controller.

An IPsec SA is then established between the RAP and the controller. The master controller provides the IP addresses (primary and backup) of the local controller to

which the RAP is assigned. In smaller deployments where the master also terminates RAPs, this can be the same controller.

One or more IPsec-encrypted GRE tunnels are formed between the RAP and the designated local controller.

Any RAP may contact any of the Aruba controllers that have RAP licenses and whose IP address or FQDN have been provisioned in the nonvolatile memory of the AP. Where master/local architecture is used in the VRD, this can be either of the local controllers (the masters do not terminate AP tunnels). Aruba recommends provisioning the RAP to contact a DNS host name (such as “RAPcontroller.companyABC.com”) and configure the DNS servers to do load balancing amongst the public IP addresses of both controllers. This provisioning confirms that the RAP can bootstrap as long as any one of the controllers is reachable.

N O T E

Remote access points must be L3 separated from Aruba controllers. Never bootstrap a RAP when it is on the same VLAN as a controller.

RN

SG

_227

Extract RAP MACAddress fromCertificate andValidate Against LocalDatabase

IKE Phase 1 Security Association Within VPN Tunnel

Authentication Result (XAuth)

Inner IP Assigned (XAuth)

ACK (XAuth)

IPSEC SA

Inner IP Request (XAuth)

6 Frames Main Mode

3 Frames Aggressive Mode



This load balancing solution distributes the control load of accepting new RAP connections across controllers while also providing geographic load balancing.

Figure 29 Bootstrapping and Load Balancing Configuration

Controller High AvailabilityFor a larger scale RAP deployment operating as a production service, you must consider two different redundancies: network management redundancy and network operations redundancy. Two master controllers in the network at the Management layer provide management redundancy. Two local controllers working together to share a load at the Aggregation layer, with each local controller acting as a backup for the other, provide operational redundancy. This section explains the design and configuration for each.

DNS Server

San Francisco Data CenterMaster

San Francisco Home Office

New York Data CenterMaster

DNS Server

“rapcontroller.companyABC.com”=229.20.1.1

229.10.1.1 229.20.1.1

New York Home Office

RN

SG

_125

Internetor WAN“rapcontroller.companyABC.com”=

229.10.1.1



Master Controller Redundancy

To achieve high availability of the master controller, use the Master Redundancy method. In this scenario, the Management layer includes two controllers, with one configured as an “active” Master and one configured as a “standby” Master. The two controllers synchronize databases and run a VRRP instance between them, accessed by a Virtual IP (VIP) address. This is the address used for network administration and given to the local controllers, wired APs, and wireless APs attempting to discover a controller.

Figure 30 Active-Standby Redundancy

One controller is always the Active Master, and the other one is always the Standby Master. Users managing the system always log into the Active Master. Aruba recommends that customers not enable “preemption” on this setup. (Without preemption, a Standby Master that takes over as the Active Master remains in that state until manually switched back, even if the original Active Master comes back online.) This configuration is known as “Active-Standby” redundancy.

In Chapter 5: Physical Designtables were provided to help determine the appropriate controller model to serve as a Master. The recommended network attachment method is to have each controller configured in a full mesh with redundant links to separate data center distribution switches.

To provide active-standby redundancy (only one controller is active) there must be one VRRP (Virtual Router Redundancy Protocol) interface. The command sequence that follows shows the initial VRRP configuration that must be created on each master controller.

N O T E

Database synchronization is not enabled by default and must be explicitly configured. Refer to , “Example Configuration for the Fixed Telecommuter Scenario” on page 113 and , “Example Configuration for the Branch Office Scenario” on page 159 for a configuration example.

RNSG_043

StandbyMaster

VRRPkeepalives

Periodic databasesynchronization

ActiveMaster



Use the following commands to create the IP and VRRP configuration for the primary master controller:

Use the following CLI commands to create the IP and VRRP configuration for the backup master controller:

Periodic primary master-backup master controller synchronization must be enabled for the databases. Enabling synchronization must be configured on both the active and standby master controllers.

Use the following CLI command to enable database synchronization:

Use the following CLI command to configure the local controllers to use the virtual IP address as their master controller address.

vrrp 1

priority 120

ip address 172.21.98.100

vlan 98

authentication <password>

description Preferred-Master

tracking master-up-time 30 add 20

no shutdown

!

master-redundancy

master-vrrp 1

peer-ip-address <standby master IP> ipsec <key>

!

vrrp 1

priority 100

ip address 172.21.98.100

vlan 98


description Backup-Master

tracking master-up-time 30 add 20

no shutdown

!

master-redundancy

master-vrrp 1

peer-ip-address <active master IP> ipsec <key>

!

database synchronize period 30

database synchronize rf-plan-data

!

masterip 172.21.998.100 ipsec <key>

!



Local Controller Redundancy (VRRP Layer 2 Method)

There are two redundancy models for local controllers, which can be combined for geographically diverse scenarios. This section describes the VRRP (layer 2) method.

Local controllers terminating wired and wireless RAPs at the Aggregation layer use VRRP instances for redundancy, but in a different model than the master controllers at the Management layer. In this case, the controllers operate in what is known as “Active-Active” redundancy.

Figure 31 Active-Active redundancy

Using this model, two local controllers each terminate individual RAP tunnels on two separate VRRP VIP addresses. Each controller is the Active Local for one VIP address and the Standby Local for the other VIP. The controllers each terminate 50% of the access point load by specifying alternate VIPs when configuring the Local Mobility System (LMS) IP addresses during the RAP provisioning process.

arun

_044

RN

SG

_044

Keepalives

Active VIPStandby VIP

Local

Active VIPStandby VIP

Local



When the Active VIP for either local controller becomes unreachable, APs connected to the unreachable controller failover to the Standby Local through the VRRP Standby VIP mechanism, loading that controller to 100% capacity. Therefore, each controller must have sufficient processing power and licenses to accommodate all of the APs served by the entire cluster. In this model, Aruba recommends that customers enable “preemption” to force the APs to failback to the original controller when it comes back online.

Figure 32 Preemption Forces APs to Failback to the Original Controller

The configuration for each local controller is a mirror image of the other. In the following example, the first controller is primary on 23 and standby on 24:

vrrp 23

vlan 23

ip address 10.200.23.254

priority 100

preempt


description initial-primary-23

no shutdown

!

vrrp 24

vlan 24

ip address 10.200.24.254

priority 110

preempt


description initial-standby-24

no shutdown

!

arun

_045

RN

SG

_045

Local

Active VIPActive VIP

Local

Unreachable



The second local controller has an opposite configuration:

Local controllers typically need much more horsepower than masters, because they terminate the RAPs. This VRD recommends using the MMC-6000 chassis with redundant power supplies connected to at least two independent power sources and the M3Series controller blade. Configure these controllers with a “one-armed” connection to DMZ switches.

Local Controller Redundancy (LMS-IP Layer 3 Method)

RAP deployments may require a redundancy model that uses more than one data center to provide geographic diversity. Enable this model using the LMS-IP and Backup LMS-IP addresses, which provide inter-site redundancy in situations where sharing a VLAN is not desirable or possible (and hence VRRP cannot be used as the redundancy mechanism).

During the bootstrapping process, the RAP receives up to two LMS-IP addresses. These are the “Primary LMS address” and the “Backup LMS address” for the RAP to form an IPsec tunnel. If the primary LMS address becomes unreachable, the RAP will automatically construct a new set of tunnels to the controller on the backup LMS address. The backup tunnel is constructed only if the heartbeat mechanism on the primary fails.

vrrp 24

vlan 24

ip address 10.200.24.254

priority 100

preempt


description initial-primary-24

no shutdown

!

vrrp 23

vlan 23

ip address 10.200.23.254

priority 110

preempt


description initial-standby-23

no shutdown

!



In this design, both controllers must be of the same regulatory type (for example, US, Israel, or ROW) to comply with local laws.

Figure 33 Inter-Site Redundancy

Data Center 1Active

Home Office

Data Center 2Backup

Backup TunnelPrimary Tunnel

RAP configuration:Ims-ip = “a”bkupIms-ip = “b”

IP Address = “a” IP Address = “b”

RN

SG

_126

Internet orWAN



Customers can combine the layer 2 and layer 3 redundancy mechanisms to provide an extremely redundant solution. In this case, a pair of controllers (with a VRRP instance) provides intra-site redundancy while another pair of controllers (with another VRRP instance) is configured as the backup pair for inter-site redundancy.

Figure 34 Inter-Site and Intra-Site Redundancy Used Together

VLAN DesignOne of the most important features of the Aruba VBN architecture is the ability to virtualize user VLANs. An Aruba RAP can effectively multiplex many wired and wireless users on a frame-by-frame basis. Each user is placed in the appropriate VLAN for the role policy corresponding to their authentication credentials. During authentication, a process called ‘role derivation’ assigns the proper VLAN to each user and forwards traffic based on the policies defined for each role. These roles follow the user whenever they move between wired and wireless, or between different access points.

VRRP aVR IP = “a”

VRRP bVR IP = “b”

Data Center 1

Home Office

Data Center 2

RAP configuration:Ims-ip = “a”bkupIms-ip = “b”

RN

SG

_127

Internet orWAN



In Figure 35, two client devices are placed into individual VLANs by the controller following completion of the role derivation process.

Figure 35 Wired Devices Placed into Different VLANs Based on Logon Role

The user VLAN design will have implications for user connectivity and mobility across the network. To make sure that users do not overwhelm a single subnet, multiple VLANs can be configured to form a VLAN pool in the controller, which users will then be load balanced into dynamically.

Choosing the Default Router

The controller is a layer 3 switch that does not run routing protocols. In general, Aruba recommends that existing routers should remain the default gateways, unless there is a specific design requirement for the controller to be the default gateway. However, if multicast is used by customer applications or IGMP snooping is enabled then the controller must not be the default gateway. In this situation, the upstream router that has multicast routing support should be the default gateway.

RN

SG

_053

b

PBX

Application

300

200

Wi-Fi Voice(WPA2-PSK)

Internet orWANVLAN 200

VLAN 300

Employee(802.1X)



Chapter 7: Authentication and Security Design

This chapter introduces and explains the following topics: Wired and wireless Authentication methods. Authentication verifies that user credentials are correct, and encryption prevents listeners from capturing data sent through the air or over a wire. Service Set Identifier (SSID) selection. Use an SSID to identify a wireless

access point (AP) and its associated network. Different SSIDs are often associated with different levels of network access privilege.

Roles. Roles determine how your remote network assigns and enforces different security policies for wired and wireless clients such as mobile data terminals, voice handsets, and guest devices.

Profiles. In ArubaOS, profiles are configuration groupings that control the behavior of various parts of the system.

Wireless Intrusion Detection System (WIDS) operation. This chapter also explains how the Aruba system detects and contains rogue APs.

This chapter assumes that Table 2 on page 34 and/or Table 3 on page 35 from Chapter 4: Defining Requirements for Remote Networks have been completed.

Authentication Methods (Wired and Wireless)Each wired port and wireless SSID on a remote access point (RAP) must have an associated authentication method. The three most common authentication methods that can be used on both wired and wireless networks are 802.1X, captive portal and MAC address authentication. IEEE 802.1X is strongly recommended for branch office employees and telecommuter employees who have individual centrally managed login credentials.

A wireless user gains access to the network by attempting to associate to the AP with the strongest signal. The association request may have originated from a new user logging on to the network, or from an active user who has just roamed from elsewhere in the facility. The 802.11 MAC layer protocol association request is forwarded to the controller, which then attempts to retrieve the user’s state from the active user database. If the user was not active previously, the controller will proceed to authenticate the user via the authentication mode defined for the SSID. With 802.1X, it is coupled with back-end authentication mechanisms such as Remote Authentication Dial-In User Service (RADIUS), Active Directory, or Lightweight Directory Access Protocol (LDAP).

Wired users gain access to the network by plugging directly into the RAP, or into a layer 1 hub or layer 2 switch that uplinks to the RAP. Multiple wired authentication methods are available, including 802.1X and captive portal and MAC address authentication. These may be applied individually to different ports, or even combined on the same port using the role derivation process.

N O T E

Do not use a layer 2 switch in front of a RAP wired port if 802.1X authentication is in use.

Aruba Networks, Inc. Authentication and Security Design | 85


The controller can perform user authentication in multiple ways to suit the varying needs of an enterprise and the Authentication, Authorization, and Accounting (AAA) infrastructure currently in use. The typical authentication methods employed on Aruba networks can be summarized as:

WPA2 or WPA with PSK (wireless only) 802.1X based user authentication with a back-end server 802.1X PEAP termination on the controller Captive portal based user authentication Medium Access Control (MAC) address authentication A combination of authentication methods such as 802.1X followed by captive portal, or WEP

authentication followed by VPN

Although the Aruba controller contains a scalable local database for users and guests, it is a best practice to use the existing authentication infrastructure, which is typically engineered for redundancy and high performance. Aruba supports integration with external RADIUS, Active Directory, and LDAP servers.

Authenticating with 802.1X

802.1X is the most secure method of wireless security and also a robust method for wired ports. However, 802.1X requires client devices that are capable of supporting 802.1X, and a back-end authentication infrastructure with unique login credentials for each user.

802.1X was developed to secure wired ports by placing the port in a ‘blocking’ state until authentication was completed using Extensible Authentication Protocol (EAP). EAP is a framework that allows many different authentication types to take place within the EAP system; Protected EAP (PEAP) is most commonly used in wireless. In this mode, a Transport Layer Security (TLS) tunnel is created and user credentials are passed to the authentication server through the tunnel. When the authentication is complete, the client and the controller both have copies of the keys used to protect the user session.

Figure 36 802.1X Authentication Handshake

RN

SG

_057

Associate

Associate response

EAP request identity

EAP response

EAP exchange

RAPStation

802.11 Association 802.1X Authentication 4-way Handshake

Key1

Key2

Key3

Key4



Using RADIUS and a WPA2-protected connection as an example, authentication occurs using 802.1X. The controller forwards the request to the RADIUS server, which performs the actual authentication and sends a response to the controller. Once authentication completes successfully, encryption keys are passed to the controller from the RADIUS server, along with the user’s access policies. The controller then completes the role derivation process and adds the new user, along with all the relevant state information, into the active user database and completes the authentication process. A security context is created, and for encrypted links, key exchange occurs where all traffic is now encrypted.

Figure 37 RADIUS Server Authentication

If the user already exists in the active user database and attempts to associate to a new AP, the controller will understand that an active user has moved and will restore the user’s connectivity state and initiate mobility processing.

A compatible AAA server must exist in order to utilize 802.1X authentication. If a centralized AAA infrastructure exists that is queried across the WAN, it can easily be used for wireless and wired authentication. This is the more reliable solution with the least administrative cost. Verification of 802.1X authentication to the production AAA server is recommended either during staging or on the day of the installation.

ArubaOS uniquely supports AAA FastConnect, which allows the encrypted portions of the 802.1X authentication exchanges to terminate on the controller. Here the Aruba hardware encryption engine dramatically increases authentication scalability and performance with support for PEAP-MSCHAPv2, PEAP-GTC, and EAP-TLS, AAA FastConnect removes the requirement for external authentication servers to be 802.1X-capable and increases authentication server scalability by permitting several hundred authentication requests per second to be processed.

RN

SG

_056

ArubaController

1

5

3 4

3

AP

L2/L3Switch

CorporateBackbone

RADIUSServer

2

1.

2. 3.

4.

5.

Client sends 802.11 association request that isautomatically forwarded by the AP to the Aruba Controller

Aruba Controller responds with association acknowledgement

Client and Aruba Controller start 802.1X authenticationconversation along with RADIUS server

Encryption keys passed to the Aruba Controller, and user derivesown encryption keys, begins sending encrypted data

Aruba Controller decrypts data, processes packets, appliesservices and forwards packets based on 802.11 MAC



Authenticating with Captive Portal

For temporary visitors, including customers and vendors, Aruba supports a Web-based captive portal that provides secure browser-based authentication. Captive portal authentication is encrypted using Secure Sockets Layer (SSL), and can support both registered users with a login and password or guest users who supply only an email address.

The user plugs into a wired port or connects to a wireless SSID, which requires no authentication, and is placed in a state that requires a login. When the user opens a Web browser, a captive portal screen appears, asking them to enter either the credentials chosen by the employee for access, such as an email address, or to simply accept a set of service terms.

Figure 38 Aruba Captive Portal Screen

MAC Address Authentication

Use MAC address authentication to authenticate wired or wireless devices based on their network interface card media access control (MAC) address. While not the most secure and scalable method, MAC address authentication provides an additional layer of security for legacy devices that are not capable of advanced authentication modes. MAC-based authentication is usually used to authenticate and allow network access through explicitly identified devices while denying access to the rest. For example, wired and wireless voice devices are often secured in this way.

MAC layer addresses can be easily 'spoofed' by unscrupulous individuals and so this method of authentication provides only limited protection to the network. Therefore, Aruba does not recommend MAC authentication be used by itself unless the client device does not support any other authentication method.



Authentication Methods (Wireless Only)Dedicated wireless authentication methods include WPA and WPA2 with pre-shared keys (PSK), Wired Equivalent Privacy (WEP), and open access with no authentication or encryption. Pre-shared keys are often used on older devices, or devices that cannot handle full 802.1X authentication.

Wi-Fi Protected Access (WPA and WPA2) is a certification program administered by the Wi-Fi Alliance to indicate compliance with the security protocol created by the Wi-Fi Alliance to secure wireless computer networks. This protocol was created in response to several serious weaknesses researchers had found in the previous system, Wired Equivalent Privacy (WEP). WPA protocol implements the majority of the IEEE 802.11i standard, and was intended as an intermediate measure to take the place of WEP while 802.11i was prepared. WPA is specifically designed to also work with pre-WPA wireless network interface cards that pre-date the protocol (through firmware upgrades), but not necessarily with first generation wireless APs. The WPA2 certification mark indicates compliance with an advanced protocol that implements the full standard. This advanced protocol will not work with some older network cards.

WPA and WPA2 PSK mode (also known as personal mode) is designed for small or medium business networks that do not require the complexity of an 802.1X authentication server. Each user must enter a passphrase to access the network. The passphrase may be from 8 to 63 printable ASCII characters or 64 hexadecimal digits (256 bits). If you choose to use the ASCII characters, a hash function reduces it from 504 bits (63 characters * 8 bits/character) to 256 bits (using the SSID). In most operating systems the passphrase may be stored on the user's device at their discretion to avoid re-entry. The passphrase must remain stored in the wireless controller configuration.

SSIDs for Secure WLANsEach Aruba AP has the ability to appear to wireless users as multiple physical APs. Each of these virtual APs has their own Basic Service Set Identifier (BSSID) that identifies the AP and the network name, or Service Set Identifier (SSID).

SSIDs

SSIDs appear as the name of the network displayed in the Available Wireless Networks screen on a wireless client. While many APs in the same network will share the same SSID, each will have a unique BSSID. This feature is often used to let users know which SSID they should attempt to associate to, and to provide different levels of security to each of the SSIDs, such as WPA, WPA2, and Captive Portal.



Clients typically make roaming decisions based on the received signal strength of the audible BSSIDs they can hear.

Figure 39 Common SSID Types in Branch Office Facilities

Figure 39 shows a common SSID design for a remote branch office network, which includes four different SSIDs:

High Security SSID. A strong authentication and encryption combination (WPA2/802.1X) is used for newer network devices (in this case, WPA2 – Enterprise). The network administrator might choose a name such as “Branch Office Employee” for this SSID.

Pre-shared Key Security SSID. This SSID is used for older network devices not capable of modern high authentication and encryption levels. This SSID is temporary until these devices can be phased out. In this case, the controller uses an SSID such as “Branch Office-Legacy” and uses the strongest authentication and encryption suite supported by the devices; in this case, WPA-PSK (pre-shared key).

Voice/Video SSID. This SSID is used for wireless phones and in-house television monitors. In this case, the controller uses an SSID such as “Branch Office Voice.” Wireless phones and video monitors connect on this separate, dedicated SSID, and are given high priority through Quality of Service (QoS) and differentiated services code point (DSCP), and use WPA/WPA2 with PSK.

Guest SSID. This SSID is used to provide guest access to the network for customers and vendors. This SSID will not run any encryption and will require guests to authenticate using the Captive Portal capability that is built into the Aruba controller. The guest users can authenticate against a centralized authentication server or the built-in local database on the controller.

The strongest available level of security for a given class of devices should always be used. Always update the firmware or operating system to the most current version.

Role DerivationAruba uses the term role derivation to describe the process of determining which role is to be assigned to a user. The system can take into account the user’s credentials, location, time of day, and authentication type when deciding which role to assign. This system can be as detailed or as general as the administrator prefers. The role derivation process determines the following:

What class of service is provided to the user’s traffic

High SecuritySSID

Pre-Shared KeySSID

GuestSSID

RN

SG

_144

Voice/VideoSSID



Which firewall ACLs are applied to the user’s traffic Which VLAN the user is placed into

For detailed information on configuring Roles and Policies, see Volume 4 of the ArubaOS User Guide.

Network flow, security, and performance policies are applied to all traffic from users who have successfully authenticated into any wired port or wireless SSID. Policies are defined by means of a role derivation process utilizing the configuration profiles in the AP group assigned to that AP.

Figure 40 Role Derivation Flowchart

RN

SG

_225

START

PHY 802.11802.3

YES

NO

YES

YES

YES

NO

YES

YES

YES

NO YES

NO

NO

NO

NO

NO

NO

YES

YES

NO

NO

YES

YES

NO

NO

YES

Aruba VSA Derived Role/VLAN

User MAC (Example: 00:34:d4:ca:58:0f)Port ID (Example: FastEthernet 1/8)Tunnel ID (Example: Tunnel-109)

Trust

No VLAN derivation past this point

802.11 is always Un-Trusted

User Derived Role/VLAN Default Role/VLAN Aruba DSA Derived Role/VAN

BSSID (Example: 00:0b:86:12:fd:37)ESSID (Example: guest, contractor, staff)Location (Example: 10.0.0, 27.4.0, 41.2.5)User MAC (Example: 00:34:d4:ca:58:0f)Encryption (Example: WEP, TKIP, AES, etc.)

SERVER Derivation

ServerDerivation

ArubaVSA’s

ArubaDSA’s

Authenticated

EXIT TO DATA PATH

ESSIDLocationUser MAC

Aruba DSA’s

ESI ESI Derived Role/VAN

Logon Role/Default VLAN

Radius LDAP InternalAUTHENTICATION SOURCES

AUTHENTICATION SOURCESXML TACACS+

RadiusReturnedVSA’s

Authentication

Aruba-User-RoleAruba-User-VlanAruba-Priv-Admin-UserAruba-Admin-RoleAruba-Essid-NameAruba-Location-IdAruba-Port-Identifier

Radius VSA Derived Role/VLAN

Role/VLANAuto

Applied

VPNLogin?

CPLogin?

Is User inDatabase?

YES – Role and VLAN already derived in first pass(usually logon role and default vlan), this is

the second pass for VPN or CP authentication.

Authentication

USER Derivation

containsends with

equalsdoes not equal

starts withvalue of

containsends with

equalsdoes not equal

starts withvalue of

UserDerivation?

CollectArubaDSA’s

Collect Aruba DSA’s(Device Specific Attribute)

UserDerivation

will beoverridden

by laterprocesses

BSSIDESSIDLocationUser MACEncryption-TypeDHCP-opt-77

dot1xAuth

MACAuth



Figure 40 shows the logic tree associated with the role derivation process, which is applied individually to every wired and wireless device that attempts to authenticate to an Aruba network. For example, high-security and legacy users are placed on a VLAN with access to internal network resources; you can further refine this setup with sophisticated firewall rules applied on a per-packet basis. For example, a dual-mode Wi-Fi voice device is placed on a voice-only VLAN and only permitted to contact a SIP server and transmit RTP traffic. Any attempt by the device to do something else would automatically ‘blacklist’ that device from the network. Finally, guest users are placed onto a guest-only VLAN with access only to the default gateway leading to the Internet. No other facility or company network access is allowed.

Configuring Roles for Different UsersThe Aruba system uniquely combines user-based security as a part of the security model. When a user is authenticated, a role is applied to the user that is enforced via the firewall in the RAP and the controller in addition to the defined policies for that user. For example, a typical branch office uses the following role types for wired and wireless users:

Secure role for mobile wireless data terminals Secure role for stationary wired devices Voice or video Guest access

Secure Role for Mobile Wireless Data Terminals

Wireless users who are company employees can be granted access to secure data based on their specific job function, or simply be given a universal employee role. Additional qualifications for user access can be applied, such as permitting clerks to access a Point of Sale (POS) system but not the finance or accounting servers.

Secure Role for Stationary Wired Devices

Wired users who are company employees will typically be granted access to a subset of secure data based on their job function, or simply be given a universal employee role. Additional qualifications for user access can be applied, such as permitting access only to local printers.

Voice Handset Role

Special-purpose device access is similar to guest access and typically includes voice devices. Limit device access to a known set of IP addresses and port numbers. A voice device should only be able to run voice protocols such as Session Initiation Protocol (SIP) to the SIP server, Real-Time Transport Protocol (RTP), and basic Internet Control Message Protocol (ICMP) commands. Any other uses should result in the device being blacklisted, as it is most likely the subject of an impersonation attack.



Guest Access Role

It is not enough for guest users to be separated from employee users through VLANs in the network. Guests must be limited not only in where they may go, but also limited by what network protocols and ports they may use to access resources.

A guest policy as implemented by the stateful firewall should only allow the guest to access the local resources that are required for IP connectivity. These include DHCP and possibly DNS if an outside DNS server is not available. The Aruba firewall also allows for certain guest services such as printers and fax, which the firewall policies can allow if desired. All other internal resources should be off limits for the guest. This condition is usually achieved by denying any internal address space to the guest user.

Figure 41 Guest Access is Time Limited

Configure additional policies to limit the use of the network for guests. The first policy is a time-of-day restriction. The user should be limited to accessing the network during normal hours. Accounts should be set to expire automatically, typically at the end of each business day.

Figure 42 Guest Access is Bandwidth Limited

A rate limit can be put on each guest user to keep the user from using up the limited wireless bandwidth. Employee users should always have first priority to the wireless medium for conducting company business. Remember to leave enough bandwidth to keep the system usable by guests. Aruba recommends a minimum of 10% bandwidth. Guests can always burst when the medium is idle.

With appropriate levels of encryption and authentication for different users, the system is completely secured. The unique combination of these security mechanisms and Aruba Role-Based Access Control (RBAC) gives an Aruba remote network far more control and granularity of user traffic than simply demanding a particular type of authentication and encryption.

RN

SG

+067

No accessafter hours

Access controlled

RN

SG

_068

Mobilitycontroller

Data Controlleddata



Putting It All Together: Building an Authentication DesignThe key deliverable from this chapter is the authentication design for each major type of facility to be covered. The three main elements of an authentication design are:

AAA profile design SSID profile design Role policy design

This section explains the basics of Aruba profiles and how the SSID and AAA profiles work together to implement role-based access control.

What Is A Profile?

A profile is defined as a logical container consisting of a number of related configuration settings. There are nearly 30 different types of profiles available. To bring up a basic working SSID with limited security on an AP, only a SSID Profile is required. More complex configurations require more profiles to be defined, such as for high security SSIDs using 802.1X authentication. In this case, a AAA Profile is also required as shown in Figure 43.

Figure 43 Examples of Aruba SSID and AAA Profiles

Every profile must be assigned a unique name; names cannot contain any white space characters. The example SSID Profile on the left contains related values whose purpose is to define a specific 802.11 SSID that will be available for a specific group of users, in this case employees who typically authenticate against an organization’s AAA infrastructure. The example AAA profile above defines how 802.1X roles will be derived and which AAA server group will be used. As discussed previously, in

RN

SG

_077

SSID Profile“XYZ_Corp_Employees”

AAA Profile“XYZ_dot1x_AAA_Profile”

PropertiesNetwork Name = “Employee_SSID”Authentication = 802.1XEncryption = AES802.11g Rates = 1,2,5,6,9,11,12,18,24,36,48,54802.11a Rates = 6,9,12,18,24,36,48,54RTS Threshold = 2333 bytesHide SSID = NoShort Preamble = Yes

PropertiesInitial Role = Logon802.1X Default Role = “XYZ_Corp_dot1x_Role”User Derivation Rules = NoneWired-to-Wireless Roaming = Yes

Dependent Profiles

802.1XAuthentication Profile“XYZ_Corp_dot1x_Profile”802.1X

Server Group“XYZ_Corp_dot1x_Server” Max Auth Failures = 0

Termination EAP-Type = “EAP-PEAP”Termination Inner EAP-Type = “EAP-MSCHAPv2”

Name = “[email protected]”Server Type = RADIUSFail-Through = No

802.1X Server Group

802.1X Authentication Profile



a remote network deployment it is common to have separate SSID profiles for PSK devices, voice devices, and guests. Guests typically may authenticate through a captive portal, which would require other profiles to be defined to configure its operation. SSID profiles and AAA profiles can then be combined as desired to use different authentication servers for different groups of users.

Profiles are realized on the controller through the GUI or the CLI. In the web GUI, each type of profile has its own page, with all relevant parameters that are accessed through the Profiles tab on the Configuration page. Figure 44 shows the GUI for the preceding SSID Profile example.

Figure 44 Configuring an SSID Profile in the Controller GUI

N O T E

Profile names, AP names, and AP Group names must not contain any spaces or other white space characters.



Aggregating Profiles into a Complete Configuration

Profiles are combined in a building-block fashion to produce the desired functionality. In addition, most profiles are portable and reusable, allowing the administrator to reduce configuration complexity while simultaneously permitting almost any combination of profiles.

A basic example is the virtual AP profile which includes both virtual AP settings and other profiles in a hierarchical fashion. A virtual AP profile contains the VLAN number, a valid SSID profile, and possibly a AAA profile. Figure 45 shows how a common AP group for a remote network can be visualized.

Figure 45 Typical AP Group for Remote Networks SSIDs with Nested VAP Profiles

RN

SG

_079

AAA Profile“Guest_AAA_Profile”

Dependent ProfilesCP Server GroupCP Authentication Profile

AAA Profile“Voice_AAA_Profile”

AAA Profile“HighSecurity_AAA_Profile”Dependent Profiles

802.1X Server Group802.1X AuthenticationProfile

AAA Profile“Pre-Shared_Key_AAA_Profile”

Dependent Profiles802.1X Server Group802.1X AuthenticationProfile

AP Group“Small_Branch_Office_Group”

VAP Profile“Pre-Shared_Key_VAP_Profile”

VLAN = 200

VAP Profile“HighSecurity_VAP_Profile”

VLAN = 100

VAP Profile“Guest_VAP_Profile”

Captive PortalAuthentication Profile

“Guest_CP_Profile”

Captive PortalServer Group

VLAN = 300

VAP Profile“Voice_VAP_Profile”

VLAN = 400

802.1XAuthentication Profile

“Pre-Shared_Key_dot1x_Profile”

802.1XAuthentication Profile“HighSecurity_dot1x_Profile”

802.1XServer Group

SSID Profile“HighSecurity_SSID_Profile”

SSID Profile“Guest_SSID_Profile”

SSID Profile“Voice_SSID_Profile”

SSID Profile“Pre-Shared_Key_SSID_Profile”



You can configure and apply multiple instances of virtual AP profiles to an AP group or to an individual AP using the Configuration tab on the Controller GUI as shown in Figure 46.

Figure 46 Configuring a Virtual AP Profile in the Controller GUI

Consult the ArubaOS 3.3.2 User Guide Volume 4, “Configuring Wireless Encryption and Authentication” for detailed information about configuring profiles.

Planning AAA and SSID Profiles

In the Define phase of the remote network lifecycle, authentication mode and device type data was collected in Table 2 on page 34 in Chapter 4: Defining Requirements for Remote Networks. Separate tables may have been completed for each major facility type to accommodate different wireless authentication needs. We recommend that you follow this process:

Construct a list of wired port assignments in each facility type Construct a list of the wireless SSIDs that should be offered in each facility type Understand which device types will be used on which SSIDs Configure the necessary wired AP and SSID Profiles in the Aruba controller Understand which authentication modes will be used for which wired ports and wireless SSIDs Configure the necessary AAA Profiles in the Aruba controller Understand what roles are required, and the firewall policies for each Configure the necessary role policies on the Aruba controller

Decide on a naming convention for your profiles. The naming convention should include a marker for your base profiles that will allow you to recognize them as construction components and not active profiles. Best practices for profile naming appear in the next section. Also, in order to prevent illegal constructions (such as a virtual AP with two identical SSIDs), profiles must be constructed in a certain order. An example of profile construction is shown in the next section.



Example 802.1X Profile Configuration

This is an example deployment which will set up a new wireless SSID, “High Security.” It will run WPA2 and authenticate against a RADIUS server and a backup server. Authenticated users will be placed in the user role “Employees” on VLAN 200.

The procedure to build profiles is divided into three parts: basic setup, creation of security profiles, and creation of wireless profiles, and is performed in this order.

Basic Setup

Create the VLAN and Employee user role and its related policies.

Create Security Profiles

Because we are planning to use a wireless protocol that requires 802.1X (WPA2), we need to set up the profiles specific to 802.1X authentication. For this example, there are two major

profiles that must be defined: An 802.1X authentication profile: Describes how 802.1X works (PEAP vs. TLS, for example) An AAA profile: Defines how authentication is performed (including specifying a server group

and server rules, for example)

To set up these profiles, complete the following steps in sequential order.1. Define an authentication server in a server group. This is a pre-defined group of authentication

servers used by any or all authentication mechanisms such as MAC authentication or 802.1X. We’ll call ours Employee-RADIUS. Typically, after you configure this server, all other Authentication Profiles will use it.

2. Create an 802.1X authentication profile. This is where you configure 802.1X-specific information such as the fact that we are going to use PEAP-MSCHAPv2 termination.

3. Create an AAA profile. Now that 802.1X is configured, specify the initial logon and default roles, the 802.1X authentication profile, and the server group.

Create Wireless Profiles

Next, define the SSID and virtual AP information for the RAP by creating an SSID Profile and a virtual AP profile.

1. Create an SSID profile.This is where you specify the SSID name and the type of 802.11 security. If you want to use any other security besides open or a pre-shared key (WEP, WPA-PSK, or WPA2-PSK) you must have the server group, authentication profile, and AAA profile already configured and ready to go. These profiles are the building blocks required to build a legitimate SSID profile.

2. Create a Virtual AP profile.In this step you will assign an SSID profile, the AAA profile that accompanies it and optionally the VLAN that is assigned to the SSID.



3. Apply the Virtual AP.The final step in the process is to apply the settings. Under AP Installation, select the APs you wish to configure with your new AP group. After an AP group is assigned to your APs, they will reboot and the new group settings will take effect.

Best Practices for Profiles

Profiles can be divided into one of two basic types: LAN definition and security definition.

As part of the building block approach to profile creation, we recommend that you create the minimum number of profiles required with the maximum amount of profile reuse. This approach can be generalized as follows:

Authentication Servers and Server Groups

1. Create a server group for each type of server.a. RADIUS_Serversb. LDAP_Servers

2. If multiple groups of the same type of servers exist, specify the unique application for each group within its name.a. NorthAmerica_RADIUS_Servers b. EMEA_RADIUS_Servers

3. If further distinction is necessary, add these servers:a. EMEA_Corp_RADIUS_Servers b. EMEA_Guest_RADIUS_Servers

AAA Fast Connect

If using 802.1X with EAP Type PEAP, configure the 802.1X authentication profile for termination.

User Role Assignment

1. Always place unauthenticated users in an initial role with the minimum possible privileges or access required.

2. Use server derivation rules if multiple types of users (employees, contractors, phones) will authenticate using the same authentication method (such as MAC or 802.1X) on the same virtual AP.

3. Use the default role assignment within the AAA profile if each type of user or device authenticates using a different authentication method.

N O T E

All APs configured in a mass configuration must be of the same type, but an AP group can contain APs of various types.



SSID Configuration

When planning wireless SSIDs:1. Use the minimum SSIDs possible to keep radio beacons and RF contention and management to

a minimum.2. Use the Aruba firewall and user roles to keep different groups of users separated from each

other or from network resources.3. Do not mix different types of wireless security on the same SSID. For example: 802.1X and

WPA security on the same SSID.4. If it is desirable to eliminate some of the slower transmit rates supported by an SSID, allow at

least two speeds. Do not remove all but the highest rate.

Virtual APs

Do not enable strict compliance unless there is legacy wireless equipment.

Wireless Intrusion Detection System Operation and DesignThis section discusses the operation of the Aruba wireless intrusion detection system (WIDS).

Detection of Rogue APs

Before an AP can be classified as a rogue the AP must first be detected, along with any stations that associate to it, and the wired devices with which it attempts to communicate. Detection is the key to all rogue AP functionality.

To detect wireless devices, both APs and air monitors (AMs) scan the air looking for new devices and keep tabs on existing devices. How APs and AMs scan is quite different.

Hybrid-mode or scanning APs only scan the channels within the regulatory domain. This means that an AP will never detect a wireless device that is operating on an illegal channel. Because it is possible to carry APs across international borders and even configure an illegal channel on some APs, you should keep this in mind when deploying RAPs with WIDS.

To correctly classify rogue APs, each Aruba AP and AM must also see specific traffic on the wire. Special VLANs should not be used to aggregate Aruba APs and AMs. When placed on isolated “AP VLANs”, the WIDS system cannot correlate wired and wireless traffic. In addition to scanning the air, they scan the wire, recording MAC addresses and looking for routers and gateways. Gateways are used for classification. They are the default gateways used by the APs. Their MAC addresses are propagated by the Aruba controller to all of the APs in the RF vicinity. Routers are detected by inspecting the time-to-live (TTL) of received traffic. If the TTL is 31, 63, 127, or 254, the sender is most likely a router. Routers are possible wireless gateways (layer 3 APs). They have to be manually inspected by the user to determine if they are valid devices.

Each AP and AM maintains a list of all other APs, stations, gateways, and wired MAC addresses it can see. Each AP and AM also maintains a list of associations (which stations are associated to which APs). The amount of information stored is capped and this information is aged out when the specific device is inactive for a configurable period of time. This capping allows the AP to conserve its memory and eventually stop any containment activities.



Classification of Rogue APs

All wireless devices are classified as valid, interfering, known-interfering, suspect-unsecured, unsecured/rogue, or denial of service (DoS), as shown in Table 14.

There is no difference between APs and AMs with respect to classification.

To correctly classify an AP as a rogue, an Aruba AP must be able to both hear the AP and be a member of its wired broadcast domain or VLAN. If there are many VLANs in the area, all of these VLANs should be trunked to each Aruba AP for maximum protection.

Once an Aruba AP has classified an AP, the controller is notified, which pushes the classification to the other Aruba APs. For example, assume three Aruba APs can hear an interfering AP. One of them can see the wired traffic and classifies the AP as a rogue. This AP notifies the controller, which pushes the rogue classification to the other two APs, so that they can also attempt to contain it.

Table 14 Possible AP Classification Types in Aruba WIDS

AP Type Description

Valid AP An AP that has bootstrapped with a local or master controller or has been manually marked as valid. Valid stations have passed encrypted traffic with a valid AP.

Interfering AP An AP that is not valid but has not been classified as a rogue. All non-valid APs are always classified as interfering.

Known Interfering AP An AP manually classified as interfering. Such an AP cannot be automatically classified as a rogue.

Suspect Unsecured AP An AP that could be a rogue, but the certainty is not 100%.

Rogue AP An interfering AP that transmits frames from valid wired MAC addresses (if an L2 AP), or transmits beacons that are adjacent to a wired MAC addresses (if an L3 AP).

DoS (denial of service) An AP that has been manually contained.



Chapter 8: Deploying Aruba Remote Networks

This chapter describes deployment processes, provisioning methods, and project management requirements that have been used to successfully roll out Aruba remote networking solutions for both branch offices and fixed telecommuters.

Aruba Deployment Process for Remote NetworksAruba recommends a six-step process for large-scale remote network rollouts. The general deployment sequence is shown in Figure 47.

Figure 47 Six Step Rollout Process

Step 1 – Deploy Data Center

The data center is the key to any remote network deployment. All RAPs home to a centralized computing facility that contains all of the fundamental infrastructure required to provide the remote network service. The data center houses the master controllers that are responsible for overall management of the remote endpoints, as well as the local controllers installed inside the DMZ. AirWave servers are also typically installed at the data center.

In order to bring up the Aruba components at the data center, integration is required with infrastructure elements, including enterprise LAN routers, distribution switches, firewalls, authentication servers, DHCP and DNS servers, and syslog servers. For voice deployments, integration with the appropriate call manager system and/or private branch exchange (PBX) may also be required. The specific configuration changes needed for each of these elements should be completed prior to installing the pilot sites.

The Aruba master and local controllers should be configured to support the remote networks being installed. The required licenses selected in Chapter 5: Physical Design should be installed. All groups, profiles, and roles should be defined and configured on the master controllers, and this configuration should be pushed to the local controllers on the DMZ. The local controllers on the DMZ should be configured to terminate the RAPs, and the MAC address of the RAPs being deployed for the pilot sites should be configured in the whitelist on the local controllers.

RN

SG

_111

Ret

ail_

100

Step 1Deploy

Data Center

Step 2Install

Pilot Sites

Step 3ProvisionBackhaulCircuits

Step 4Train

Help Desk

Step 5Stage SiteEquipment

Step 6Execute

FullDeployment

Aruba Networks, Inc. Deploying Aruba Remote Networks | 103


A basic checklist of activities to successfully deploy the data center portion of an Aruba network includes:

Order/update backhaul services at the data center, if required. Order properly-sized master and local controllers along with the required software licenses. Assign an IP address range large enough to accommodate the expected RAP count several

years into the future. Update the scopes on the enterprise DHCP server if required. Provision ports on distribution switches if required in support of master and local controllers. Update enterprise firewall configurations to provide dst-nat for inbound NAT-T traffic to local and

master controllers as well as to outbound src-nat traffic. Update enterprise router configurations to provide for a routable IP path to the master controller

for RAPs to authenticate during the bootstrapping process. For remote voice deployments, update call manager systems, including the PBX if appropriate,

in support of new extensions that will exist physically off-premise but will appear on-premise. Develop the configuration for the controllers using the example templates and worksheets in the

Appendices of this guide. Use the Aruba License Site to activate the license certificates purchased with the controllers and

obtain valid license keys for installation. Install the controllers into prepared locations on either side of the the enterprise DMZ. Load

license keys and program the prepared configurations. Validate the data center configuration by installing one of the pilot site RAPs on an external

backhaul. Obtain an Aruba Support Site account for ongoing access to technical documentation, software

updates, and Knowledge Base access. (This account requires a current ArubaCare support contract.)

Step 2 – Install Pilot Sites

After the data center is running smoothly, the remote network site equipment for a limited number of pilot sites should be installed. Aruba recommends that pilot locations meet the following criteria:

Target between five and twenty locations to provide a good mix of WAN links, site equipment types, and user populations.

If sites fall into distinct categories, be sure to include some sites of each type as pilots. For example, customers with both branch offices and fixed telecommuters should pilot both groups separately. For enterprises with branch offices that have significantly different IT footprints, some of each type should be included as pilots.

Verify that all enterprise client devices that will be supported on the remote networks are in use at the selected pilot sites.

If 3G wireless is being considered for backhaul, Aruba recommends the pilot include a mix of both wired and wireless 3G sites for comparison purposes. Consider comparing the performance of different wireless carriers during the pilot phase.

If wired WAN link speeds or latencies are expected to vary widely, target sites with differing types of connections. This may require a visit to candidate sites to characterize and qualify wired WAN links.



If RAPs will be located in multiple countries, Aruba recommends piloting sites in each country to evaluate WAN performance.

Target sites with close proximity to each other, subject to WAN diversity objectives listed above, and to enterprise IT resources.

Select cooperative branch office managers with experience participating in new technology trials.

Select cooperative employees with experience participating in new technology trials.

Larger enterprises will need more pilot sites. Allow at least four weeks of operation to confirm that all design issues and client device optimizations have been adequately exposed.

Plan to achieve the following critical objectives during this pilot phase:1. Perfect the physical and logical network design.2. Finalize the “golden” controller and RAP configuration.3. Identify the optimal client device settings for RAP operation.

Performance of the design over the WAN should be evaluated in course of the pilot. This is also an excellent opportunity to test master and local controller failover.

Operating pilot sites greatly reduces the project risks during the Full Deployment phase. While the centralized nature of an Aruba remote network makes configuration changes to the network itself very simple, having to retouch or reconfigure remote devices may be costly and disruptive to users.

Step 3 – Provision Backhaul Circuits

There are multiple considerations when selecting WAN links for backhauling the remote networks to the local controller. During the pilot stage, several diverse types of WAN connectivity were likely evaluated. Now it is time to order and provision individual circuits for the full deployment.

Some of the considerations in selecting and provisioning the backhaul(s) to use for the remote networks deployment are:

Ability of the service provider to offer IP “dialtone,” including dynamic IP address assignment for the RAP.

For branch office deployments, whether existing WAN circuits are meeting minimum speed and latency requirements.

For telecommuter deployments, whether the employee already pays for broadband internet service and whether this expense will be reimbursed by the organization.

For 3G wireless deployments, availability of service at each individual site location. For international deployments, whether WAN circuits that meet minimum speed and latency

requirements are available.

Planning for the installation or upgrade of backhaul services is a critical factor for a successful deployment. The lead-time for ordering data circuits varies by geography, service provider, and season. For large-scale deployments that are geographically dispersed, it is imperative that an installation timeline be discussed with the selected service providers well in advance. Typically, adding two to three weeks to the service provider’s projected installation date will provide an adequate margin of safety in the Americas; elsewhere it may be prudent to budget a contingency window of 6-8 weeks.



The key steps of the ordering process for wired circuits are:1. Identify all site addresses.2. Inventory all existing circuit IDs and link types.3. For each site, determine whether to order new service or to upgrade the existing circuit.4. For each site, select the customer-premises equipment (CPE) device for connecting to the RAP

uplink port (fastethernet/0).5. Once the circuit is confirmed to be available, schedule the site for installation.

Similarly, the key steps for ordering 3G wireless backhaul are:1. Identify all site addresses.2. If the site count is large enough, negotiate a bulk agreement with desired wireless carrier(s).3. Choose a USB 3G wireless modem that is compatible with the selected service provider and the

RAP.4. Complete a 3G wireless site survey at each location with the selected equipment configuration.5. Order the 3G service for all sites that pass the survey. Delivery of the modems can be directly to

the site, or to a central staging center, depending on the deployment method selected. 6. Schedule the site for installation.

Step 4 – Train the Help Desk

Now it is time to prepare the technology support desk for the pending deployment. Depending on how your organization handles technology pilots, the help desk may have already been engaged during Step 2. In any case, help desk staff training should capitalize on the lessons learned during the pilot test and the diagnostic procedures that were developed during that phase.

The help desk organization may already field calls from branch office and telecommuter employees reporting network and device problems. However, the pending remote network deployment may increase the number of sites significantly. Help desk management will need to know the install schedule, expected number of new sites by week or month, and the equipment footprint going into each site.

The help desk needs to locate the remote user quickly (preferably by username), to determine in which remote site he or she is located, view real-time performance and usage data, and access historical information for diagnostic purposes. One help desk group may be responsible for all sites or the responsibility may be assigned to multiple, smaller help desks segmented by geography or type of remote network installation (branch office or fixed telecommuter, for example). This help desk team usually has no administrative privileges for changing network settings or security policies.

The AirWave system includes displays optimized for help desk teams that enable these requirements. The AirWave Management Platform (AMP) has help desk-specific screens that provide a snapshot of incidents, allowing staff the ability to quickly drill down and diagnose an end user-reported issue. AMP offers a visual navigation mode that works very well if the help desk knows the site location. Otherwise, a search mechanism will quickly find all instances of a user on the network based on their login name, MAC address, or other parameters.



The basic checklist of help desk training activities recommended by Aruba includes: Basic operation of help desk-related screens in AMP. Set up a RAP for each help desk agent that will be taking calls. Basic operation of the RAP, including user-side diagnostic screens.

If the help desk was not involved in the pilot sites, it is a good idea to transition those sites to the help desk once training is completed. This allows help desk staff to begin gaining day-to-day experience with the processes and procedures required for support of the sites targeted for deployment.

Step 5 – Stage Site Equipment

The next step is to prepare the site equipment that will be deployed including the RAPs. Aruba supports two different provisioning methods: Zero touch and Pre-Provisioning. These methods are discussed in detail later in this chapter.

During this step, the master controllers will be programmed with the MAC addresses of all of the RAPs. For international deployments, it will be necessary to confirm that each RAP is assigned to an AP Group with the proper country code to comply with local laws regarding radio operation.

Another factor for international deployments is the selection of the AP power supply. The RAP-2WG, RAP-5, and RAP-5WN come in region-specific variants with appropriate power connectors. Be sure to forward the right equipment for each country.

In addition to the RAPs, there may be other equipment that will be distributed to the site as part of the deployment. Fixed telecommuters may receive a wired or wireless voice device. A branch office may receive updated data or voice devices. A wired modem CPE device, or a 3G wireless modem may be included. This equipment must be procured, grouped by site, configured, and then forwarded to the proper address.

Step 6 – Execute Full Deployment

The final step is to carry out the full deployment to all sites to be included in the production remote network. The process followed will likely be different for branch office and telecommuter sites:

Branch office deployments are often handled by IT personnel or systems integrators who have been hired to visit individual sites. The pre-provisioning model is most appropriate for this scenario, where all equipment is prepared in advance and shipped to the location. It is common that other site equipment changes are made at this time by the same team, such as providing new mobile devices or reprogramming old ones to work with the new system. Many branch offices may be installed each day, with the overall deployment timeline and resources controlled by a project manager.

By contrast, fixed telecommuter deployments are most often self-installed by each employee. The zero touch provisioning model is likely the best fit for this environment, where the RAP is shipped directly to each employee and they perform a few simple steps to complete the process. It is rarely the case that on-site support is required for fixed telecommuter deployments.

Either way, depending on the number of remote sites being deployed, outsourcing the staging or deployment work to experienced third-party systems integrators may be prudent. This is especially true for large, nationwide rollouts. If properly trained, systems integrators can efficiently perform controller programming, staging, and logistics functions. Aruba has relationships with and can recommend experienced third-party integrators to assist with these tasks.



Recommended Provisioning MethodsAruba customers can adopt either of two provisioning methods as a best practice for remote network deployments. The choice of method is determined solely by the cost to send installers onsite, and whether the end user can or should be expected to perform certain simple tasks to activate an Aruba RAP. Table 15 describes the available methods.

Zero touch and pre-provisioning methods are shown in Figure 48.

Figure 48 Zero Touch and Pre-Provisioning Methods

Provisioning refers to the process of programming the APs to find their controller and optionally assigning their physical location on an electronic floor plan in order to show real-time heat maps on a controller. We consider each of these provisioning methods in detail below.

Table 15 RAP Provisioning Methods

Method Description Selection Criteria

Zero Touch Provisioning

RAP is drop-shipped directly to the site No pre-touch of the RAP by the IT group is required.

(MAC address must be entered into a whitelist on the master controller.)

User self-installs after receiving the AP.

Home-based employees or very small branch offices.

AP with security certificate and provisioning image (RAP-2WG, RAP-5, RAP-5WN)

Controllers with security certificate (3000 Series, M3 blades)

Pre-Provisioning RAP is connected to a LAN-accessible controller at a staging site and programmed.

RAP is shipped “ready to go” to the site (possibly along with other equipment to be installed).

Medium or small branch offices where employees are not allowed or expected to make equipment changes.

AP without security certificate or provisioning image (AP-65, AP-70, AP-120 Series)

Controllers without security certificate (800 or 2400 Series, Supervisor II blade)

RN

SG

_221

ship

ship ship ship

Site-to-SiteVPN

Pre-Provisioning Method

Site EquipmentRemote AccessPoints Remote Access

Points

StagingCenter

Site # 2 Site # 3Site # 1

DataCenter

ship ship ship

Certificate-Based Whitelist Authentication

Zero Touch Provisioning Method

Site # 2 Site # 3Site # 1

DataCenter

LoadWhitelist



Zero Touch Provisioning

The Aruba RAP-5 and RAP-5WN include Trusted Platform Modules (TPM) that are preloaded with a unique security key at the factory. The RAP-2WG includes a security certificate that is stored in flash memory. All three of these RAP models also include a provisioning software image that includes the zero touch feature. When combined with the 3000-series standalone controller or the M3-series blade that also include a TPM and key, a low-cost provisioning model becomes possible. This model is particularly attractive for telecommuter deployments.

Aruba calls this zero touch provisioning, meaning that the IT organization simply pre-programs the MAC address of each authorized RAP into a whitelist on the master controller before shipping it to the end user. The IT professional can do this without having to plug the AP into the controller, and the AP remains in its packaging untouched. Once received at the site, the end user simply enters the IP address/hostname of the local controller into the provisioning screen on the RAP. The RAP exchanges keys automatically with the controller and completes the provisioning process with no further manual intervention. An optional one-time successful RADIUS authentication step may also be used for extra security.

Because zero touch provisioning takes advantage of the Aruba AP auto-discovery features and certificate-based authentication, RAPs can be shipped directly to each site location, as opposed to being shipped first to a staging center; MAC address documentation and controller whitelist configuration can be performed once the APs arrive at the remote site. This allows the customer to avoid having to pay twice to ship and house the APs for the staging process.

Pre-Provisioning

Pre-provisioning refers to the process of provisioning the APs before they arrive at a site. This is most often done when an IT team or system integrator will be travelling to each location to install/refresh multiple pieces of equipment, and it is not possible or not desirable for site employees to perform IT tasks themselves.

With pre-provisioning, a staging center is required to prepare equipment to be delivered to the remote locations. The Aruba RAPs are unpacked, configured, and verified at the staging center prior to final delivery. The staging center should have secure LAN connectivity to the data center where the controllers are housed so that RAPs can connect to the controller.

Once the RAP comes up on the controller, it first updates its software image if necessary. An Aruba administrator then completes the provisioning process by assigning the unit to the proper AP Group and choosing an authentication method. Both pre-shared keys and certificates are supported. Aruba supports bulk provisioning of large numbers of RAPs at the same time. Once completed, the RAP can be disconnected and prepared for shipment.

Site Procedure for Zero Touch MethodThis section describes the general steps to follow for zero touch provisioning of APs. These procedures are provided to help customers and their systems integrators prepare for a successful Aruba deployment. They should be customized for the unique needs of each organization.

In this scenario, the RAPs are shipped directly to the site. During the installation at the site, any AP can be mounted in a preselected location.



Pre-Installation Checklist

The following tasks must be completed before installing the RAPs:

Verify that the RAPs have been delivered to the remote sites with appropriate SKUs for country power requirements.

Verify that the backhaul connectivity and any required CPE device are available at each remote site (wired and/or 3G).

Confirm that a suitable RAP location has been selected with these attributes: Power is available. If the 802.11 radio will be used, the RAP location is in the center of the site to make sure that

the signal is strong everywhere. WAN service provider CPE device is within reach (if this is not the same location as the radio,

an Ethernet cable must be run from the CPE to the RAP).

Site Installation

At the installation site:

1. Unpack the RAP.2. Install the RAP as desired.3. Connect the RAP to the WAN service provider CPE device using the fastethernet/0 uplink port.

Provisioning the RAPs

For detailed information about provisioning the RAP, refer to the Release Note for Aruba OS version3.3.2.x-rn3.0.

The RAP must now be instructed to connect to a local controller in the enterprise DMZ. To establish this connection, perform the following steps:

1. Connect a desktop or laptop to any other Ethernet port on the RAP.The PC will receive an IP address from the RAP internal DHCP server.

2. Open a Web browser and navigate to any URL.The browser is automatically redirected to an Aruba management web page inside the AP that requests the IP address or DNS-resolvable hostname of the local controller in the DMZ.

3. Enter the hostname or IP address provided in the installation documentation.The RAP connects to the local controller. Then the following events occur: The local verifies with the master controller that the RAP appears in a whitelist, and to what

AP Group the device belongs. If authenticated, the RAP updates its software image if necessary, and downloads its

configuration. Depending on the speed of the link, this takes approximately five minutes. The RAP reboots, after which it begins offering the expected services over the air and on

secure wired ports. For detailed information about the bootstrapping process, refer to , “Logical Design” on page 59.



Site Procedure for Pre-Provisioning MethodThis section describes the general steps to follow for pre-provisioning the RAP at a staging center. These procedures are general in nature, and must be customized for the specific details of each customer.

In this scenario, the RAPs are shipped to a staging center and, after provisioning, shipped to the remote sites.

If other equipment is being installed, the staging center should have sufficient bench space to allow a steady flow of RAPs and associated site equipment to be configured and distributed appropriately for testing.

Pre-Installation Checklist

The following tasks must be complete before the RAPs are installed: The staging area has been acquired and equipped with secure LAN connectivity to the

enterprise network. The RAPs have been delivered to the staging area with appropriate SKUs for the target country

power requirements. Preselected RAP location information has been gathered and entered with the MAC address

into a form that was shipped with the RAP to the installation site. The RAPs are connected to L2 switches. (RAPs must be L3 isolated from the controller via a

router for this step.)

Provisioning the RAPs

For the specifi8c details of provisioning the RAPs, refer to the Release Note for Aruba OS version3.3.2.x-rn3.0.

Site Selection

Verify that a suitable RAP location has been selected with these attributes: Power is available. If the 802.11 radio will be used, the RAP should be located in the center of the site to make sure

that the signal is strong everywhere. WAN service provider CPE device is within reach. (If this is not the same location as the radio,

an Ethernet cable must be run from the CPE to the RAP.)

Site Installation

At the installation site:1. Unpack the RAP.2. Install the RAP as desired.3. Connect the RAP to the WAN service provider CPE device using the fastethernet/0 uplink port.

(If 3G wireless is being used, plug in the customer-provided 3G modem into the USB port on the RAP.)



Site Validation ConsiderationsIt is a best practice to develop a standard site checkout and validation procedure to make sure that all sites are fully functioning. Some common techniques are briefly described in the following sections. As with the procedures discussed previously, these must be adapted for each individual customer’s logical, RF, and security design, as well as the customer’s unique client device population.

Cabling and RAP Validation

Perform the following cabling tasks when new wiring is required to complete the installation: Require the installer to scope each pulled run and print the test results. Perform a visual inspection of all installed equipment to make sure that cables are dressed in

and the RAP status lights are correct.

Client Device Validation

A complete onsite validation test requires device-specific verification. Potential tests could include: Perform a continuous “ping” test to see if application servers, RAPs, and controllers can be

reached from wired devices and from mobile wireless devices at various locations within the site. Verify that any dropped packets are below a prearranged threshold.

Perform an appropriate basic client device functionality test with each type of device used by site employees and verify proper operation in a number of locations. Test each wireless SSID and wired port.

Complete detailed client device tests (for example, measure MOS scores on a voice handset while roaming around).



Chapter 9: Example Configuration for the Fixed Telecommuter Scenario

Organizations with many fixed telecommuters typically have a requirement to extend a fully functional secure wired and/or wireless footprint into the employee home. For example, call centers that employ home workers must deliver full voice services to off-premises wired phones as well as data services to a PC. Financial services companies may duplicate the entire office infrastructure at an

employee home, including voice and data services, for business continuity in the event of a catastrophic facility loss.

Because they work at home, fixed telecommuters also have to consider the needs of their families. Home Internet access is needed for children at school, spouses working from home, and family entertainment. It makes little sense to pay for two Internet connections to a house, if indeed there are even enough wired copper connections available. Employers understand that providing this service for full-time home-based employees is an effective retention tool that is highly valued, so long as the IT management burden is not increased.

The Aruba remote network solution fully meets the needs of both employers and families. By leveraging the built-in firewall in the Aruba remote access point (RAP), the enterprise can provide secure basic services needed by the fixed telecommuter to do his or her job. In addition, by harnessing the Aruba solution’s built-in bridging capabilities, the family can be online without imposing any additional IT management cost.

Simplified Design for the Fixed TelecommuterThis chapter presents a simplified design for a common fixed telecommuter configuration. This template can be easily adapted to suit the specific needs of each customer. Chapter 10: Example Configuration for the Branch Office Scenario on page 159, presents a reference design for a typical branch office.

The following assumptions are made for the fixed telecommuter use case: Master/local controller design. Each RAP connects directly to the Internet via a customer-premises equipment (CPE) device

such as a DSL or cable modem. A RAP with at least four wired ports is used. Each wired port on the RAP is statically assigned to

a specific function: Port 1: Wired enterprise access (802.1X authentication via split-tunnel forwarding mode) Port 2: Wired voice handset (MAC authentication via tunnel forwarding mode) Port 3: Family general access (open authentication via bridge forwarding mode) Port 4: Family general access (open authentication via bridge forwarding mode)

Three separate wireless SSIDs for Enterprise, Voice, and Family will be broadcast for over-the-air access.

Enterprise users can reach the shared printer on the family VLAN via a one-way ACL.

Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 113


The simplified example configuration in this chapter differs from the reference design presented in earlier chapters in that it omits:

Redundant master controllers (active/standby configuration) Redundant local controllers (active/active configuration) Dual AP groups to load-balance RAPs across redundant local controllers Separate wired and wireless 802.1X Authentication Profiles for flexibility

In addition, the fixed telecommuter scenario has no Provisioning profile. Provisioning profiles assume identical configurations in all premises equipment. This scenario is less likely for telecommuters who use zero touch provisioning.

A network diagram of the fixed telecommuter reference model is depicted in Figure 49.

Figure 49 Network Design for the Fixed Telecommuter Example

RN

SG

_116

FamilySSID

VoiceSSID

EnterpriseSSID

Enterprise

Enterprise

Voice

Voice

MasterController

LocalController

RADIUS

SIP Server

RAP IP Pool

ge1/3172.21.98.251

ge1/199.99.99.14

99.99.99.1

99.99.99.00/24VLAN 214

LMSIP = 99.99.99.14

172.21.98.0/24VLAN 98

172.21.99.0/24VLAN 99

10.168.115.225 -10.168.115.239

172.21.99.250ge1/2 (.1Q)

192.168.177.0/24Alias = “family_network”

VLAN 177Fwd Mode = Bridge

DHCP Start = 192.168.177.100DHCP End = 192.168.177.254

172.21.98.1(Router configured to routeRAP IP Pool & Local to Master)

10.0.0.0(Static Route from Local)

172.21.99.1

10.168.115.13010.168.115.128/27VLAN 128

Alias = “ent_network”

10.168.115.160/27VLAN 160

Alias = “voice_network”

VLAN 160Fwd Mode = Tunnel

fe1/3 & fe1/4192.168.177.1

fe1/2

fe1/0 fe1/1

VLAN 128Fwd Mode = Split-Tunnel

10.168.115.162

Internet orWAN

RAP-5WN

Shared Printer


Aruba N

etworks, Inc.

Exam

ple Configuration for

the Fixed Telecom

muter S

cenario|

115

Virtual B

ranch Netw

orksV

alidated Reference D

esign

vlan = 177forward-mode = bridgerap-operation = always

VAP ProfileFamily_vap_profile

(Task 5C)

lms-ip = 63.82.214.194rap-dhcp-server-vlan = 177rap-dhcp-server-id = 192.168.177.1rap-dhcp-default-router = 192.168.177.1rap-dhcp-pool-start = 192.168.177.100rap-dhcp-pool-end = 192.168.177.254dns-domain = arubanetworks.comdns-domain = airwave.com

AP System ProfileAPGroup1_sys_profile

(Tasks 7A & 7B)

Dependent ProfilesAAA Profile

SSID Profile

SSID ProfileFamily_ssid_profile

(Task 5C)

essid = “Family”wpa-passphrase = “arubarocks”opmode = wpa2-psk-aes

RN

SG

_226

From an A

ruba controller perspective, the profile design required to implem

ent this reference model

can be seen in Figure 50.

AP GroupFixed_Telecommuter_APGroup1

(Task 8)

Dependent Profiles - Wired

Enet1 Port Profile

Dependent Profiles - Wireless

Virtual AP Profile

Enet2 Port Profile Virtual AP Profile


Enet4 Port Profile

Dependent Profiles - General

AP System Profile

AP Wired Port ProfileWired_Ent_Port_profile

(Task 6A)


Wired AP Profile

AP Wired Port ProfileWired_Voice_Port_profile

(Task 6B)

AP Wired Port ProfileWired_Family_Port_profile

(Task 6C)

vlan = 128forward-mode = split-tunnel

VAP ProfileEnterprise_vap_profile

(Task 5A)

vlan = 160forward-mode = tunnel

VAP ProfileVoice_vap_profile

(Task 5B)


Wired AP Profile


Wired AP ProfileDependent Profiles

AAA Profile

SSID Profile


SSID Profile

Wired AP ProfileWired_Ent_ap_profile

(Task 6A)

wired-ap-enable = yesforward-mode = split-tunnelswitchport access vlan = 128

Wired AP ProfileWired_Voice_ap_profile

(Task 6B)

wired-ap-enable = yesswitchport access vlan = 160

SSID ProfileEnterprise_ssid_profile

(Task 5A)

essid = “Enterprise”opmode = wpa2-aes

Wired AP ProfileWired_Family_ap_profile

(Task 6C)

wired-ap-enable = yesforward-mode = bridgeswitchport access vlan = 177

SSID ProfileVoice_ssid_profile

(Task 5B)

essid = “Voice”opmode = wpa2-aes

AAA ProfileWired_Voice_aaa_profile

(Task 4F)dot1x-default-role = Enterprise_Voice_user_roleinitial-role = logonmac-default-role = Enterprise_Voice_user_rolemac-server-group = internal

MAC AuthenticationProfile

AAA ProfileRemote_Ent_aaa_profile

(Task 4D)

Dependent Profiles802.1X Server Group

dot1x-default-role = Remote_Enterprise_user_roleinitial-role = denyall_user_role

802.1X AuthenticationProfile

AAA ProfileVoice_aaa_profile

(Task 4F)

dot1x-default-role = Enterprise_Voice_user_roleinitial-role = logon

AAA ProfileFamily_aaa_profile

(Task 4G)

initial-role = family_user_roleauthentication-dot1x = default-psk





802.1X Authentication ProfileRemote_Enterprise_dot1x

(Task 4B)

MAC Authentication ProfileWired_Voice_mac

(Task 4C)

AP Server GroupRADIUS_Servers

(Task 4A)

Dependent ProfilesAAA AuthenticationServer

AAAAuthentication Server

dot1x_server1(Task 4A)

type = RADIUShost = 10.168.115.130key = “arubasecure”

Figure 50 Profile Design for the Fixed Telecommuter Example


Configuring the Aruba Fixed Telecommuter SolutionThe Aruba Fixed Telecommuter solution requires three main configuration steps:

1. Complete the configuration of the master controller.2. Complete the configuration of the local controllers, and set unique local controller parameters.3. Deploy the RAP.

This section describes each step in detail. For further information, complete configuration files for the master and local controllers are provided in Appendix D: Sample Configuration Files for Fixed Telecommuter Example on page 243. These configuration file outputs have been annotated so that the effect of each step in this procedure can be clearly seen.

Figure 51 Three Steps to Configure the Aruba Fixed Telecommuter Solution

Configure the Master Controller

The following steps summarize the general tasks required for the configuration of the master controller. 1. Complete the base configuration of the master controller.2. Provide a route to the master controller.

3. Configure the network destination, firewall policies, and user roles.4. Configure the AAA server, AAA server group, AAA profile, and AAA authentication profiles.5. Configure the SSID and virtual AP profiles.6. Configure the wired AP and wired port profiles.7. Configure the AP system profile.8. Configure the AP group.

Controller Configuration Wizards

Two administrative methods are available for quickly configuring controllers: CLI setup wizard, accessed via the controller serial port GUI setup wizard, available using an Internet browser

In the following section, the GUI setup wizard is used to complete the master controller base configuration.

RN

SG

_129

DeployRAP

ConfigureLocal

ConfigureMaster



Task 1: Complete the Base Configuration of the Master Controller

The ArubaOS Remote Networking (RN) code train contains unique features to support RAP deployments. Aruba controllers are shipped with the mainline ArubaOS image preloaded. The

first step, therefore, is to install the RN code onto the new master controller.

Step 1A: Load the RN Code on the Master Controller

To launch the GUI setup wizard, follow these steps:1. Connect a laptop to any Fast Ethernet or Gigabit Ethernet on the controller.

The controller initially acts as a DHCP server for the 172.16.0.0 /24 subnet and offers an IP address to the laptop that will be used to access the GUI setup wizard.

2. After an IP address is assigned to the laptop, open an Internet browser and set the address field to the URL http://172.16.0.254.

3. Log in to the controller with the specified administrator credentials.4. On the top-level menu bar, select the Maintenance tab.5. In the navigation pane at the left, select Image Management.

Figure 52 Image Management Screen

6. Verify the system partition used by the ArubaOS boot image; then load the RN code on the other partition.

7. Reboot the controller.

N O T E

Your web browser will display an error message that there is a problem with the web site's security certificate. This is because Aruba ships each controller with a default certificate. Aruba strongly recommends that every customer obtain and install individual certificates for each controller, as a security best practice.



Step 1B: Launch the GUI Setup Wizard

After the controller has rebooted successfully with the RN code image, use the GUI setup wizard to complete the base configuration of the master controller.

1. The GUI setup wizard opens the Welcome screen as shown in Figure 53. For the Deployment Scenario, select Remote networking.

2. Click Begin.

Figure 53 GUI Setup Wizard Welcome Screen



Step 1C: Specify Basic Controller Information

On the controller Basic Information screen, perform the following steps:1. For each of the following fields, enter the information appropriate for the installation of the

controller: Name, Country Code, Password for user “Admin”, Password for Enable Mode Access, Date & Time, and Time Zone.

2. Click Next.

Figure 54 Controller Basic Information Setup



Step 1D: Select the Controller Mode

To specify this controller as a master controller, perform the following steps:1. Click Master.2. Click Next.

Figure 55 Specifying the Controller Mode

Step 1E: Configure the VLAN and IP Interfaces

By default, the GUI Setup Wizard uses VLAN ID 1 for the IP interface with an address and netmask of 172.16.0.254/255.255.255.0. The administrator can modify the IP address and netmask for this VLAN and/or select to add additional VLANs by clicking New.1

The IP address is the public address the RAPs will use to communicate with the controller.

1. VLAN with ID 1 is the default VLAN and the ID cannot be changed. The IP address/netmask for this VLAN can be modified by clicking in the IP Address/Netmask field.

N O T E

The VLANs shown in this section are relevant to the network design illustrated in Figure 49 on page 114. VLAN 1 is not used in this example.



To configure the VLAN and IP interfaces, perform these steps:1. Click New to create a new VLAN.2. Enter values for the VLAN ID, Description, IP Address/Netmask, Port Members, and DHCP

settings.3. Click Add to finish adding the VLAN.

Figure 56 Configuring VLAN and IP Interfaces

4. Create additional VLANs as necessary.



5. Click Next when the modification and/or addition of VLAN/IP address information is complete.

Figure 57 Configured VLAN and IP Interfaces

Step 1F: Configure Connectivity to Local Controllers

As described in Chapter 6: Logical Design on page 59, communication between the master controller and local controller traverses an IPsec tunnel. Creating this tunnel requires an Internet Key Exchange (IKE) pre-shared key that creates a Security Association (SA) that is then used to create the IPsec tunnel. The IKE key must be defined on both the master and local controllers. The master can be configured to use the key for any local that attempts to communicate to it. The local will later be configured to communicate specifically to the master IP address.

In this step, we define the IKE pre-shared key that is used to create the IPsec tunnel.

To define the default gateway address and shared key for the controller, perform the following steps:1. Click Static and enter the default gateway IP address for the controller.2. Enter and re-enter the IKE pre-shared key (case sensitive) that will be used by local controllers

to authenticate with this master controller.The pre-shared key must be from 6 to 64 characters. Be sure to record this key to use on the local controllers.For more information about the IKE pre-shared key, refer to Chapter 6: Logical Design on page 59.



3. Click Next.

Figure 58 Configure Controller Connectivity

Step 1G: Configure the Ports

View the displayed port information and modify any parameters if corrections are needed. Modify the port configuration by clicking on the port parameter requiring change.1

To configure the ports, perform these steps:1. Modify the port configurations as needed by selecting individual ports on the display and clicking

Update.2. Click Disable for Spanning Tree protocol, as it is assumed that the uplink layer 2 switches will be

configured to support spanning tree.

1. Figure 59 shows the port selection for a MMC-3000 series controller. All available ports are listed on the Configure Port screen. Port numbers cannot be modified. All other parameters can be modified.



3. Click Next.

Figure 59 Port Configuration

N O T E

It is assumed that both the active and standby master controllers have “one-armed” connections to distribution switches as recommended in Chapter 6. If this is not the case in your environment, this step may not be necessary.



Step 1H: Save the Controller Configuration

When the controller workflow has been completed, the Controller Configuration is Complete screen opens. Save the configuration and proceed to the License Manager, click Continue.

Figure 60 Controller Configuration Complete

Step 1I: Configure Licences

Perform these steps to configure licenses for this controller:1. Click New.2. Add the Remote Access Point license key and click OK.3. Click New.



4. Add the PEF license and any other required licenses. A key is required for each license.

Figure 61 Install Software Licenses

5. When all the required licenses with their keys have been entered, click Next to push the license information to the controller.

N O T E

As discussed in Chapter 5, the master controller must have the same license types as the local controller. If the master does not terminate RAPs, the smallest available license of each type may be used. Refer to Chapter 5: Physical Designfor more information.



6. After the licenses are pushed to the controller the Installation of Licenses is Complete screen appears, as shown in Figure 62.

Figure 62 License Installation Complete

7. Click Continue to review the master controller base configuration.



Step 1J: Review the Controller Configuration Information

The Aruba Controller setup wizard now displays all the configuration that has been received. Check to make sure that all the parameters match those that were entered in the configuration workflow screens. Use the scroll bar to see the complete parameter list.

1. Click Back to modify configuration information.2. Click Finish if all configuration information is as desired.

Figure 63 Saving the Controller Configuration

While the configuration is being pushed to the controller a Configuration in Progress status message is displayed on the Pushing the Configuration to Controller screen.



When the configuration has been successfully pushed to the controller and the controller has rebooted, the Configuration was Successful window opens as shown in Figure 64.

Figure 64 Configuration Successful

Task 2: Provide a Route to the Master Controller

The local controller periodically communicates with the master controller to report management information and to receive configuration updates. RAPs also transmit ARM and

WIP telemetry to the master controller on a regular basis. Therefore the network administrator must confirm that the master controller has IP connectivity to both the local controller and the RAP inner IP address pool by verifying that the following conditions are true:

The master-IP address you configured in Configure Connectivity to Local Controllers on page 122 must be routable from the local controller.

The L2TP pool used to assign RAP IP addresses must also be routable. UDP port 8211 must be permitted between these endpoints.

N O T E


N O T E

If the RAPs use DNS to resolve the IP address of the DMZ controller, add the appropriate records to the DNS servers.



Task 3: Configure Network Destination, Firewall Policies and User Roles

Now that the basic controller IP settings, RAP IP address pool settings, and licenses have been configured, it is time to configure the security policies of the RAPs and the user role

policies for devices that will be connected to them.

For more information about preparing a security design, including defining roles and policies, refer to , “Authentication and Security Design.”

Step 3A: Configure Network Destination Aliases

Firewall policies can be more efficiently applied with the use of aliases for multiple known network subnet and host references. The following are the network destinations that will be referenced by several destination aliases:

Step 3B: Configure RAP Firewall Policy

After a RAP has authenticated and established an IPsec connection, make sure that the AP is only allowed to access those network resources required for its operation. Thereafter, even if the IKE/IPsec settings of the RAP are known, this knowledge does not, of itself, allow unrestricted network access. The first step is to configure the firewall policies for the RAPs themselves. This policy is applied upon completion of IPsec and grants the following access:

AP control traffic via the Aruba PAPI protocol (UDP port 8211) TFTP traffic from the RAP to the Aruba controller FTP traffic from the RAP to the Aruba controller NTP: udp/123 Syslog: udp/514 802.11 traffic inside GRE tunnels ICMP ping

netdestination ent_network

network 10.0.0.0 255.0.0.0

!

netdestination family_network

network 192.168.177.0 255.255.255.0

!

netdestination sip_server

host 10.168.115.162

!

netdestination voice_network

network 10.168.115.160 255.255.255.224

!

N O T E

This simplified example configuration assumes that the local controller is inside a DMZ and is not connected directly to the Internet.



Use the following CLI commands, in the order listed, to create the firewall policy called RemoteAP_acl. This policy applies the rules in the same order as the preceding bullets.

Step 3C: Configure the RAP User Role

Now that the firewall policy has been created, a role for the RAPs can be created. When a RAP connects to the Aruba controller, it is placed into a role. This role contains information about the access rights and privileges of that device. It also contains the firewall policy we just created.

Use the following CLI commands to create the user role RemoteAP_user_role:

Step 3D: Configure Remote Enterprise Firewall Policy

The Remote_Enterprise_acl policy allows authenticated users to access the enterprise network without limitations. The Remote_Enterprise_acl policy is mapped to Remote_Enterprise_user_role.

Use the following CLI commands in the order listed to create the firewall policy called Remote_Enterprise_acl.

Step 3E: Configure the Remote Enterprise User Role

Now that the firewall policy has been created, a user role for the remote enterprise devices can be created.

Use the following CLI commands to create the user role called Remote_Enterprise_user_role:

ip access-list session RemoteAP_acl

any any svc-papi permit

any any svc-tftp permit

any any svc-ftp permit

any any svc-ntp permit

any any svc-syslog permit

any any svc-gre permit

any any svc-icmp permit

!

user-role RemoteAP_user_role

session-acl RemoteAP_acl

!

ip access-list session Remote_Enterprise_acl

any any svc-dhcp permit

user alias ent_network any permit

alias ent_network user any permit

user network 224.0.0.0 255.0.0.0 any permit

alias ent_network alias ent_network any permit

user any any route src-nat

!

user-role Remote_Enterprise_user_role

session-acl Remote_Enterprise_acl

!



Step 3F: Configure the Enterprise Voice Firewall Policy

The Enterprise_Voice_acl policy is a security best practice that enables only the specific protocols needed by voice devices, including DNS, DHCP, HTTP, HTTPS, ICMP, NTP and TFTP. SIP traffic is allowed only to the voice server. The Enterprise_Voice_acl policy is mapped to Enterprise_Voice_user_role. We assume that the controllers have a Voice License. These ACLs also note network destination aliases that are used to group several hosts and networks together.

Use the following CLI commands to create the access list Enterprise_voice_acl:

Step 3G: Configure the Enterprise Voice User Role

Now that the firewall policy has been created, a user role for the enterprise voice devices can be created.

Use the following CLI commands to create the user role called Enterprise_voice_user_role:

Step 3H: Configure the Family Firewall Policy

Now create a firewall policy for family devices. In the family firewall policy, the following traffic rules are applied in order:

DHCP protocol is allowed for any host. Family traffic destined to the RAP's local private IP is allowed. Family traffic within the same subnet is bridged or forwarded unaltered. Multicast traffic is allowed unaltered.

This rule helps certain common applications like Apple Bonjour to discover services across multiple devices on the local network.

Split-tunnel user is allowed to access bridge user. Internet bound traffic is source-NAT’ed to IP address of Enet0. No other incoming traffic is allowed (from Enet0).

ip access-list session Enterprise_voice_acl

user any udp 68 deny

any any svc-dns permit





alias ent_network user svc-http permit

alias ent_network user svc-https permit

alias voice_network alias sip_server svc-sip-udp permit queue high

alias voice_network alias sip_server svc-sip-tcp permit queue high

!

user-role Enterprise_voice_user_role

session-acl Enterprise_voice_acl

!



Use the following CLI commands, in the order listed, to create a firewall policy for family devices called Family_acl. This policy applies the rules in the same order as the preceding bullets.

Step 3I: Configure the Family User Role

Use the following CLI commands to create the user role Family_user_role:

Step 3J: Configure the Block All Firewall Policy

The following ACL creates a firewall policy to block all traffic for devices that fail wired 802.1X authentication on the enterprise wired port Enet1.

Use the following CLI commands to create the access list denyall_acl:

Step 3K: Configure the Block All User Role

A user role must be created to block all traffic for wired devices that fail 802.1X authentication for the fixed telecommuter wired port Enet1.

Use the following CLI commands to create a user role to block any traffic that fails 802.1X authentication:

Task 4: Configure AAA Server, AAA Server Group, AAA Profile, and AAA Authentication Profiles

Now that the user roles and their firewall policies have been created, the AAA profiles and authentication profiles must be created. The AAA profile contains the initial user role, authentication profiles, authentication default user role, and authentication server group. The AAA profiles will be used by the Virtual AP profile and the Wired Port profiles.

Step 4A: Create a Server for 802.1X Authentication

Wired and wireless 802.1X requires an EAP authentication server to be configured. In the example configuration, we use a RADIUS server on a static IP address and define a shared key for

ip access-list session Family_acl


alias family_network host 192.168.177.1 any route src-nat

alias family_network alias family_network any permit

alias family_network network 224.0.0.0 255.0.0.0 any permit

alias ent_network alias family_network any permit


!

user-role Family_user_role

session-acl Family_acl

!

ip access-list session denyall_acl

any any any deny

!

user-role denyall_user_role

session-acl denyall_acl

!



communication. After the server has been defined, it must be added into a server group. In this simplified example, one server group is shared among three AAA profiles. This can be visualized in Figure 50.

Use the following CLI commands to create the RADIUS server for 802.1X authentication:

Step 4B: Create the Shared 802.1X Authentication Profile

One 802.1X authentication profile is sufficient for many RAP configurations. In this simplified example, a single 802.1X authentication profile is shared between three AAA profiles. This authentication is shown in Figure 50.

Use the following CLI command to create the remote enterprise 802.1X profile:

For information about the usage and role of authentication profiles in RAP configurations, refer to , “Authentication and Security Design.”

Step 4C: Create the Wired Voice MAC Authentication Profile

The following wired voice MAC authentication profile can use the default MAC profile settings and be modified for MAC address delimiter or case preferences.

Use the following CLI command to create the wired voice MAC profile:

Step 4D: Create the Enterprise AAA Profile

An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients on wireless SSIDs and wired ports. The AAA profile also specifies the default user roles for 802.1X and MAC authentication. The remote enterprise AAA profile will force devices to authenticate with the RADIUS server using the 802.1X profile before any access is granted.

aaa authentication-server radius dot1x_server1

host 10.168.115.130

key arubasecure

!

aaa server-group RADIUS_Servers

auth-server dot1x_server1

!

N O T E

It is a best practice to create separate 802.1X authentication profiles for each Virtual AP and Wired Port profile to limit the impact on the number of devices that would be affected by any future modifications that must be made to the profile.

aaa authentication dot1x Remote_Enterprise_dot1x

!

aaa authentication mac Wired_Voice_mac

!



In this simplified example configuration, one AAA profile is shared between the Wired Port Profile for enterprise users on enet1 and the Virtual AP Profile for the enterprise SSID. Use the following CLI commands to create the wireless remote enterprise AAA profile:

Step 4E: Create the Global Wired Authentication Profile

The following wired authentication profile is used globally by the controller for all wired authentication. The best practice is to configure it to have the wired enterprise AAA profile.

Use the following CLI commands to create the global wired authentication profile:

Step 4F: Create the Wired and Wireless Voice AAA Profiles

Follow these steps to create the voice AAA profiles:1. Create the Wireless Voice AAA Profile.

Because it is assumed the enterprise wireless voice device supports the strongest security (WPA2-AES), its AAA profile will have an 802.1X authentication role, 802.1X server group, and no other authentication profile. Use the following CLI commands to create the wireless voice profile:

aaa profile Remote_Ent_aaa_profile

authentication-dot1x Remote_Enterprise_dot1x

dot1x-default-role Remote_Enterprise_user_role

dot1x-server-group RADIUS_Servers

initial-role denyall_user_role

!

aaa authentication wired

profile Remote_Ent_aaa_profile

!

aaa profile Voice_aaa_profile


dot1x-default-role Enterprise_voice_user_role


initial-role logon

!



2. Create the Wired Voice AAA Profile.The enterprise wired voice devices use a separate AAA profile from the wireless devices because they require MAC authentication.Use the following CLI commands to create the wired voice profile:

Step 4G: Create the Family AAA Profile

The Family AAA profile does not need a manually created 802.1X authentication profile because the predefined default-psk 802.1X authentication profile is sufficient for both wireless and wired Family connections.

Use the following commands to create the Family AAA profile:

Task 5: Configure SSID and Virtual AP Profiles

Now that the user roles, authentication profiles, and AAA profiles have been created, the wireless SSID and Virtual AP profiles can be configured to use them.

Step 5A: Create the Enterprise SSID and Virtual AP Profiles

The Enterprise SSID profile is configured with 802.1X WPA2-AES. The Enterprise Virtual AP profile will be configured with forward mode split-tunnel and use VLAN 128 for its IP subnet.

This SSID is designed for enterprise wireless devices. The enterprise traffic will be routed through the IPsec tunnel or source-NAT’ed to the Internet. The DHCP server at the enterprise network assigns IP addresses.

Use the following CLI commands to create the enterprise SSID and VAP (Virtual AP) profiles:

aaa profile Wired_Voice_aaa_profile


authentication-mac Wired_Voice_mac



initial-role logon

mac-default-role Enterprise_voice_user_role

mac-server-group internal

!

aaa profile Family_aaa_profile

initial-role Family_user_role

authentication-dot1x default-psk

!

wlan ssid-profile Enterprise_ssid_profile

essid Enterprise

opmode wpa2-aes

!

wlan virtual-ap Enterprise_vap_profile

aaa-profile Remote_Ent_aaa_profile

ssid-profile Enterprise_ssid_profile

vlan 128

forward-mode split-tunnel

!



Step 5B: Create the Voice SSID and Virtual AP Profiles

The Voice SSID profile is configured with 802.1X WPA2-AES. The Voice Virtual AP profile will be configured with forward mode tunnel and use VLAN 160 for its IP subnet.

Use the following CLI commands to create the voice SSID and VAP profiles:

Step 5C: Create the Family SSID and Virtual AP Profiles

This SSID is for family members or guests in the same household as the enterprise employee. Packets are decrypted on the AP and bridged to the local subnet. An internal DHCP server assigns IP addresses.

The Family SSID profile is configured with WPA2-AES-PSK. The Family Virtual AP profile will be configured with forward mode bridge and will use the RAP’s internal DHCP server VLAN 177 for its IP subnet. This internal subnet must match the AP system’s profile DHCP VLAN settings which will be configured later in this chapter. Because the Virtual AP forward mode is bridge, the SSID can always be available even when there is no connectivity to the controller due to the “rap-operation always” parameter.

In order to provide the same level of security for enterprise users and ease-of-use for family members there should be different wired profiles bound to each RAP Ethernet port for the typical set of devices that would connect to them. The required traffic flow will be defined in the wired-port profile. In the following configuration scenario it is suggested to have the enterprise laptop connected to the enet1 port, the enterprise wired VoIP phone connected to the enet2 port, and the family Ethernet switch plugged into enet3 port.

wlan ssid-profile Voice_ssid_profile

essid Voice

opmode wpa2-aes

!

wlan virtual-ap Voice_vap_profile

aaa-profile Voice_aaa_profile

ssid-profile Voice_ssid_profile

vlan 160

forward-mode tunnel

!

N O T E

In the following CLI example, the Family-vap VLAN should be the same as the “Remote-AP DHCP Server VLAN” configured in the AP system profile. This example also applies to the wired-ap-profile for wired Bridge Family port/user.



Use the following CLI commands to create the family SSID and VAP profiles:

Task 6: Configure Wired AP and Wired Port Profiles

The wired port profiles contain a wired AP profile and an AAA profile which will be applied to the RAP’s Ethernet ports.

Step 6A: Create the Enterprise Wired AP and Port Profiles (Port 1)

This wired port profile will force users to authenticate via 802.1X or else no traffic will be allowed.

Users authenticate with an Ethernet port using 802.1X against a RADIUS server. The employee laptop should be directly connected to the RAP enet1 port because it will be using 802.1X EAP authentication that is often dropped if a layer 2 Ethernet switch in between the client and authenticator. If any other non-enterprise laptop is connected to this port the traffic is immediately dropped as it is secured with 802.1X. After successful wired 802.1X authentication, traffic destined for the internal enterprise network is directed to the IPsec tunnel to the controller. Traffic destined to the local subnet or the Internet is routed on the local network via a split tunnel. A DHCP server at the enterprise network assigns IP addresses.

Use the following CLI commands to create the enterprise wired AP and port profiles:

wlan ssid-profile Family_ssid_profile

essid Family

wpa-passphrase arubarocks

opmode wpa2-psk-aes

!

wlan virtual-ap Family_vap_profile

aaa-profile Family_aaa_profile

ssid-profile Family_ssid_profile

vlan 177

forward-mode bridge

rap-operation always

!

ap wired-ap-profile Wired_Ent_ap_profile

wired-ap-enable


switchport access vlan 128

!

ap wired-port-profile Wired_Ent_port_profile


wired-ap-profile Wired_Ent_ap_profile

!



Step 6B: Create the Voice Wired AP and Port Profiles (Port 2)

Some VoIP phones can authenticate with their Ethernet port using 802.1X against a back-end RADIUS server. For those that cannot authenticate on the wire with 802.1X, the administrator needs to configure MAC authentication. The employee VoIP phone should be directly connected to RAP Enet2 port as it will be using 802.1X EAP authentication or MAC authentication. After successful wired 802.1X or MAC authentication, traffic will be destined for the internal enterprise network via the IPsec tunnel to the controller. A DHCP server at the enterprise network assigns IP addresses.

Use the following CLI commands to create the RAPs voice wired AP and port profiles:

Step 6C: Create the Family Wired AP and Port Profiles (Ports 3 and 4)

Family members and their shared equipment only need access to each other’s devices and the Internet. Therefore the Enet3 port needs to be configured as bridge mode in the wired ap profile. The following configuration will enable these family devices to obtain an IP addresses through the DHCP server on the RAP. All Internet bound traffic will be source-NATed by the RAP (to the IP address of enet0). The bridge port mode is “access,” so all the ports bound with this profile will be in the same VLAN and traffic between devices will also be bridged.

Use the following CLI commands to create the RAP family wired AP and port profiles:

ap wired-ap-profile Wired_Voice_ap_profile

wired-ap-enable


!

ap wired-port-profile Wired_Voice_port_profile

aaa-profile Wired_Voice_aaa_profile

wired-ap-profile Wired_Voice_ap_profile

!

ap wired-ap-profile Wired_Family_ap_profile

wired-ap-enable

forward-mode bridge


!

ap wired-port-profile Wired_Family_port_profile

wired-ap-profile Wired_Family_ap_profile

aaa-profile Family_aaa_profile

!



Task 7: Configure the AP System Profile

The reference design presented earlier in this guide recommends redundant local controllers in an active/active configuration, with one-half of the RAP population terminating on each local.

In that design, two AP groups are required, each with its own AP system profile. However, the simplified example presented in this chapter uses a single AP group and AP system profile.

Step 7A: Create the AP System Profile

The AP system profile specifies critical server IP address values, as well as the DHCP pool range used by the Family role. In this configuration, RAPs are terminated on a specific local controller in the DMZ when this local controller is available (primary LMS).

Use the following CLI commands to create the AP system profile:

Step 7B: DNS Proxy for Split-Tunnel SSID (Optional)

In many enterprises, DNS resolution of certain hosts depends on the location of the client. For example, when a computer is connected to the internal enterprise network, the IP address of the mail server will be resolved to an internal (private) IP address. The same hostname (FQDN) will be resolved to a public IP address if the computer is connected to the Internet.

A RAP normally receives the IP address of the local DNS server from the local DHCP server when the AP boots up. However, there are usually DNS servers within the internal enterprise network. There-fore, the enterprise DNS server is given to clients associated to split-tunnel SSIDs, as these clients obtain IP addresses from a DHCP server on the enterprise network.

A RAP has the ability to intercept DNS queries from SSIDs in split-tunnel mode to re-direct these queries based on the domain. This feature is configured in the ap system-profile applied to a RAP. For example, the following configuration example will tunnel all DNS queries to the enterprise DNS server

N O T E

The following configuration example uses VLAN 177. If a VLAN is not defined, a default RAP DHCP Server configuration is provided (for example, 192.168.11.x). The default subnet for the RAP internal DHCP server is 192.168.11.0 /24; in this use case configuration,192.168.177.0 /24 is being used.

ap system-profile APGroup1_sys_profile

lms-ip 63.82.214.194

rap-dhcp-server-vlan 177

rap-dhcp-server-id 192.168.177.1

rap-dhcp-default-router 192.168.177.1

rap-dhcp-pool-start 192.168.177.100

rap-dhcp-pool-end 192.168.177.254

!

N O T E

If a RAP DHCP DNS server is not defined, the DNS server obtained from DHCP on the uplink enet0 port will be used.



if the domain name ends with 'arubanetworks.com' or 'airwave.com' and re-directs the query to a local DNS server for any other domains.

Task 8: Configure the AP Group

With all of our supporting profiles and groups defined, the final step is to aggregate them using an AP group. In this simplified configuration example, we define AP group

Fixed_Telecommuter_APGroup1 which has an AP system profile, three virtual AP profiles, and four wired port profiles. This configuration is illustrated in Figure 50 on page 115.

Use the following CLI commands to create the AP group for a RAP-5WN with four wired ports:

Configure Local Controllers

This section outlines the steps required to configure a local controller to terminate RAPs. The tasks required to configure the local controllers are:1. Using the controller GUI, complete the base configuration of the local controller.

2. Log in to the local controller CLI and add any necessary static routes that are not reachable through the default gateway.

Task 1: Complete the Base Configuration of the Local Controller

Start by creating the base configuration on the local controller, using the GUI setup wizard. Follow the steps below to complete task 1.

Step 1A: Load the RN Code on the Local Controller

Upgrade the code image on the local controller as described in step 1A on page 117.

1. Log in to the controller with the specified administrator credentials.2. On the top-level menu bar, select the Maintenance tab.3. In the navigation pane at the left, select Image Management.4. Verify the system partition used by the ArubaOS boot image; then load the RN code on the other

partition.5. Reboot the controller.


dns-domain arubanetworks.com

dns-domain airwave.com

!

ap-group Fixed_Telecommuter_APGroup1

ap-system-profile APGroup1_Sys_profile

virtual-ap Enterprise_vap_profile

virtual-ap Voice_vap_profile

virtual-ap Family_vap_profile

enet1-port-profile Wired_Ent_port_profile

enet2-port-profile Wired_Voice_port_profile

enet3-port-profile Wired_Family_port_profile

enet4-port-profile Wired_Family_port_profile

!



Step 1B: Select the Deployment Scenario

After the local controller has rebooted successfully, launch the GUI setup wizard as described in step 1A on page 117.

When the GUI wizard opens the Welcome screen as shown in Figure 53, select Remote networking as the Deployment Scenario and then click Begin.

Figure 65 GUI Setup Wizard Welcome Screen



Step 1C: Specify Basic Controller Information

On the controller Basic Information screen, perform the following steps:1. For each of the following fields, enter the information appropriate for the installation of the

controller: Name, Country Code, Password for user “Admin”, Password for Enable Mode Access, Date & Time, and Time Zone.

2. Click Next.

Figure 66 Controller Basic Information Setup



Step 1D: Select the Controller Mode

To specify this controller as a local controller, perform the following steps:1. Click Local.2. Click Next.

Figure 67 Specifying the Controller Mode

Step 1E: Configure the VLAN and IP Interfaces

By default, the GUI startup wizard uses VLAN ID 1 for the IP interface with an address and netmask of 172.16.0.254/255.255.255.0. The administrator can modify the IP address and netmask for this VLAN and/or select to add additional VLANs using the New button.1

The IP address is the public address which RAPs will use to communicate with the controller.

To configure the VLAN and IP interfaces, perform these steps:1. Click New to create a new VLAN.2. Enter values for the VLAN ID, Description, IP Address/Netmask, Port Members, and DHCP

settings.3. Click Add to finish adding the VLAN.

1. VLAN with ID 1 is the default VLAN and the ID cannot be changed. The IP address/netmask for this VLAN can be modified by clicking on that field.

N O T E

The VLANs displayed in this section are used as examples only.



4. Repeat step 1 through step 3 to add other VLAN and IP interfaces as needed.

Figure 68 Configuring Additional VLAN and IP Interfaces

After VLAN addition or modification, the configured information will appear on the Configure VLANs and IP Interfaces screen. Confirm that the information is correct.

5. Click Next when the modification and/or addition of VLAN/IP address information is complete.



Step 1F: Configure Connectivity to the Master Controller

This step configures the local controller with the IKE pre-shared key used for master-local configuration. The pre-shared key used here must match the key configured on the master in step 1F on page 122.

To define the default gateway address and shared key for the controller, perform the following steps:1. Click Static and enter the default gateway IP address for the controller.2. Enter the IP address of the master controller.

For more information about the IKE pre-shared key, refer to Chapter 6: Logical Design on page 59.

3. Select IP of this Controller as the source of the IP address.4. Click Next.

Figure 69 Configuring Controller Connectivity



Step 1G: Configure the Ports

View the displayed port information and modify any parameters if corrections are needed. Modify the port configuration by clicking on the port parameter requiring change.1

To configure the ports, perform these steps:1. Make any modifications to the port configurations.2. Click Disable for Spanning Tree protocol, as it is assumed that the uplink layer 2 switches will be

configured to support spanning tree. 3. Click Next.

Figure 70 Configuring Ports

1. Figure 70 shows the port selection for an MMC-3000 series controller. All available ports are listed on the Configure Port screen. Port numbers cannot be modified. All other parameters can be modified.

N O T E

It is assumed that both the active and standby master controllers have “one-armed” connections to distribution switches as recommended in Chapter 6. If this is not the case in your environment, this step may not be necessary.



Step 1H: Configure the IP Address Pools

Because the secure RAP is a VPN client, the Aruba controller must have VPN server functionality configured to terminate the RAPs. This functionality is included with the RAP license and has a default ISAKMP and IPsec configuration except for the inner IP address assignment to the RAPs after Extended Authentication (XAUTH) is successful.

To configure the range of the IP address pools, perform these tasks:1. Click New.2. Enter a name for this address pool (case-sensitive).3. Enter the starting address for the address pool.4. Enter the ending address for the address pool.

5. Click Next.

Figure 71 Configure the IP Address Pools for RAPs

N O T E

The ending address minus the starting address of the address pool for RAPs determines the size of the pool. It is prudent to size the address pool to accommodate the future projected number of RAPs to be supported by this controller.



Step 1I: Save the Controller Configuration

When the workflow has been completed, the Controller Configuration is Complete screen appears. To save the controller configuration and proceed to the License Manager, click Continue.

Figure 72 Controller Configuration Complete

Step 1J: Configure Licences

Perform these steps to configure licenses for this controller:1. Click New.2. Add the Remote Access Point license key and click OK.3. Click New.



4. Add the PEF license and any other required licenses. A key is required for each license.

Figure 73 Installing Software Licenses

5. When all of the required licenses with their keys have been entered, click Next to push the license information to the controller.



6. After the licenses are pushed to the controller, the Installation of Licenses is Complete screen is displayed, as shown in Figure 74.

Figure 74 License Installation Complete

7. Click Finish to push the configuration to the controller and reboot the controller.



Step 1K: Review the Controller Configuration Information

The Aruba Controller setup wizard now displays all the configuration that has been received. Make sure that all the parameters match those that were entered in the configuration workflow screens. Use the scroll bar to see the complete parameter list.

1. Click Back to modify configuration information.2. Click Finish if all configuration information is correct.

Figure 75 Saving the Controller Configuration

While the configuration is being pushed to the controller a status message is displayed on the controller GUI.



When the configuration has been successfully pushed to the controller and the controller has rebooted, a notification window maybe viewed on the Controller Has Been Configured & Rebooted screen, as shown in Figure 76.

Figure 76 Configuration is Successful

When the base configuration process is complete, log in to the local controller CLI to complete the next configuration tasks.

Task 2: Add Any Necessary Static Routes

Add the necessary static routes that may not be reachable through the default gateway.

Use the following CLI commands:

ip route 10.0.0.0 255.0.0.0 10.172.21.99.1

!

ip route 172.21.98.0 255.255.255.0 172.21.99.1

!



Deploy RAP(s)

RAPs are usually distributed to employees using the same procedures used for other enterprise IT assets.

The employee’s home must have an operating broadband Internet connection. Aruba recommends that the employee have a DSL modem or cable modem that offers DHCP services.

Perform the following tasks to deploy RAPs.

Task 1: Test and Validate Controller Reachability

Verify that the public address is reachable from the untrusted network, such as the Internet. Make sure that the controller correctly responds to a ping of the new public IP address

63.82.214.207. (The IP address used will be different from this example.)

Task 2: Add the RAP to the Master Controller Local AP Database

Before new RAPs can connect and authenticate to the controller, they must be either provisioned on the controller (pre-provisioning method) or entered into the master controller

RAP whitelist (zero touch method). From the controller GUI, new RAPs can easily be added to the whitelist.

1. Navigate to the Configuration > AP Installation > page.2. Select the RAP Whitelist tab.3. At the bottom of the list, click New.4. Enter the MAC address of the RAP and assign a User Name to this RAP.5. From the drop-down menu, select an AP Group to apply.6. Click Add to apply the configuration.

Figure 77 RAP Whitelist



If you prefer, the CLI can also be used to add new RAPs. Use the following EXEC command to add an AP to the local AP database:

Task 3: Load the MAC Addresses of Client Devices

The master controller should be populated with the wired VoIP phone MAC address using either the WebUI or the command line. You can create entries in the controller's internal

database that can be used to authenticate client MAC addresses. The internal database contains a list of clients along with the password and default role for each client. To configure entries in the internal database for MAC authentication, you enter the MAC address for both the user name and password for each client.

From the controller GUI, adding client devices to the valid MAC address table in the internal database is done on the Authentication Servers page.

1. Navigate to the Configuration > Security > Authentication > Servers > page.2. Select Internal DB.3. In the Users section, click Add User. The user configuration page opens.4. For User Name and Password, enter the MAC address for the client. Use the format specified by

the Delimiter parameter in the MAC Authentication profile. For example, if the MAC Authentication profile specifies the default delimiter (none), enter MAC addresses in the format xxxxxxxxxxxx.

5. Click Enabled to activate this entry immediately.6. Click Apply to apply the configuration.

You can also use the following CLI command to populate the master controller database with the required MAC address, supplying the phone MAC address as the username and password:

local-userdb-ap add mac-address <Remote AP Ethernet Mac Address> ap-group Fixed_Telecommuter_APGroup1

!

N O T E

You must enter the MAC address using the delimiter format configured in the MAC authentication profile. The default delimiter is none, which means that MAC addresses should be in the format xxxxxxxxxxxx. If you specify colons for the delimiter, you can enter MAC addresses in the format xx:xx:xx:xx:xx:xx.

local-userdb add username <phone mac address> password <phone mac address>

!



Task 4: Set Up the RAP in the Home

Each employee who receives a RAP must perform aseries of tasks Zero touch provisioning automates much of the process of setting up the RAP at the employee’s home.The employee

need only perform the following steps:1. Power down the CPE device, such as a cable or DSL modem.

2. Power up the RAP.3. Connect ENET0 to the upstream CPE device (DSL or cable modem).4. Power up the CPE device.5. Make sure that the network is set up such that the RAP will obtain an IP address using DHCP on

this link.

6. Connect a laptop or desktop to the enet1 interface.The laptop should receive an IP address from RAP DHCP server.

7. Start a browser and navigate to any URL.

The browser will be re-directed to the RAP web page asking for the controller IP or hostname.

N O T E

If the CPE device provides voice services, it may contain a backup battery. The backup battery must also be disconnected for 10 seconds.

N O T E

Make sure that no Aruba controllers are in the network where the RAP is being installed.

Make sure that the RAP obtains an IP address on enet0.

N O T E

Validated browsers for zero touch provisioning are: Google Chrome 1.0.154.43 IE 7 Version 7.0.5730.13 Firefox 3.0.5 Firefox 2.0.0.20 Safari 3.1 (525.13)



8. Enter the IP address or hostname supplied by the IT department.

Figure 78 Remote Access Point Setup

If issues arise during RAP deployment, refer to Chapter 12: Troubleshooting Remote Access Points on page 187.

For provisioning and deployment method alternatives and options, refer toAruba Deployment Process for Remote Networks on page 103 in Chapter 8: Deploying Aruba Remote Networksand to Recommended Provisioning Methods on page 108.



Chapter 10: Example Configuration for the Branch Office Scenario

Historically, most branch offices have received less-sophisticated and lower-performance network technology and IT services than enterprise core network workers. Paradoxically, the configuration and management costs have been much higher as a whole for the remote sites.

The Aruba virtual branch network architecture focuses on maintaining the simplicity and ease of use of a software VPN solution while delivering full IP network services to multi-device, multi-user offices with from one to fifty users. This architecture shatters the cost and complexity barriers that exist today in establishing new remote offices for multiple devices and users

The Aruba remote access point (RAP) solution fully meets the needs of the small to medium branch office. By leveraging Aruba’s built-in firewall in the RAP, the enterprise can provide secure wired and wireless services needed by branch office employees, as well as Internet access for their guests.

Simplified Design for the Branch OfficeThis chapter presents a simplified design for a common branch office configuration. This template can be easily adapted to suit the specific needs of each customer. In Chapter 9: Example Configuration for the Fixed Telecommuter Scenario a typical fixed telecommuter reference design was presented. The base configuration of the master controller using the GUI Setup Wizard is not repeated in this chapter. That information can be found in the section Configure the Master Controller on page 116.

The following assumptions are made for the branch office use case: Master/local controller design. Each RAP connects directly to the Internet via a customer-premises device (CPE) device such

as a DSL or MPLS modem. A RAP with at least four wired ports is used. Each wired port on the RAP is statically assigned to

specific function: Port 1: Wired enterprise access (802.1X authentication via split-tunnel forwarding mode). Port 2: Wired voice handset (MAC authentication via tunnel forwarding mode). Port 3: Wired branch office Application Server (802.1X authentication via split-tunnel

forwarding mode). Port 4: Wired guest access (open authentication via bridge forwarding mode).

Three separate wireless SSIDs for Enterprise, Voice and Guests will be broadcast for over-the-air access.

Enterprise users can reach devices on the guest VLAN via one-way ACLs.

Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 159



Redundant master controllers (active/standby configuration) Redundant local controllers (active/active configuration) Dual AP Groups to load balance RAPs across redundant local controllers Separate wired and wireless 802.1X Authentication Profiles for flexibility

A network diagram of this reference model is depicted in Figure 79.

Figure 79 Network Design for the Branch Office Example

RN

SG

_228

VoiceSSID

EnterpriseSSID

Enterprise

Enterprise

Voice

Voice

MasterController

LocalController

RADIUS

SIP Server

RAP IP Pool

ge1/3172.21.98.251

ge1/199.99.99.14

99.99.99.1

99.99.99.00/24VLAN 214

LMSIP = 99.99.99.14

172.21.98.0/24VLAN 98

172.21.99.0/24VLAN 99

10.168.115.225 -10.168.115.239

172.21.99.250ge1/2 (.1Q)

192.168.177.0/24Alias = “guest_network”

VLAN 177Fwd Mode = Bridge

DHCP Start = 192.168.177.100DHCP End = 192.168.177.254

172.21.98.1(Router configured to routeRAP IP Pool & Local to Master)

10.0.0.0(Static Route from Local)

172.21.99.1

10.168.115.130

Application

10.168.115.131

10.168.115.128/27VLAN 128

Alias = “ent_network”

10.168.115.160/27VLAN 160

Alias = “voice_network”

VLAN 160Fwd Mode = Tunnel

fe1/2

fe1/0 fe1/1

fe1/3

VLAN 128Fwd Mode = Split-Tunnel

10.168.115.162

Internet orWAN

RAP-5WN

GuestSSID

fe1/4192.168.177.1


Aruba N

etworks, Inc.

Exam

ple Configuration for the B

ranch Office S

cenario|

161

Virtual B

ranch Netw

orksV


esign

vlan = 177forward-mode = bridgerap-operation = always

VAP ProfileGuest_vap_profile

(Task 5C)

lms-ip = 63.82.214.194rap-dhcp-server-vlan = 177rap-dhcp-server-id = 192.168.177.1rap-dhcp-default-router = 192.168.177.1rap-dhcp-pool-start = 192.168.177.100rap-dhcp-pool-end = 192.168.177.254dns-domain = arubanetworks.comdns-domain = airwave.com

AP System ProfileAPGroup1_sys_profile

(Tasks 7A & 7B)


SSID Profile

SSID ProfileGuest_ssid_profile

(Task 5C)

essid = “Guest”wpa-passphrase = “arubarocks”opmode = wpa2-psk-aes

p

on

RN

SG

_229

From an A

ruba controller perspective, the profile design required to implem

ent this reference model

can be seen in Figure 80.

AP GroupBranch_Office_APGroup1

(Task 8)

Dependent Profiles - Wired

Enet1 Port Profile

Dependent Profiles - Wireless

Virtual AP Profile



Enet4 Port Profile

Dependent Profiles - General

AP System Profile

AP Wired Port ProfileWired_Branch_Port_profile

(Task 6A)


Wired AP Profile

AP Wired Port ProfileWired_Voice_Port_profile

(Task 6B)

AP Wired Port ProfileWired_Guest_Port_profile

(Task 6D)

vlan = 128forward-mode = split-tunnel

VAP ProfileEnterprise_vap_profile

(Task 5A)

vlan = 160forward-mode = tunnel

VAP ProfileVoice_vap_profile

(Task 5B)


Wired AP Profile


Wired AP Profile

AP Wired Port ProfileWired_Server_Port_profile

(Task 6C)


Wired AP ProfileDependent Profiles

AAA Profile

SSID Profile


SSID Profile

Wired AP ProfileWired_Branch_ap_profile

(Task 6A)


Wired AP ProfileWired_Voice_ap_profile

(Task 6B)

wired-ap-enable = yesswitchport access vlan = 160

SSID ProfileEnterprise_ssid_profile

(Task 5A)

essid = “Enterprise”opmode = wpa2-aes

Wired AP ProfileWired_Guest_ap_profile

(Task 6D)

wired-ap-enable = yesforward-mode = bridgeswitchport access vlan = 177

Wired AP ProfileWired_Server_ap_profile

(Task 6C)


SSID ProfileVoice_ssid_profile

(Task 5B)

essid = “Voice”opmode = wpa2-aes

AAA ProfileWired_Voice_aaa_profile

(Task 4G)dot1x-default-role = Enterprise_Voice_user_roleinitial-role = logonmac-default-role = Enterprise_Voice_user_rolemac-server-group = internal

MAC AuthenticationProfile

AAA ProfileRemote_Ent_aaa_profile

(Task 4D)


dot1x-default-role = Remote_Enterprise_user_roleinitial-role = denyall_user_role


AAA ProfileVoice_aaa_profile

(Task 4G)

dot1x-default-role = Enterprise_Voice_user_roleinitial-role = logon

AAA ProfileGuest_aaa_profile

(Task 4H)

initial-role = guest_user_roleauthentication-dot1x = default-psk

AAA ProfileWired_Server_aaa_profile

(Task 4F)

initial-role = Remote_App_Server_user_role

Dependent Profiles802.1X Server Grou

802.1X AuthenticatiProfile



802.1X Authentication ProfileRemote_Enterprise_dot1x

(Task 4B)

MAC Authentication ProfileWired_Voice_mac

(Task 4C)

AP Server GroupRADIUS_Servers

(Task 4A)

Dependent ProfilesAAA AuthenticationServer

AAAAuthentication Server

dot1x_server1(Task 4A)

type = RADIUShost = 10.168.115.130key = “arubasecure”

Figure 80 Profile Design for the Branch Office Example


Configuring the Aruba Branch Office SolutionThe Aruba Branch Office solution requires three main configuration steps:

1. Complete the configuration of the master controller.2. Configure unique local controller parameters.3. Provision and deploy the RAPs.

This chapter describes each task in detail.

Figure 81 Three steps to configure the Aruba Branch Office solution

Configure the Master Controller

The following steps summarize the general tasks required for a basic configuration on the master controller. 1. Complete the base configuration of the master controller.

2. Provide a route to the master controller.3. Configure the network destination, firewall policies and user roles.4. Configure the AAA server, AAA server group, AAA profile, and AAA authentication profiles.5. Configure the SSID and virtual AP profiles.6. Configure the wired AP and wired port profiles.7. Configure the AP system profile.8. Configure the AP group.

Task 1: Configure the Master Controller

The detailed procedure for creating the base configuration on the master controller using the GUI Setup Wizard can be found in Chapter 9: Example Configuration for the Fixed

Telecommuter Scenarioin the section Configure the Master Controller on page 116.

Task 2: Provide a Route to the Master Controller

The local controller periodically communicates with the master controller to report management information and to receive configuration updates. RAPs also transmit ARM and

WIP telemetry to the master controller on a regular basis. Therefore the network administrator must confirm that the master controller has IP connectivity to both the local controller and the RAP inner IP address pool by verifying that the following conditions are true:

The master-IP address you configured in Configure Connectivity to Local Controllers on page 122 must be routable from the local controller.

RN

SG

_129

Provision &DeployRAP

ConfigureLocal

ConfigureMaster



The L2TP pool used to assign RAP IP addresses must also be routable. UDP port 8211 must be permitted between these endpoints.

Task 3: Configure Network Destination, Firewall Policies, and User Roles

Now that the basic controller IP settings, RAP IP pool settings, and licenses have been configured, it is time to configure the security policies of the RAPs and the user role policies for

devices that will be connected to them.

Step 3A: Configure Network Destination Aliases

Firewall policies can be more efficiently applied with the use of aliases for multiple known network subnet and host references. The following are the network destinations that will be referenced by several destination aliases.

Step 3B: Configure RAP Firewall Policy

After a RAP has authenticated and established an IPsec connection, it is time to make sure that the AP is only allowed to access those network resources required for its operation. Thereafter, even if the IKE/IPsec settings of the RAP are known, this knowledge does not, of itself, allow unrestricted network access. We will do this by first configuring firewall policies for the RAPs themselves. This policy is applied upon completion of IPsec and grants the following access.

AP control traffic via the Aruba PAPI protocol (UDP port 8211) TFTP traffic from the RAP to the Aruba controller FTP traffic from the RAP to the Aruba controller NTP: udp/123

N O T E


N O T E

If the RAPs use DNS to resolve the IP address of the DMZ controller, add the appropriate records to the DNS servers.

netdestination ent_network

network 10.0.0.0 255.0.0.0

!

netdestination guest_network

network 192.168.177.0 255.255.255.0

!

netdestination app_server

host 10.168.115.131

!

netdestination sip_server

host 10.168.115.162

!

netdestination voice_network

network 10.168.115.160 255.255.255.224

!



Syslog: udp/514 802.11 traffic inside GRE tunnels ICMP ping

Use the following CLI commands, in the order listed, to create the firewall policy called RemoteAP_acl. This policy applies the rules i the same order as the bullets listed above.

Step 3C: Configure RAP User Role

Now that the firewall policy has been created, a role for the RAPs can be created. When a RAP connects to the Aruba controller, it is placed into a role. This role contains information about the access rights and privileges of that device. It also contains the firewall policy we just created.

Use the following CLI commands to create the user role RemoteAP_user_role:

Step 3D: Configure the Remote Enterprise Firewall Policy

The Remote_Enterprise_acl policy allows authenticated users to access the enterprise network without limitations. The Remote_Enterprise_acl policy is mapped to Remote_Enterprise_user_role.

Use the following CLI commands, in the order listed, to create the firewall policy called Remote_Enterprise_acl:

Step 3E: Configure the Remote Enterprise User Role

Now that the firewall policy has been created, a user role for the remote enterprise devices can be created.

N O T E

This simplified example configuration assumes that the local controller is inside a DMZ and is not connected directly to the Internet

ip access-list session RemoteAP_acl

any any svc-papi permit


any any svc-ftp permit


any any svc-syslog permit

any any svc-gre permit


!

user-role RemoteAP_user_role

session-acl RemoteAP_acl!

ip access-list session Remote_Enterprise_acl


user alias ent_network any permit

alias ent_network user any permit

user network 224.0.0.0 255.0.0.0 any permit

alias ent_network alias ent_network any permit


!



Use the following CLI commands to create the user role called Remote_Enterprise_user_role:

Step 3F: Configure the Enterprise Voice Firewall Policy

The Enterprise_Voice_acl policy is a security best practice that enables only the specific protocols needed by voice devices, including DNS, DHCP, HTTP, HTTPS, ICMP, NTP and TFTP. SIP traffic is allowed only to the voice server. The Enterprise_Voice_acl policy is mapped to Enterprise_Voice_user_role. We assume that the controllers have a Voice License. These ACLs also note network destination aliases that are used to group several hosts and networks together.

Use the following CLI commands to create the access list Enterprise_voice_acl:

Step 3G: Configure the Enterprise Voice User Role

Now that the firewall policy has been created, a user role for the enterprise voice devices can be created.

Use the following CLI commands to create the user role called Enterprise_voice_user_role:

user-role Remote_Enterprise_user_role

session-acl Remote_Enterprise_acl

!

ip access-list session Enterprise_voice_acl

user any udp 68 deny

any any svc-dns permit





alias ent_network user svc-http permit

alias ent_network user svc-https permit

alias voice_network alias sip_server svc-sip-udp permit queue high

alias voice_network alias sip_server svc-sip-tcp permit queue high

!

user-role Enterprise_voice_user_role

session-acl Enterprise_voice_acl

!



Step 3H: Configure the Remote Enterprise Application Server Firewall Policy

In this simplified example configuration, we assume that a local application server has been connected directly to the RAP on the enet3 port. This policy will allow only Enterprise devices to access specific protocols on the Application Server for their application needs. In the following configuration the enterprise devices require ICMP, HTTP, and HTTPS to access their application server.

Use the following CLI commands, in the order listed, to create the firewall policy called Remote_Application_Server_acl:

Step 3I: Configure the Remote Enterprise Application Server User Role

Now that the firewall policy has been created, a user role for the Remote Enterprise Application Server can be created.

Use the following CLI commands to create the user role called Remote_App_Server_user_role

Step 3J: Configure the Guest Firewall Policy

Now create a firewall policy for guest devices. In the firewall policy below the following traffic rules are applied in order:

DHCP protocol is allowed for any host. Guest traffic destined to the RAP’s local private IP is allowed Guest traffic within the same subnet is bridged/forwarded unaltered. Multicast traffic is allowed unaltered.

This helps certain common applications like Apple Bonjour to discover services across multiple devices on the local network.

Split-tunnel users are allowed to access bridge users. Internet-bound traffic is source-NATed to the IP address of enet0. No other incoming traffic is allowed (from enet0).

I access-list session Remote_Application_Server_acl

alias ent_network alias app_server svc-icmp permit

alias ent_network alias app_server svc-http permit

alias ent_network alias app_server svc-https permit

alias app_server alias ent_network any permit


!

user-role Remote_App_Server_user_role

session-acl Remote_Application_Server_acl

!



Use the following CLI commands, in the order listed, to create a firewall policy for guest devices called Guest_acl. This policy applies the rules in the same order as the bullet items listed above

Step 3K: Configure the Guest User Role

Now that the firewall policy has been created, a user role for the Guest devices can be created.

Use the following CLI command to create the user role Guest_user_role:

Step 3L: Configure the Block All Firewall Policy

The following ACL creates a firewall policy to block all traffic for devices that fail wired 802.1X authentication on the enterprise wired port enet1.

Use the following CLI commands to create the access list denyall_acl:

Step 3M: Configure the Block All User Role

A user role must be created to block all traffic for wired devices that fail 802.1X authentication for the Branch Office wired port enet1.

Use the following CLI commands to create a user role to block the 802.1X traffic:.

Task 4: Configure AAA Server, AAA Server Group, AAA Profile, and AAA Authentication Profiles

Now that the user roles and their firewall policies have been created the AAA profiles and authentication profiles must be created. The AAA profile contains initial user role, authentication profiles, authentication default user role, and authentication server group. The AAA profiles will be used by the Virtual AP profile and the Wired Port profiles.

Step 4A: Create a Server for 802.1X Authentication

Wired and wireless 802.1X requires an EAP authentication server to be configured. In the example configuration, we use a RADIUS server on a static IP address and define a shared key for

ip access-list session Guest_acl


alias guest_network host 192.168.177.1 any route src-nat

alias guest_network alias guest_network any permit

alias guest_network network 224.0.0.0 255.0.0.0 any permit

alias ent_network alias guest_network any permit


!

user-role Guest_user_role

session-acl Guest_acl

!

ip access-list session denyall_acl

any any any deny

!

user-role denyall_user_role

session-acl denyall_acl

!



communication. After the server has been defined, it must be added into a server group. In this simplified example, one server group is shared among three AAA profiles. This can be visualized in Figure 80.

Use the following CLI commands to create the RADIUS server for 802.1X authentication:

Step 4B: Create the Shared Remote Enterprise 802.1X Authentication Profile s

One 802.1X authentication profile is sufficient for many RAP configurations. In this simplified example, a single 802.1X authentication profile is shared between three AAA profiles. This can be visualized in Figure 80.

Use the following CLI command to create the remote enterprise 802.1X profile:

For information about the usage and role of authentication profiles in RAP configurations, refer to , “Authentication and Security Design.”

Step 4C: Create the Wired Voice MAC Authentication Profile

The following wired voice MAC authentication profile can use the default MAC profile settings and be modified for MAC address delimiter or case preferences.

Use the following CLI command to create the wired voice MAC profile:

aaa authentication-server radius dot1x_server1

host 10.168.115.130

key arubasecure

!

aaa server-group RADIUS_Servers

auth-server dot1x_server1

!

N O T E

It is a best practice to create separate 802.1X authentication profiles for each Virtual AP and Wired Port profile to limit the impact on the number of devices that would be affected by any future modifications that must be made to the profile.

aaa authentication dot1x Remote_Enterprise_dot1x

!

aaa authentication mac Wired_Voice_mac

!



Step 4D: Create the Enterprise AAA Profile

An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients on wireless SSIDs and wired ports. The AAA profile also specifies the default user roles for 802.1X and MAC authentication. The remote enterprise AAA profile will force devices to authenticate with 802.1X successfully with the RADIUS server before any access is granted.

In this simplified example configuration, one AAA profile is shared between the Wired Port Profile for enterprise users on enet1 and the Virtual AP Profile for the enterprise SSID. Use the following CLI commands to create the wireless remote enterprise AAA profile:

Step 4E: Create the Global Wired Authentication Profile

The following wired authentication profile is used globally by the controller for all wired authentication. The best practice is to configure it to have the wired enterprise AAA profile.

Use the following CLI commands to create the global wired authentication profile:

Step 4F: Create the Wired Remote Enterprise Application Server AAA Profile

The wired remote enterprise Application Server AAA profile will enforce the firewall policies to only allow certain devices and protocols to reach the Server. The enet3 wired port will use this profile.

Use the following CLI command to create the wired remote enterprise Application Server profile:

Step 4G: Create the Wired and Wireless Voice AAA Profiles

Follow these steps to create the voice AAA profiles:

1. Create the Wireless Voice AAA Profile.

Since it is assumed the enterprise wireless voice devices support the strongest security (WPA2-AES), their AAA profile will have an 802.1X authentication role, 802.1X server group, and no other authentication profile.

aaa profile Remote_Ent_aaa_profile


dot1x-default-role Remote_Enterprise_user_role


initial-role denyall_user_role

!

aaa authentication wired

profile Remote_Ent_aaa_profile

!

aaa profile Wired_Server_aaa_profile

initial-role Remote_App_Server_user_role

!



Use the following CLI commands to create the wireless voice profile:

2. Create the Wired Voice AAA profile.

The enterprise wired voice devices will use a separate AAA profile from the wireless devices since they will require MAC authentication.

Use the following CLI commands to create the wired voice profile:

Step 4H: Create the Guest AAA Profile

The guest AAA profile does not need a manually created 802.1X authentication profile because the predefined default-psk 802.1X authentication profile is sufficient for both wireless and wired Guest connections.

Use the following commands to create the Guest AAA profile:

Task 5: Configure SSID and Virtual AP Profiles

Now that the user roles, authentication profiles, and AAA profiles have been created the wireless SSID and Virtual AP profiles can be configured to use them

Step 5A: Create the Enterprise SSID and Virtual AP Profiles

The Enterprise SSID profile is configured with 802.1X WPA2-AES. The Enterprise Virtual AP profile will be configured with forward mode split-tunnel and use VLAN 128 for its IP subnet.

This SSID is designed for enterprise wireless devices. The enterprise traffic will be routed through the IPsec tunnel or source nat’d to the Internet. The DHCP server at the enterprise network assigns IP addresses.

aaa profile Voice_aaa_profile




initial-role logon

!

aaa profile Wired_Voice_aaa_profile


authentication-mac Wired_Voice_mac



initial-role logon

mac-default-role Enterprise_voice_user_role

mac-server-group internal

!

aaa profile Guest_aaa_profile

initial-role Guest_user_role

authentication-dot1x default-psk

!



Use the following CLI commands to create the enterprise SSID and VAP (Virtual AP) profiles:

Step 5B: Create the Voice SSID and Virtual AP Profiles

The Voice SSID profile is configured with 802.1X WPA2-AES. The Voice Virtual AP profile will be configured with forward mode tunnel and use VLAN 128 for its IP subnet.

Use the following CLI commands to create the voice SSID and VAP profiles:

Step 5C: Create the Guest SSID and Virtual AP Profiles

This SSID is for in the same office as the enterprise employee. Packets are decrypted on the AP and bridged to the local subnet. An internal DHCP server assigns IP addresses.

The Guest SSID profile is configured with WPA2-AES-PSK. The Guest Virtual AP profile will be configured with bridge as the forward mode and will use the RAP’s internal DHCP server VLAN 177 for its IP subnet. This internal subnet must match the AP system’s profile DHCP VLAN settings, which will be configured later in this chapter. Since the Virtual AP forward mode is bridge the SSID can always be available even when there is no connectivity to the controller due to the “rap-operation always” parameter.

wlan ssid-profile Enterprise_ssid_profile

essid Enterprise

opmode wpa2-aes

!

wlan virtual-ap Enterprise_vap_profile


ssid-profile Enterprise_ssid_profile

vlan 128


!

wlan ssid-profile Voice_ssid_profile

essid Voice

opmode wpa2-aes

!

wlan virtual-ap Voice_vap_profile

aaa-profile Voice_aaa_profile

ssid-profile Voice_ssid_profile

vlan 160

forward-mode tunnel

!

N O T E

In the following CLI example, the Family-vap vlan should be the same as the “Remote-AP DHCP Server VLAN” configured in the ap system profile. This example also applies to the wired-ap-profile for wired Bridge Family port/user.



Use the following CLI commands to create the guest SSID and VAP profiles:

Task 6: Configure Wired AP and Wired Port Profiles

The wired port profiles contain a wired AP profile and an AAA profile, which will be applied to the RAP’s Ethernet ports.

Step 6A: Create the Branch Wired AP and Port Profiles (Port 1)

This wired port profile will force users to authenticate via 802.1X or else no traffic will be allowed.

Users authenticate with an Ethernet port using 802.1X against a RADIUS server. The employee laptop should be directly connected to the RAP enet1 port because it will be using 802.1X EAP authentication that is often dropped if a Layer 2 Ethernet switch in between the client and authenticator. If any other non-enterprise laptop is connected to this port the traffic is immediately dropped as it is secured with 802.1X. After successful wired 802.1X authentication, traffic destined for the internal enterprise network is directed to the IPsec tunnel to the controller. Traffic destined to the local subnet or the Internet is routed on the local network via a split tunnel. A DHCP server at the enterprise network assigns IP addresses.Use the following CLI commands to create the RAP enterprise wired AP and port profiles:

wlan ssid-profile Guest_ssid_profile

essid Guest

wpa-passphrase arubarocks

opmode wpa2-psk-aes

!

wlan virtual-ap Guest_vap_profile

aaa-profile Guest_aaa_profile

ssid-profile Guest_ssid_profile

vlan 177

forward-mode bridge

rap-operation always

!

ap wired-ap-profile Wired_Branch_ap_profile

wired-ap-enable



!

ap wired-port-profile Wired_Branch_port_profile


wired-ap-profile Wired_Branch_ap_profile

!



Step 6B: Create the Voice Wired AP and Port Profiles (Port 2)

Use the following CLI commands to create the RAP voice wired AP and port profiles:

Step 6C: Create the Application Server Wired AP and Port Profiles (Port 3)

A local application server is directly connected to the RAP-5WN on the Enet3 port. This allows ACLs to be applied to enforce user role assignments so as to permit server access only to authorized devices.

Use the following CLI commands to create the application server wired AP and port profiles:

Step 6D: Create the Guest Wired AP and Port Profiles (Port 4)

Guests and their shared equipment only need access to each other’s devices and the Internet. Therefore the Enet4 port should be configured as bridge mode in the wired AP profile. The following configuration will enable these guest devices to obtain an IP addresses through the DHCP server on the RAP. All Internet-bound traffic will be source-NATed by the RAP (to the IP address of Enet0). Because the bridge port mode is “access,” all the ports bound with this profile will be in the same VLAN, and traffic between devices will also be bridged.

Use the following CLI commands to create the guest wired AP and port profiles:

ap wired-ap-profile Wired_Voice_ap_profile

wired-ap-enable


!

ap wired-port-profile Wired_Voice_port_profile

aaa-profile Wired_Voice_aaa_profile

wired-ap-profile Wired_Voice_ap_profile

!

ap wired-ap-profile Wired_Server_ap_profile

wired-ap-enable



!

ap wired-port-profile Wired_Server_port_profile

wired-ap-profile Wired_Server_ap_profile

aaa-profile Wired_Server_aaa_profile

!

ap wired-ap-profile Wired_Guest_ap_profile

wired-ap-enable

forward-mode bridge


!

ap wired-port-profile Wired_Guest_port_profile

wired-ap-profile Wired_Guest_ap_profile

aaa-profile Guest_aaa_profile

!



Task 7: Configure the AP System Profile

The reference design presented earlier in this guide recommends redundant local controllers in an active/active configuration, with one-half of the RAP population terminating on each local.

In that design, two AP groups are required, each with its own AP system profile. However, the simplified example presented in this chapter uses a single AP group and AP system profile.

Step 7A: Create the AP System Profile

The AP system profile specifies critical server IP address values, as well as the DHCP pool range used by the Family role. In this configuration RAPs are terminated on a specific local controller in the DMZ when this local controller is available (primary LMS).

Use the following CLI commands to create the AP system profiles:

Step 7B: DNS Proxy for Split-Tunnel SSID (Optional)

In many enterprises, DNS resolution of certain hosts depends on the location of the client. For example, when a computer is connected to the internal enterprise network, the IP address of the mail server will be resolved to an internal (private) IP address. The same hostname (FQDN) will be resolved to a public IP address if the computer is connected to the Internet.

A RAP normally receives the IP address of the local DNS server from the local DHCP server when the AP boots up. However, there are usually DNS servers within the internal enterprise network: therefore, the enterprise DNS server is given to clients associated to split-tunnel SSIDs as these clients obtain IP addresses from a DHCP server on the enterprise network.

A RAP has the ability to intercept DNS queries from SSIDs in Split-Tunnel mode to re-direct these que-ries based on the domain. This feature is configured in the ap system-profile applied to a RAP. For example, the following configuration example will tunnel all DNS queries to the enterprise DNS server

N O T E

The following configuration example uses VLAN 177. If a VLAN is not defined, a default Remote-AP DHCP Server configuration is provided (for example, 192.168.11.x). The default subnet for the RAP internal DHCP server is 192.168.11.0 /24; in this use case configuration,192.168.177.0 /24 is being used.


lms-ip 63.82.214.194

rap-dhcp-server-vlan 177

rap-dhcp-server-id 192.168.177.1

rap-dhcp-default-router 192.168.177.1

rap-dhcp-pool-start 192.168.177.100

rap-dhcp-pool-end 192.168.177.254

!

N O T E

If a RAP DHCP DNS server is not defined, the DNS server obtained from DHCP on the uplink enet0 port will be used.



if the domain name ends with 'arubanetworks.com' or 'airwave.com' and re-directs the query to a local DNS server for any other domains.

Task 8: Configure the AP Group

With all of our supporting profiles and groups defined, the final step is to aggregate them together using an AP group. In this simplified configuration example, we define AP group

Fixed_Telecommuter_APGroup1 which has an AP system profile, three virtual AP profiles, and four wired port profiles. This can be visualized in Figure 80 on page 161.

Use the following CLI commands to configure the AP group for a RAP-5WN with four wired ports:

Configure the Local Controller

This section outlines the steps required to configure a local controller to terminate remote access points.

The tasks required to configure the local controllers are:

1. Using the controller GUI, complete the base configuration of the local controller.2. Log in to the local controller CLI and add any necessary static routes that are not reachable

through the default gateway,

Task 1: Complete the Base Configuration of the Local Controller

To complete the base configuration of the local controller, follow the procedure under Task 1 starting on page 141 in , “Example Configuration for the Fixed Telecommuter Scenario.”

Select Remote networking as the Deployment Scenario in the Welcome screen.


dns-domain arubanetworks.com

dns-domain airwave.com

!

ap-group Branch_Office_APGroup1

ap-system-profile APGroup1_Sys_profile

virtual-ap Enterprise_vap_profile

virtual-ap Voice_vap_profile

virtual-ap Guest_vap_profile

enet1-port-profile Wired_Branch_port_profile

enet2-port-profile Wired_Voice_port_profile

enet3-port-profile Wired_Server_port_profile

enet4-port-profile Wired_Guest_port_profile

!



Task 2: Add Any Necessary Static Routes.

Add the necessary static routes that may not be reachable through the default gateway.

Use the following CLI commands:

Provision and Deploy RAPs

Provisioning and deployment methods for branch offices are discussed in detail in , “Example Configuration for the Fixed Telecommuter Scenario.”in the section.Deploy RAP(s) on page 154.

ip route 10.0.0.0 255.0.0.0 172.21.99.1

!

!ip route 172.21.98.0 255.255.255.0 172.21.99.1

!



Chapter 11: Reporting and Management

Enterprises are actively building the largest remote networks in the world, often fielding 30,000 or more devices. Managing those large-scale remote networks involves challenges a traditional campus-based enterprise does not encounter, even though the hardware may be identical. The network is larger and more distributed, operating environments are more varied, onsite support resources

are limited or nonexistent, and network security is critical.

The Aruba AirWave Management Platform (AMP) provides the level of control IT needs to successfully manage a distributed network encompassing many remote networks. AirWave is specifically designed with features that meet the particular needs of organizations with remote networks.

Manageability. Supports centralized configuration and control of the remote network infrastructure regardless of vendor or architecture from a single point. The Virtual Branch Network solution appears to the NOC to be an extension of the enterprise LAN.

Security. Detects devices and enforces security policies across all wired and wireless devices automatically.

Visibility. Allows viewing of real-time information for every remote user and device as well as historical trend reports for planning and diagnostics. Provides tracking in split-tunnel and tunnel modes for wireline users attached to an Aruba access point via a port in untrusted mode. The MAC address, user name, and role, as well as the mode, are displayed on the AP Monitoring and AP list pages, and on user detail and user list pages. Campus and remote access points are identified, and RAP-5WN and RAP-5 are supported.

Flexibility. Fits the remote network management solution to the existing network architecture. In addition, AMP allows simultaneous management of both legacy wired and wireless infrastructure and the latest access point technology from a single console.

AMP gives organizations the ability to effectively control very large-scale remote networks. In this chapter, we explore the capabilities of AMP as well as specific remote networking features available in the product.

Remote ManagementIn the remote network environment, especially where each branch office is relatively small and/or a large number of telecommuter workers exist, local IT support is not available, and onsite staff may not be able to diagnose or resolve network issues on their own. Therefore, efficient remote support must come through a centralized Network Operations Center (NOC) or else operating costs will mount with each local service call.

Using AMP, IT staff gain the same type of information for remote networks as they do for the enterprise LAN. To the IT staff, the remote networks appear as if they were standing in the remote facility. Through a combination of RF monitoring using authorized APs and wired network scans, AMP shows IT exactly who is connected to the network, how much bandwidth they are using, how the network is performing locally, and what signal level is being received by any wireless users.

Aruba Networks, Inc. Reporting and Management | 177


Figure 82 shows an example of an AirWave monitoring screen for an Aruba Remote Access Point (RAP). This page aggregates statistics for all wired and wireless interfaces on the RAP. Drill-downs are available to examine specific user and interface attributes.

Figure 82 AirWave RAP Monitoring Page

AMP provides a flexible grouping mechanism that enables logical segmentation of devices based on location, security, or even device type. Flexible grouping coupled with robust searching capabilities allows IT to quickly locate and drill into detailed data for a single device, a group of devices, an individual user, a group of users, a floor plan, or a building. Using the AirWave VisualRF module for wireless clients, IT sees where each user or device is located and can assess the RF environment for likely sources of interference. With this data, IT can diagnose problems quickly to determine whether the issue is related to the client AP, controller, or wired network.



Figure 83 shows an example of a user page in AMP that shows information about connected users on a RAP.

Figure 83 AirWave Connected User Page

This diagnostic page enables help desk personnel to quickly diagnose a problem or create an incident for a Level II support engineer. Help desk personnel can correlate and capture this page or any page in AMP to a trouble ticket. This capability makes sure that the Level II engineer can view the user’s experience as it was when the incident was created.

Figure 84 AirWave User Detail Page



Managing Both Legacy and New Network Elements

An organization’s remote networks are significantly more likely to have hardware from multiple vendors than a standard enterprise organization with carpeted offices. Several key factors contribute to this diversity:

Mergers and acquisitions Aggressive vendor management Diverse operating environments Large deployments and lengthy rollouts

No matter how inexpensive the network hardware, the real cost of installing or replacing that hardware for a large organization can be thousands of dollars. Equipment must be staged, local contractors hired, and the work performed in a way that does not disrupt ongoing operations. Even a small mistake can cost hundreds of thousands of dollars if it is replicated in every remote facility, so many organizations prefer to update a test segment of the network to work out the kinks with the upgrade. When the test upgrade is successful, the organization gradually migrates the changes to the rest of the network, segment by segment. As a result, upgrading the entire network may take several years.

A network management platform must maintain extensive support for legacy devices and architectures while permitting the addition of new products. It must also allow the wired and wireless network to function in logical segments, to enable new products and changes to be rolled out gradually.

AMP supports a broad library of the most popular wired and wireless network elements, including legacy hardware from the early days of Wi-Fi. The organization can extend the life of its existing investment and determine when to upgrade its network infrastructure.

Within AMP, users can define as many device groups as needed, allowing organizations to set up test groups for new devices and configurations. When a network change is made, AMP can implement it globally or segment by segment. Changes can be scheduled to occur late at night, to minimize the impact on local network performance.

Role-Based Management

In a typical large organization, dozens or even hundreds of IT employees need access to information about the remote networks. A management solution designed only for network engineers cannot meet the diverse needs of all IT staff members.

Help desk staff typically fields calls from remote network employees reporting network problems. The help desk needs to locate the remote user quickly (preferably by username), determine which facility he is in, view real-time performance and usage data, and access historical information for diagnostic purposes. One help desk group may be responsible for all remote facilities or the responsibility may be assigned to multiple, smaller help desks. This team usually has no administrative privileges for changing network settings or security policies.

AMP has help desk-specific screens that provide a snapshot of incidents, allowing staff the ability to quickly drill down and diagnose an end user-reported issue. 3-D navigation works very well if the help desk knows the location. Otherwise, the search mechanism will find all instances of a user on the network.



Figure 85 Help Desk Problem Resolution Progression

Network engineers need to manage device configurations on their segment of the network. Individual network engineers responsible for a geographic region or a specific set of facilities should not have administrative access to other network segments.

Enterprise network administrators need to define network and security policies across the entire network, as well as see detailed trend reports and exception reports.

Network planners need detailed trend reporting, by facility and other logical groupings, in order to plan network expansion to assure performance and security.

Installers (often contractors) need detailed installation reports and forms to fill in site-specific information, but typically should not be able to configure or monitor remote devices on an ongoing basis.

IT security and audit teams must be alerted when device configurations violate policies or when rogue devices are discovered, and need to view audit trails and log files as necessary.

AMP allows the IT organization to tailor permissions and views to match the responsibilities of these various IT users:

Password-protected user permissions can be set to ‘view-only’ levels for users who only need to monitor data, while ‘read-write’ administrative access is granted to network engineers. Users can be given permission to view data across the entire remote network infrastructure or be restricted to those groups or devices for which they are responsible.

AMP reports are automatically delivered to specified email distribution lists to make sure staff members receive job-appropriate information. The audit group can receive configuration-compliance reports and rogue-device reports without administrative access to the system. Network planners can receive usage reports and trend data without accessing the AMP system.



For wireless networks, VisualRF provides special bill of material (BOM) reports for installers without giving them access to any configuration data, thus maintaining network and data security.

Planning and Location Services for Wireless Clients

Organizations with hundreds of branch offices and potentially thousands of telecommuters need the ability to view real-time RF information at each location to provide optimization and efficiently diagnose problems. A key feature, location services, assist organizations in reducing costs and increasing productivity.

An easy-to-use planning and provisioning tool, VisualRF reduces the time required for importing floor plans and provisioning APs. VisualRF provides a simple, intuitive interface to guide even an RF novice through the process.

In a sample planning and provisioning scenario for a remote branch office, a typical procedure would take less than 15 minutes per location using VisualRF:

Import floor plan CAD file (DWG formats are converted automatically with dimensions and layers).

Associate floor plan with floor number and location. Remove non-vital layers (cubes, writing, and so on). Crop white space. Draw external walls. Auto-provision APs by drawing provisioning region.

If using the pre-provisioning deployment methodology for remote network rollouts that is described in this chapter, the actual APs could be configured directly in AirWave at the organization’s staging center. If using the post-provisioning methodology, first install the remote networks, then return to the AirWave floor plan for each facility and match the previously planned APs to actual APs.

Figure 86 3-D Navigation With VisualRF



This work produces an easy to use 3-D navigation capability as shown in Figure 86. This navigation capability provides all IT personnel with quick access to location and diagnostic services within VisualRF without having to know the physical or logical network topology. AirWave uses the hierarchy of the network, campus, and building to organize floor plans. A campus is a collection of buildings; there is no requirement that they be physically near one another. Therefore, organizations often map their facility’s geographic areas into the campus concept within AirWave, with each area loaded as a separate campus. Areas and facilities can be named with their identifying numbers as well as the city or geographic region they cover.

VisualRF also provides auto-import capability from AOS (Aruba controllers), RFPlan, and WCS (Cisco’s Wireless Control System). If you have already loaded your floor plans and placed your APs, you will not have to repeat the process when you install AMP.

From the building view you can select the floor of interest and obtain diagnostic and location information, as shown in Figure 87.

Figure 87 Floor Plan Views

From this view you can also focus on a client or AP, view Wi-Fi tag locations, view rogue devices, view roaming history, view heat maps, view data rates, view channel overlap, perform remote site surveys, adjust antenna properties, and view neighboring APs.



Scalability

For an enterprise with hundreds or thousands of remote facilities, installing two or three RAPs per facility means the IT organization must manage a remote network with thousands of APs. When enterprise central and local offices are included, it is not unusual for a large enterprise to have thousands of RAPs (and tens of thousands of client devices) on its network.

Most management solutions are designed for smaller remote networks, with limits on the number of RAPs or controllers that can be managed. This limitation forces IT to manage its remote network as multiple separate stand-alone networks. To operate a large, mission-critical remote network, IT needs enterprise-grade features such as many-to-one automated failover, TACACS integration, and more.

By contrast, AMP is designed for maximum scalability, and can routinely manage networks with 30,000-plus remote access points. AMP is a software-only solution that allows the user to select a hardware platform that meets its needs rather than using a one-size-fits-all appliance with limited scalability. This approach provides a management platform that seamlessly supports the Aruba VBN remote network virtualization paradigm.

AMP also employs a distributed architecture that allows IT to install the software on multiple servers, and to manage and monitor the software from a unified, web-based Master Console. These servers can be collocated in a single NOC or distributed in multiple locations, as appropriate. As a result, AMP has nearly unlimited scalability; more servers can be added as the remote network grows without sacrificing centralized control and manageability.

Figure 88 Master Console

RN

SG

_222Fixed

Telecommuter Sites

AirWaveFailover

AWMS Software

CentralizedArchitecture

Branch Office Sites

AirWaveFailover

AWMS Software

FixedTelecommuter Sites

CentralizedArchitecture

Branch Office Sites

Enterprise Site A

Network Network

Enterprise Site B

NOC #1

AirWaveMaster Console™

NOC #2



Trend Reporting

When an organization decides to add another RAP model to a standard remote network configuration, the decision impacts not one remote network but potentially thousands; the cost is not a few hundred dollars, but several hundred thousand dollars. Organizations with many remote locations tend to standardize their network environments to keep operational costs low. As a result, the successful IT organization needs to know not just real-time information on network utilization and performance in each remote location, but detailed trending data on individual users and devices:

Which RAPs are most heavily loaded, the RAPs in the conference rooms or those in the sales offices?

How variable are usage patterns? Are there peak usage times at certain points in the day or year, or is usage fairly steady?

Which users are causing the network traffic to increase? Was there a significant utilization increase in the 10 remote facilities where you are testing VoIP?

Are there seasonal patterns to network usage? Was there a spike in usage during the year-end close last year that would indicate that IT should plan for a comparable spike this year?

Only with reliable historical trending data added to real-time information can IT make informed, intelligent decisions about when, where, and how to grow their remote networks.

Figure 89 Trend Reporting

The AMP provides both the real-time and historical information that organizations need. AMP retains historical user and performance data for a year or more, enabling the IT staff to run detailed trending reports for specific groups of remote locations or globally across the entire network. AMP also uses a flexible folder UI design that allows IT to examine branch office conference room APs separately from back-office RAPs to get more granular trend and performance data.



Diverse WAN Environments

On a campus network, a reliable broadband connection is nearly always available, so bandwidth and latency are not significant concerns. In a highly distributed environment, some remote facilities may use a T1 connection or even an intermittent satellite connection, while telecommuters may have a mix of broadband cable and DSL. Even if the primary connection is a broadband line, the emergency backup link typically is not. Management solutions that can adapt to the available bandwidth are needed, rather than forcing IT to re-architect their entire network infrastructure simply to support remote facilities.

AMP provides maximum flexibility to support nearly any network environment, whether stand-alone or lightweight APs are deployed. Using group-based parameters, IT can configure AMP to poll network locations with a broadband connection frequently to provide near real-time monitoring data. In other facilities, where bandwidth is more of a concern, the polling interval can be longer to minimize network traffic.

Similarly, AMP triggers and alert thresholds can be configured to reflect network design and support high-latency networks. On a high-latency network, for example, AMP can be configured to wait longer for a response to a polling query. Instead of treating all network locations the same, AMP provides IT maximum flexibility, fine-tuning management settings for each type of facility.



Chapter 12: Troubleshooting Remote Access Points

This chapter describes basic troubleshooting for the remote access point (RAP). To successfully troubleshoot issues with a RAP installation, you should be familiar with: Basic IPsec operation and protocols RAP provisioning procedures

Aruba Controller web user interface and CLI commands

The troubleshooting procedures in this chapter primarily use the CLI to verify configuration parameters and log messages for the RAP.

Troubleshooting CategoriesThis chapter includes information about the following types of troubleshooting:

Zero Touch Provisioning ProblemsUsers provision the RAP using the web interface. If problems arise during the provisioning process, error screens and diagnostic screens provide help to identify the source of the problem. (See Troubleshooting Zero Touch Provisioning Problems on page 188.)

Basic Connectivity ProblemsThis deals with the basic connectivity established between the RAP and the Aruba controller after the RAP is provisioned. (See Troubleshooting Basic Connectivity Problems on page 189.)

Bootstrapping ProblemsRAP bootstrapping is the process by which the RAP attempts communication with the controller using the Process Application Programming Interface protocol. (See Troubleshooting RAP Bootstrapping Problems on page 207.)

Wired Port Configuration ProblemsThe RAP has one or more ports that can operate in Active/Standby mode or in Wired Port mode. Misconfiguration of the port for operating as a wired port can cause problems. (See Troubleshooting Wired Port Configuration Problems on page 212.)

Split-Tunnel Forwarding Mode Configuration ProblemsProblems can arise if the RAP is not correctly configured for split-tunnel mode operation. (See Troubleshooting Split-Tunnel Mode Problems on page 216.)

Bridge Forwarding Mode Configuration ProblemsProblems can arise if the RAP is not correctly configured for bridge mode operation. (See Troubleshooting Bridge Mode Problems on page 225.)

Aruba Networks, Inc. Troubleshooting Remote Access Points | 187


Troubleshooting Zero Touch Provisioning ProblemsTo complete the provisioning process for a new RAP when zero touch provisioning is being used, the user connects a PC to the RAP after receiving it and launches a Web browser. At this point the Provisioning screen should be displayed on the browser. If the Provisioning screen does not come up, the user should: Check the cable connection between the RAP and the PC.

Check the PC and make sure that the Ethernet port on the PC is set for a DHCP IP address.

The Provisioning screen prompts the user to enter either the IP address or the hostname of the Aruba master controller, after which provisioning occurs automatically. The screen reports the steps in the provisioning and connecting sequence. When the process is completed successfully, the RAP reboots (Figure 90).

Figure 90 Successfully Provisioned RAP

After the RAP reboots, the browser is automatically directed to the RAP console page (Figure 91).

Figure 91 RAP Console Page



If provisioning was not successful, the RAP does not reboot. Refer to Working from the RAP on page 189 for information about troubleshooting connectivity using the RAP Console screens.

Troubleshooting Basic Connectivity ProblemsTo troubleshoot basic connectivity, it is useful to understand how the RAP connects to the controller. After a provisioned RAP is connected to the network and completes its boot process, it goes through the following operational stages to establish a connection to the Aruba controller:1. Acquires IP parameters.2. Sets up an IPsec tunnel to the controller.

3. Authenticates using embedded certificate.4. Transitions from the temporary role to the system role called ap-role.5. Downloads its configuration and bootstraps.

Problems may occur at any of these stages. The troubleshooting procedure in this chapter follows each step in this process to identify the root cause. More information is available in Chapter 2: Virtual Branch Theory of Operations on page 13.

To troubleshoot the basic connectivity, you can work from the RAP or from the controller.

Working from the RAP

Users with RAPs configured in either bridge mode or split-tunnel mode can use the RAP Console screens in the WebUI to troubleshoot connectivity issues.

To access the RAP console:

1. Connect a PC to the RAP and open a Web browser.

2. Point the browser to the following URL:http://rapconsole.arubanetworks.comThe RAP Console screen opens with the Summary tab active.

3. From the Summary tab, click Advanced.

N O T E

Only connect the PC to ports configured for split-tunnel or bridge forwarding modes. Ports configured for tunnel forwarding mode will not display a RAP console.



The Advanced Summary tab (Figure 92) provides detailed information about the RAP configuration and connection status and may suggest a direction for troubleshooting.

Figure 92 Advanced Summary Information

The Diagnostics tab (Figure 93) allows you to perform basic tests for troubleshooting.

Figure 93 Diagnostics Tab



Working from the Controller

Figure 94 shows a general overview of how to approach the troubleshooting process from the direction of the controller.

Figure 94 General Approach to Troubleshooting the RAP

If the RAP is not communicating with the controller, start by connecting to the controller and issuing the following command:

show crypto ipsec sa [peer <ip_address>]

where <ip-address> is the RAP public IP address.

RN

SG

_213

START HERE:

Enter the command:show crypto ipsec sa

Is output present?

Does the outputinclude an inner IP?

See“Troubleshooting RAP

Bootstrapping Problems”

See“Troubleshootingthe IPsec Tunnel”

See “Checking the XAuth”and “Checking the IP

Address Pool and Usage”

Yes

No

Yes

No

See “Troubleshooting RAP

Bootstrapping Problems”



The command output should be similar to the following:

Depending on the output from this command, do one of the following: If there is no output from this command, go to Troubleshooting the IPsec Tunnel on page 192. If the command output does not include the inner IP address, go to Checking the IP Address

Pool and Usage on page 206. If the command output includes all the expected data, go to Troubleshooting RAP Bootstrapping

Problems on page 207.

Troubleshooting the IPsec Tunnel

If the show crypto ipsec sa command does not return any command output, there is a problem with the IPsec tunnel.

The RAP IPsec tunnel is set up in two phases. In phase 1, an ISAKMP connection is established between the RAP and the controller to secure the phase 2 negotiations.

During phase 2, security associations (SAs) are negotiated to determine the encryption and authentication algorithms to be used when sending user data. Each SA is identified by a unique security parameter index (SPI), which is also negotiated during phase 2. The RAP uses transport encapsulation mode. Phase 2 completes the connection.

(vrd-rap-local) #show crypto ipsec sa peer 66.126.247.254

Initiator IP: 66.126.247.254

Responder IP: 68.165.169.218

Initiator: No

Initiator cookie:10257410b0aaae07 Responder cookie:a82d2205f2393b83

SA Creation Date: Thu Apr 9 14:19:29 2009

Life secs: 7200

Initiator Phase2 ID: 10.168.23.91/255.255.255.255

Responder Phase2 ID: 0.0.0.0/0.0.0.0

Phase2 Transform: EncAlg:esp-3des HMAC:esp-sha-hmac

Encapsulation Mode:UDP-encapsulated Tunnel

PFS: No

OUT SPI c1e9a600, IN SPI 0dde1300

Inner IP 10.168.23.91, internal type C

Aruba AP

Reference count: 3



Figure 95 shows the sequence for troubleshooting the IPsec tunnel.

Figure 95 Troubleshooting the IPsec Tunnel

If the RAP is not communicating with the Aruba controller, verify the following:1. Has the RAP contacted the controller over UDP port 4500? (See Checking the UDP 4500

Session on page 194.)2. Was IPsec phase 1 established? (See Checking IPsec Phase 1 on page 194.)3. Was IPsec phase 2 established? (See Checking IPsec Phase 2 on page 200.)

RN

SG

_214

START HERE:

Troubleshoot the IPsec tunnel.Didshow crypto ipsec sa produce output?

Enter the command:show crypto isakmp sa

Enter the command:show datapath session table

See“Checking the UDP

4500 Session”

Yes

No

Yes

No

See“Preshared Key Mismatch”

and“ISAKMP Policy Changes”

No

Does theoutput show a

NAT-T (UDP 4500)session?

Enter the command:show crypto ipsec sa

Yes

Does theoutput show aPhase 1 SA?

Contact Aruba for assistanceGather data as described in

“Information for Technical Support”

No

See “Checking XAuth”and “Checking the IP

Address Pool and Usage”

Yes

Does theoutput show aPhase 2 SA?



Checking the UDP 4500 Session

To verify whether or not the RAP contacted the controller, use the following command:(vrd-rap-local) #show datapath session table | include 4500

The output should be similar to the following (not all fields shown):

Troubleshooting a Missing UDP 4500 Session

If no UDP 4500 session is present, do the following:1. Check the IP connectivity between the RAP (DSL/cable) public IP address and the controller

public IP address using IP utilities such as ping and trace-route.Alternatively, ask the end user to access the Local Debug screen.

2. Check for an external firewall that blocks NAT traversal (NAT-T). 3. Check which ACLs in the logon role are registering hits, using the following command:

(vrd-rap-local) #show acl hits

The command output should be similar to the following: (not all fields shown):

In particular, notice the following: Is the svs-natt policy present and permitted in the logon role? Is NAT-T registering hits?

If no IP connectivity could be established or if no incoming UDP 4500 packets are observed, check with the ISP or DSL provider.

Checking IPsec Phase 1

If IPsec phase 1 was established, a phase 1 security association (SA) exists. To check for a phase 1 SA, use the following command:

(vrd-rap-local) #show crypto isakmp sa [peer <ip-address>]

Source IP Destination IP Prot SPort DPort ... TAge Flags

-------------- -------------- ---- ----- ----- ... ---- -----

98.234.52.200 63.82.214.206 17 33782 4500 ... 8c8b FC63.82.214.206 98.234.52.200 17 4500 33782 ... 8c8b F

User Role ACL Hits

------------------

Role Policy Src Dst Service Action Dest/Opcode New Hits Total Hits ....

---- ------ --- --- ------- ------ ----------- -------- ---------- ....

ap-role ap-acl any any svc-syslog permit 0 3 ....

RemoteAP RemoteAP any any svc-papi permit 0 1 ....

RemoteAP RemoteAP any any svc-ntp permit 0 1 ....



The output should be similar to the following:

If no ISAKMP SA exists, the show crypto isakmp sa command does not return any output. In that case, check for the following two possible causes:

Mismatch of the pre-shared key between the RAP and the controller (legacy equipment only) Possible change of ISAKMP policies from the defaults

Pre-Shared Key Mismatch

To check for a mismatch of the pre-shared key, do the following:1. Enter the following commands to see the currently configured pre-shared key:

(vrd-rap-local) #encrypt disable (vrd-rap-local) #show running-config | include "crypto isakmp"


(vrd-rap-local) #show crypto isakmp sa peer 66.126.247.254

Initiator IP: 66.126.247.254

Responder IP: 68.165.169.218

Initiator: No

Initiator cookie:10257410b0aaae07 Responder cookie:a82d2205f2393b83

SA Creation Date: Thu Apr 9 11:08:08 2009

Life secs: 28800

Initiator Phase1 ID: asn1_dn//CN=AG0000100::00:0b:86:66:01:00

Responder Phase1 ID: asn1_dn//CN=AC0003018::00:0b:86:61:3c:dc/L=SW

Exchange Type: Main mode

Phase1 Transform: EncAlg:AES HashAlg:SHA DHGroup:#2(1024 bit)

Authentication method: Mode-config with Rivest-Shamir-Adelman Signature

XAuth IP 10.168.23.91, Phase 2 passed

IPSEC SA Rekey Number: 3

Aruba AP

Reference count: 2

N O T E

This information applies only to legacy equipment running software that is earlier than the RN version.

Building Configuration...

crypto isakmp policy 20

no crypto isakmp psk-caching

crypto isakmp key "secret" address 0.0.0.0 netmask 0.0.0.0

crypto isakmp groupname changeme



2. Enter the following commands to see the key that was originally provisioned on the RAP:(vrd-rap-local) #encrypt disable (vrd-rap-local) #show audit trail


3. Compare the shared key information in the two sets of command output.If the shared key information does not match between the two sets of command output, the RAP must be re-provisioned.If the shared key information matches, check the ISAKMP policy settings.

ISAKMP Policy Changes

To check for a change of ISAKMP policies from the default settings: 1. Enter the following command to see the configured policies:

(vrd-rap-local) #show crypto isakmp policy

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap pap-user "RAP01" > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap pap-passwd "GoAruba" > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap ikepsk "secret" > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap master "63.82.214.206" > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap no server-name > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap server-ip 63.82.214.206 > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap ap-group "remote" > -- command executed successfully

Jan 16 16:28:04 webui[508]: USER:[email protected] COMMAND:<provision-ap ap-name "RAP70" > -- command executed successfully




2. Compare the configured policies with the defaults. Modify the configured policies if they differ from the defaults.If the policies are configured correctly, check log messages for errors as described in the next section.

Checking for Error Messages

To check error messages:1. Enable crypto debugging logging on the controller, using the following command:

(vrd-rap-local) #configure terminal logging level debugging security process crypto

2. Power cycle the RAP to re-initiate the IPsec tunnel and generate IKE messages in the security log.

3. Display the security log, using the following command:(vrd-rap-local) #show log security all | inc ike

ISAKMP ENABLED

Default protection suite

encryption algorithm: 3DES - Triple Data Encryption Standard (168 bit keys)

hash algorithm: Secure Hash Algorithm

authentication method: Pre-Shared Key

Diffie-Hellman Group: #2 (1024 bit)

lifetime: [300 - 86400] seconds, no volume limit

Default RAP Certificate protection suite

encryption algorithm: AES - Advanced Encryption Standard (256 bit keys)


authentication method: Rivest-Shamir-Adelman Signature



Default RAP PSK protection suite

encryption algorithm: AES - Advanced Encryption Standard (256 bit keys)


authentication method: Pre-Shared Key






Check the IKE main mode phase lines in the command output for errors.

Apr 13 22:18:32 :103063: <DBUG> |ike| ike_phase_1_responder_send_SA_NAT_T

Apr 13 22:18:32 :103060: <DBUG> |ike|

nat_traversal.c:nat_t_generate_nat_d_hash:266 IP 63.82.214.197 Port 500

Apr 13 22:18:32 :103060: <DBUG> |ike|

nat_traversal.c:nat_t_generate_nat_d_hash:266 IP 63.82.214.197 Port 4500

Apr 13 22:18:32 :103060: <DBUG> |ike| nat_traversal.c:nat_t_exchange_check_nat_d_has_us:564 Found our matching NAT-D

payload in their packet

Apr 13 22:18:35 :124038: <INFO> |authmgr| Selected server Internal for

method=VPN; user=00:0b:86:66:02:31, essid=<>, domain=<>, server-group=default

Apr 13 22:18:35 :133004: <INFO> |localdb| Received Authentication Request for

User 00:0b:86:66:02:31

Apr 13 22:18:35 :133005: <INFO> |localdb| User 00:0b:86:66:02:31 Succesfully

Authenticated

Apr 13 22:18:35 :124004: <DBUG> |authmgr| Rx message 62/63, length 1010 from

10.3.67.2:8344

Apr 13 22:18:35 :124003: <INFO> |authmgr| Authentication result=Authentication

Successful(0), method=VPN, server=Internal, user=24.6.195.37

Apr 13 22:18:35 :124004: <DBUG> |authmgr| Auth server 'Internal' response=0

Apr 13 22:18:35 :124004: <DBUG> |authmgr| Setting authserver 'Internal' for user

24.6.195.37, client VPN

Apr 13 22:18:35 :124004: <DBUG> |authmgr| auth_user_query_resp: response

user:00:0b:86:66:02:31 ip:403096357 cookie:0

Apr 13 22:18:35 :124004: <DBUG> |authmgr| {L3} Authenticating Server is Internal

Apr 13 22:18:35 :124004: <DBUG> |authmgr| Matching `default' rules to derive role

...

Apr 13 22:18:36 :103022: <INFO> |ike| IKE Quick Mode succeeded for peer

24.6.195.37

Apr 13 22:18:36 :103033: <INFO> |ike| IKE Quick Mode succeeded internal

10.3.101.95, external 24.6.195.37



Checking XAuth

If the RAP has not been added to the local database (whitelist), it will fail the extended authentication (XAuth) process. To check whether or not XAuth has succeeded, use the following command:

(vrd-rap-local) #show log security <x>

The output should be similar to the following:

To check the whitelist, use the following command: (vrd-rap-local) #show local-userdb-ap

The command output should be similar to the following (not all fields shown):

If the RAP is missing from the whitelist, add it using the following command:(vrd-rap-local) #local-userdb-ap add mac-address <mac> ap-group <group> full-name <full name>

To correct an entry that has a mistake in the MAC address or other part of the entry, use the following command:

(vrd-rap-local) #local-userdb-ap modify mac-address <mac> ap-group <group> full-name <full name> mode [enable | disable]

Jan 28 15:45:19 10.168.20.2 2009 [10.168.20.2] localdb[1406]: <133019> <ERRS>

|localdb| User 00:0b:86:c3:58:58 was not found in the database

Jan 28 15:45:19 10.168.20.2 2009 [10.168.20.2] localdb[1406]: <133006? <ERRS>

|localdb| User 00:0b:86:c3:58:58 Failed Authentication

Jan 28 15:45:19 10.168.20.2 2009 [10.168.20.2] isakmpd[1394]: <103048> <ERRS>

|ike| IKE XAuth failed for 00:0b:86:c3:58:58

AP-entry Details

----------------

Name AP-Group Full-Name . . . AP_Authenticated . . . Enabled

---- -------- --------- . . . --------------- . . .-------

00:0b:86:66:05:a1 Partha Provisioned Yes

00:0b:86:c3:58:4c Fixed-Telecommuter Amit Provisioned Yes

00:0b:86:c3:58:96 WPA2_ONLY kazi chuck@home Provisioned Yes

00:0b:86:c3:58:92 Fixed-Telecommuter Provisioned Yes

00:0b:86:c3:58:58 Fixed-Telecommuter Brian (@home) Provisioned Yes

00:0b:86:c3:58:c0 Fixed-Telecommuter Kiran Provisioned Yes

00:0b:86:66:07:18 branch Prasad Provisioned Yes

00:0b:86:66:02:31 branch Martin Provisioned Yes

AP Entries: 8



Checking IPsec Phase 2

If IPsec phase 2 was successful, a phase 2 IPsec security association (SA) exists. To verify that an IPsec phase 2 SA exists, use the following command:

(vrd-rap-local) #show crypto ipsec sa [peer <ip-address>]


Hint: Check the command output for the most recent SA Creation Date.

If no phase 2 SA has been established, this command produces no output. If IPsec phase 2 has failed, contact Aruba Technical Support and gather the information described in the next section.

(vrd-rap-local) #show crypto ipsec sa [peer 98.234.52.200]

Initiator IP: 98.234.52.200

Responder IP: 63.82.214.206

Initiator: No

Initiator cookie:5828d039fe4d1b20 Responder cookie:15e0919fcc392d1e

SA Creation Date: Mon Sep 15 18:07:47 2008

Life secs: 7200

Initiator Phase2 ID: 192.168.117.182/255.255.255.255

Responder Phase2 ID: 63.82.214.206/255.255.255.255

Phase2 Transform: EncAlg:esp-aes256 HMAC:esp-sha-hmac

Encapsulation Mode: Transport PFS: No

OUT SPI 770ffe00, IN SPI 98275200

L2TP tunnel ID = 54, remote id = 3398, innerIP = 172.16.118.12

Aruba AP

Reference count: 3

<--- SA creation date



Information for Technical Support

With guidance from Aruba Technical Support, gather the following information: Controller logs, including technical support information IPsec transforms ISAKMP statistics Relevant output from the crypto debug logs Crypto data path statistics Packet capture on UDP port 4500

IPsec Transform Information

To display information about the IPsec transforms, use the following command:vrd-rap-local) #show crypto ipsec transform-set


ISAKMP Statistics

To display ISAKMP statistics, use the following command:(vrd-rap-local) #show crypto isakmp stats

Transform set default-transform: { esp-3des esp-sha-hmac }

will negotiate = { Transport, Tunnel }

Transform set default-ml-transform: { esp-3des esp-sha-hmac }


Transform set default-aes: { esp-aes256 esp-sha-hmac }





Main Mode Initiator exchanges started/completed = 0/0

Main Mode Responder exchanges started/completed = 273/68

Aggr Mode Initiator exchanges started/completed = 14/14

Aggr Mode Responder exchanges started/completed = 0/0

Quick Mode Initiator exchanges started/completed = 54/54

Quick Mode Responder exchanges started/completed = 117/117

XAuth Type1 Responder exchanges started/completed = 0/0

XAuth Type2 Responder exchanges started/completed = 0/0

Mode-Config Responder exchanges started/completed = 0/0

Phase1 SAs Current/Max/Total = 2/5/287

Phase2 SAs Current/Max/Total = 3/4/171

VPN Sessions Total/RAPs/Master-Local/Redundancy = 1/10/1/0

VPN License Limits Total/Platform/Current/Violation = 16777215/16777215/0/0

Switch Role: Local

CFGM triggers: Master/Local/Redund/Failed/Total = 0/1/0/0/1

Redundancy changes: Master->Standby/Standby->Master = 0/0

FPAPPS TX messages: Tunnel-Up/Tunnel-Down = 1/0

FPAPPS TX messages: cfg-map-add/cfg-map-del = 0/0

FPAPPS TX messages: Peer-map-add/Peer-map-del = 1/0

FPAPPS TX messages: SwitchIP-mapadd/SwitchIP-mapdel = 0/0

FPAPPS TX messages: New-SwitchIP-map-adds = 0

Datapath To Control DPD Triggers Received = 1056

DPD Initiate Reqs-Sent/Re-Sent/Replies-Rcvd/Dropped = 1056/0/1056/0

DPD Responder Reqs-Rcvd/Reqs-Dropped/Replies-Sent = 1140/0/1140

DPD peers detected as Dead = 0

L2TP tunnel events received: Add/Delete = 13/9

L2TP Delete tunnel events sent: Success/Fail = 3/0

RAP-PSK-caching IKE SA: New-PSK/Old-PSK/Expired/Bad = 0/0/0/0

Garbage SA deletions: ISAKMP-SA/IPSec-SA = 14/6

Rcvd Cert-chain: Verified/Failed = 0/0

Rcvd Cert-chain error: Invalid ID and pubkey = 0

Rcvd Cert-chain error: no username(mode-cfg only) = 0

Cert-chain error in encryption/decryption = 0/0

Cert-manager registration: Started/Completed = 0/0

Cert-manager errors: Cert-Not-found/No-reply = 0/0

IKE To CPFW DST-NAT messages sent = 54

Control To Datapath SA Adds/Failed Adds = 310/0

Control To Datapath SA Deletions/Failed Deletions = 242/0

Datapath To Control IKE Triggers Received/Ignored = 0/0

Timers Current/Max/Total = 11/17/25180

SA Soft timers Current/Max/Total = 4/4/185

SA Hard timers Current/Max/Total = 5/8/316

NAT-T Timers Current/Max/Total = 0/0/0

IKE Messages Current/Max/Total = 0/5/7446

Message Payloads Current/Max/Total = 0/29/24588

Message Timers Current/Max/Total = 0/2/939

IKE Exchanges Current/Max/Total = 0/4/5027

Exchange Timers Current/Max/Total = 0/4/5027



Crypto Debug Output

To display the crypto debug output, use the following command: (vrd-rap-local) #show log security 100 | include ike


Jun 30 18:35:51 :103060: <DBUG> |ike|

ike_quick_mode.c:responder_recv_HASH_SA_NONCE:2558 message negotiation succeeded

Jun 30 18:35:51 :103022: <INFO> |ike| IKE Quick Mode succeeded for peer

98.234.53.200

Jun 30 18:35:51 :103034: <INFO> |ike| IKE Quick Mode succeeded from client

external 98.234.53.200

Jun 30 18:35:51 :103060: <DBUG> |ike|

ike_quick_mode.c:ike_quick_mode_send_notify:3391 ike_quick_mode_send_notify: Added ike quick mode notify payload.

Jun 30 18:35:51 :103063: <DBUG> |ike| ipsec_sa 0x10292e3c, proto 0x10292fc4

Jun 30 18:35:51 :103063: <DBUG> |ike| ipc_setup_ipsec_dp_sa add=1, out=1,

sa=0x10292c5c, proto=0x10292fc4

Jun 30 18:35:51 :103063: <DBUG> |ike| ipc_setup_ipsec_dp_sa sa src=0x0aa85202,

dst=0x0a64652a

Jun 30 18:35:51 :103060: <DBUG> |ike| ipc.c:ipc_print_dp_packet:1313 DP:

:TRANSPORT::SA_ADD::L2TP: OFF::outgoing::ESP::AES256::Auth = SHA1:, SPI ED4C7E00, esrc AA85202, edst_ip A64652A, dst_ip 0, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello 0

Jun 30 18:35:51 :103060: <DBUG> |ike| ipc.c:ipc_modify_sb_data:848 IPSEC

dst_ip=0.0.0.0, dst_mask 0.0.0.0 inner_ip 0.0.0.0 client:yestrusted:no, Master-Local:no

Jun 30 18:35:51 :103063: <DBUG> |ike| Setup the outgoing IPSEC SA --- DONE !!




dst=0x0a64652a

Jun 30 18:35:51 :103060: <DBUG> |ike| ipc.c:ipc_print_dp_packet:1313 DP:

:TRANSPORT::SA_ADD::L2TP: OFF::incoming::ESP::AES256::Auth = SHA1:, SPI FDEC7B00, esrc A64652A, edst_ip AA85202, dst_ip 0, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello 0

Jun 30 18:35:51 :103063: <DBUG> |ike| Setup the incoming IPSEC SA --- DONE !!

Jun 30 18:35:51 :103063: <DBUG> |ike| ***** Adding to the DB Transport ESP ? SHA

******

Jun 30 18:35:53 :103063: <DBUG> |ike| ipsec_sa 0x10292e3c, proto 0x10292fc4




dst=0x0a64652a



Crypto Data Path Statistics

To display the crypto data path statistics, use the following command:(vrd-rap-local) #show datapath crypto


Packet Capture on UDP Port 4500

To obtain information about packet capture on UDP port 4500, first provision the controller to collect the data, using the following command:

(vrd-rap-local) #packet-capture udp 4500

Datapath Crypto Statistics

--------------------------

Crypto Accelerator Present

Crypto Cores In Use 2

Crypto Cores Total 2

Crypto Requests Total 1357231

Crypto Requests Queued 0

Crypto Requests Failed 0

Crypto Timeouts 0

IPSec Encryption Failures 0

IPSec Decryption Failures 0

IPSec Decryption Loops 0

IPSec Decryption BufFail 0

IPSec Decr SPI(client) ERR 0

IPSec Decrypt SA Not Ready 0

... . .

Max Crypto HW Queues 64

Crypto HW Queues Used 15

Crypto HW Queue Alloc Fail 0

... . .

L2TP Hellos Sent 69

L2TP Hello Timeouts 9



The collected data is stored as the file filter.pcap file. Convert the file into a .tar file.


No. Time Source Destination Protocol Info

172 17:20:15.02133498.234.52.200 63.82.214.206 ISAKMP Identity Protection (Main Mode)






178 17:20:16.13087898.234.52.200 63.82.214.206 ISAKMP Quick Mode




N O T E

Be sure to disable the packet capture using the packet-capture udp disable command at the completion of your troubleshooting session to reduce CPU load on the AP and controller.



Checking the IP Address Pool and Usage

After the IPsec tunnel between the controller and the RAP is established, the RAP authenticates to the configured server (for example, the server called internal db) and gets an IP address from the configured pool.

If the output from the show crypto ipsec sa command does not show an inner IP, check the existence of the IP pool using the following command:

(vrd-rap-local) #show vpdn l2tp configuration


To check usage of the IP pool, use the following command:(vrd-rap-local) #show vpdn l2tp local pool


Verify that the local pool has free IP addresses available.

Enabled

Hello timeout: 60 seconds

DNS primary server: 10.1.1.50

DNS secondary server: 0.0.0.0

WINS primary server: 0.0.0.0

WINS secondary server: 0.0.0.0

PPP client authentication methods:

PAP

IP LOCAL POOLS:

RAP-Routable-Pool: 10.168.23.1 - 10.168.23.100

IP addresses used in pool RAP-Routable-Pool

10.168.23.79

10.168.23.87

10.168.23.90-10.168.23.91

10.168.23.93-10.168.23.94

10.168.23.96

7 IPs used - 93 IPs free - 100 IPs configured



Troubleshooting RAP Bootstrapping ProblemsAfter the RAP has successfully built its IPsec tunnel to the controller and has acquired an L2TP IP address as a VPN user, the RAP is assigned a role. This role can be either the VPN default role or a role derived from the VPN authentication server. If the authentication server is local db, make sure that the desired role is configured there.

RAP bootstrapping is the process by which the RAP attempts communication with the controller using the Process Application Programming Interface protocol. The RAP

remains in the assigned VPN role until it finishes bootstrapping, and then it automatically transitions into the system role called ap-role.

Figure 96 shows an overview of how to troubleshoot problems with RAP bootstrapping.

Figure 96 Troubleshooting RAP Bootstrapping Problems

Checking the VPN Role Policies

To allow the RAP to bootstrap, the VPN role must permit these services: svc-papi, svc-ntp, svc-syslog, svc-tftp, svc-ftp, and svc-gre. To verify that the VPN role has the correctly configured policies, use the following command:

vrd-rap-local) #show rights RemoteAPR

NS

G_2

18

START HERE:

Troubleshoot RAPbootstrapping problems.

Check the VPNrole policies.

Check the RAProle transition.




If the VPN role is missing any of the required policies, add the necessary policies to the role.

Checking the RAP Role Transition

When the RAP has successfully bootstrapped, it transitions to the ap-role.

1. To verify that the RAP has transitioned to the ap-role, display the user table entries for a connected RAP, using the following command:

(vrd-rap-local) #show user-table verbose | inc <RAP-public-ip>


If the command output shows ap-role as indicated, proceed with step 2.If the command output does not show ap-role, go to step 3 on page 209.

access-list List

----------------

Position Name Location

-------- ---- --------

1 RemoteAP

RemoteAP

--------

Priority Source Destination Service Action . . . . Queue . . . .

-------- ------ ----------- ------- ------ . . . . ------- . . .

1 any any svc-papi permit Low . . . .

2 any any svc-ntp permit Low . . .

3 any any svc-syslog permit Low . . .

4 any any svc-tftp permit Low . . .

5 any any svc-ftp permit Low . . .

6 any any svc-gre permit Low . . .

Expired Policies (due to time constraints) = 0

(vrd-rap-local) #show user-table verbose | inc 98.234.52.200

Users

-----

IP MAC Name Role Age(d:h:m) Auth VPN Link ...

--------- ---------- ---- ---- --------- ---- --------- ...

172.16.118.12 00:a0:c8:1c:fe:eb RAP01 ap-role 01:23:08 VPN 8.234.52.200 ...

98.234.52.200 00:a0:c8:1c:fe:eb logon 01:23:08 ...

User Entries: 2/2



2. If the command output shows that the connected RAP has transitioned to the ap-role, check to see if the AP is active on the controller and which SSIDs it is advertising at the remote location. To do so, use the following commands, specifying the L2TP IP address for the RAP:(vrd-rap-local) #show ap active ip-address <l2tp-ip-address>(vrd-rap-local) #show ap bss ip-address <l2tp-ip-address>

If the AP is active on the controller, the command output should be similar to the following (not all fields shown):

If the RAP is advertising the correct SSIDs, the command output should be similar to the following (not all fields shown):

3. If the show user-table verbose command output does not show ap-role, check the configured rights for ap-role, using the following command:(vrd-rap-local) #show rights ap-role

(vrd-rap-local) #show ap active ip-address 172.16.118.12

Active AP Table

---------------

Name Group IP Address 11g Clients 11g Ch/EIRP/MaxEIRP . . . . AP Type Flags Uptime

----- ----- ---------- ----------- ------------------- . . . . ------- ----- ------

RAP70 remote 172.16.118.12 0 AP:11/1.5/33 . . . . 70 RA 7h:30m:42s

Num APs:1

(vrd-rap-local) #show ap bss ip-address 172.16.118.12

Aruba AP BSS Table

------------------

bss ess s/p ip phy type ch/EIRP/max-EIR Pcur-cl ap name . . .

--- --- --- -- --- ---- --------------- ------- ------- . . .

00:0b:86:d9:11:70 tunneled 3/6 172.16.118.12 a ap 153/21/36 0 RAP70 . . .

00:0b:86:d9:11:60 tunneled 3/6 172.16.118.12 g ap 11/1.5/33 0 RAP70 . . .

Num APs:2



Verify that the system role ap-role contains the rules shown in the following command output:

Common Problem Symptoms

Two common symptoms of problems with the RAP are: The RAP is stuck in the temporary role. The L2TP address changes in output from repeated commands on the same device.

RAP Stuck in Temporary Role

If the RAP is stuck in the temporary role, the temporary role may not have the correct rules to allow the RAP to bootstrap successfully.

Display the ACL rules for the temporary role using the following command:(vrd-rap-local) #show ip access-list RemoteAP

.

.

.

control

-------

Priority Source Destination Service Action TimeRange Log Expired Queue ....

-------- ------ ----------- ------- ------ --------- --- ------- ----- ----

1 user any udp 68 deny Low

2 any any svc-icmp permit Low

3 any any svc-dns permit Low

4 any any svc-papi permit Low

5 any any svc-cfgm-tcp permit Low

6 any any svc-adp permit Low

7 any any svc-tftp permit Low

8 any any svc-dhcp permit Low

9 any any svc-natt permit Low

ap-acl

------


-------- ------ ----------- ------- ------ --------- --- ------- ----- ----

1 any any svc-gre permit Low

2 any any svc-syslog permit Low

3 any user svc-snmp permit Low

4 user any svc-snmp-trap permit Low

5 user any svc-ntp permit Low

Expired Policies (due to time constraints) = 0



The command output should be similar to the following example and should contain (at a minimum) the same rules shown in the example.

Troubleshooting tip: Power cycle the RAP and run the show acl hits command multiple times to check which rules are being hit. The command output should be similar to the following (not all fields shown):


-------- ------ ------------ ------- ------ --------- --- ------- -----

1 any any svc-papi permit Low

2 any any svc-ntp permit Low

3 any any svc-syslog permit Low

4 any any svc-tftp permit Low

5 any any svc-ftp permit Low

6 any any svc-gre permit Low

(vrd-rap-local) #show acl hits

User Role ACL Hits

------------------

Role Policy Src Dst Service Action Dest/Opcode New Hits Total Hits ...

---- ------ --- --- ------- ------ ----------- -------- ---------- ---

logon allow-l2tp any any svc-l2tp permit 13 13 ...

ap-role control any any svc-icmp permit 5 5 ...

ap-role control any any svc-papi permit 588 588 ...

ap-role ap-acl any any svc-gre permit 11 11 ...

ap-role ap-acl any any svc-syslog permit 635 635 ...

ap-role ap-acl user any svc-ntp permit 15 15 ...

RemoteAP RemoteAP any any svc-dns permit 2 2 ...

RemoteAP RemoteAP any any svc-papi permit 19 19 ...

RemoteAP RemoteAP any any svc-ftp permit 3 3 ...

RemoteAP RemoteAP any any svc-syslog permit 2 2 ...

RemoteAP RemoteAP any any svc-ntp permit 13 13 ...

RemoteAP any any 0 deny 2 2 ...



Continual Changes to the L2TP IP address

If you use the show user-table command or show crypto ipsec sa command several times and see a different L2TP IP address in each instance of command output for the same peer, this may indicate IPsec tunnel flapping.

Check for possible packet loss on the path between the controller and the RAP. The check should include the intranet, the Internet, and the RAP local network.

Troubleshooting Wired Port Configuration ProblemsPorts on the RAP can operate in two modes: Active/Standby mode (default) Wired Port mode (tunnel, bridge, or split-tunneling)

The following profiles are contained within the wired-port-profile, which is used to configure the port as a wired port:

Wired AP profile Ethernet interface link profile AAA profile (for an untrusted port)

Figure 97 shows an overview of how to troubleshoot problems with wired port configuration.

Figure 97 Troubleshooting Wired Port Configuration Problems

RN

SG

_219

START HERE:

Troubleshoot wired portconfiguration problems.

Verify that the wired port hasbeen enabled.

Enter the command:show ap active

orshow ap bss-table

orshow datapath tunnel table

Check the port profile.Enter the commands:

show ap wired-ap-profilerap

Check the authentication profile.Enter the commands:

show aaa authenticationwired

show aaa profile<profile-name>



Checking for an Enabled Wired Port

If the wired port is not working correctly, possibly it has not been enabled during the configuration process. In the following command examples, the highlighted lines of the command output include flags (E or e) showing the port as enabled.

(vrd-rap-local) #show ap active

Active AP Table

---------------

Name Group IP Address 11g Clients11g Ch/EIRP/MaxEIRP... AP Type Flags ....

---- ----- ----------- -------------- ---------------... ------- ----- ....

RAP70 remote 172.16.118.12 0 AP:11/1.5/33 ... 70 RE ....

Flags: R = Remote AP; P = PPPOE; M = Mesh; E = Wired AP enabled; ....

... .

Num APs:1

(vrd-rap-local) #show ap bss-table

Aruba AP BSS Table

------------------

bss ess s/p ip phy type ch/EIRP/max-EIRP cur-cl ap name in-t(s) ...

--- --- --- -- --- ---- ---------------- ----- ------- ------ ...

00:0b:86:d9:11:70 tunneled 3/6 172.16.118.12 a ap 36/13/23 0 RAP70 0 ...

00:0b:86:d9:11:60 tunneled 3/6 172.16.118.12 g ap 11/1.5/33 0 RAP70 0 ...

00:0b:86:c5:91:17 N/A 3/6 172.16.118.12 e N/A N/A N/A RAP70 0 ...

...

Num APs:3

Num Associations:0



Checking the Port Profile

If indications that the port is enabled are missing from the command output, check the port profile, using the following command:

(vrd-rap-local) #show ap wired-ap-profile rap


(vrd-rap-local) #show datapath tunnel table

Datapath Tunnel Table Entries

-----------------------------

Flags: E - Ether encap, I - Wi-Fi encap, F - IP fragment OK

W - WEP, K - TKIP, A - AESCCM, M - no mcast src filtering

S - Single encrypt, U - Untagged, X - MUX

T - Trusted, L - No looping, d - Drop Bcast/Mcast

a - Reduce ARP packets in the air

# Source Destination Prt Type MTU VLAN Acls BSSID ... Flags

- ------ ------------ --- ----- --- ---- ---- ----- ... -----

13 SPI03242300 in 63.82.214.206 50 IPSE 1500 0 routeDest FFFF ...

12 10.100.135.97 172.16.118.12 47 8300 1200 88 0 0 1 00:0B:86:D9:11:60 ... IMAS

11 10.100.135.97 172.16.118.12 47 8200 1200 88 0 0 1 00:0B:86:D9:11:70 ... IMAS

14 10.100.135.97 172.16.118.12 47 8100 1200 88 0 0 0 00:00:00:00:00:00 ... E

Wired AP profile "rap"

----------------------

Parameter Value

--------- -----

Wired AP enable Enabled

Forward mode tunnel

Switchport mode access

Access mode VLAN 88

Trunk mode native VLAN 1

Trunk mode allowed VLANs all

Trusted Not Trusted

Broadcast Broadcast



Checking the Authentication Profile

If the command output indicates that the wired port uses tunnel forwarding mode and is not trusted, check the authentication profile using the following commands:

#show aaa authentication wired #show aaa profile <profile-name>


(vrd-rap-local) #show aaa authentication wired

Wired Authentication Profile

----------------------------

Parameter Value

--------- -----

AAA Profile dot1x-wired

(vrd-rap-local) #show aaa profile dot1x-wired

AAA Profile "dot1x-wired"

-------------------------

Parameter Value

--------- -----

Initial role logon

MAC Authentication Profile N/A

MAC Authentication Default Role guest

MAC Authentication Server Group default

802.1X Authentication Profile 8021x-wired

802.1X Authentication Default Role employee

802.1X Authentication Server Group radius_servers

RADIUS Accounting Server Group N/A

XML API server N/A

RFC 3576 server N/A

User derivation rules N/A

Wired to Wireless Roaming Disabled

SIP authentication role N/A



Troubleshooting Split-Tunnel Mode ProblemsFigure 98 shows an overview of how to troubleshoot problems with split-tunnel mode configuration.

Figure 98 Troubleshooting Split-Tunnel and Bridge Mode Configuration

Split-tunnel mode has the following characteristics: Encryption and decryption occur on the AP. For static encryption, the 802.11 management frames are handled locally by the AP. For dynamic encryption, the 802.11 frames are handled locally by the AP, except for the

association response, which comes from the controller. Corporate traffic is tunneled.

RN

SG

_220

START HERE:

Troubleshoot split-tunnelmode configurationproblems.

Check the user table.Enter the command:show user-table

Verify that the split-tunnelSSID is active on the RAP.

Enter the command:show ap bss-tableap-name <ap-name>

Verify that a GRE tunnel exists forthe SSID with 802.1X

authentication.Enter the command:

show ap datapath tunnel table

Verify that the client can associateto the SSID.

Enter the command:show ap debug client-table

ap-name <ap-name>

Verify that the client succeededwith 802.1X authentication.

Enter the command:show dot1x supplicant-info

list all

Verify that the client receiveda DHCP address.

Enter the command:C:\>ipconfig/all



Non-corporate traffic is handled using NAT, then bridged to the wired port as per the user role and its associated ACLs.

To troubleshoot split-tunnel configuration for the RAP, verify the following conditions, using the indicated commands:

1. Does the user table indicate that the RAP is configured in split-tunneling mode?#show user-table

2. Is the split-tunnel SSID active (being advertised) on the AP? #show ap bss-table ap-name <ap-name>

3. Is there a GRE tunnel for the split-tunnel SSID with 802.1X authentication?#show datapath tunnel table

4. Is the client able to associate to the SSID?#show ap debug client-table ap-name <ap-name>

5. Has the client succeeded with 802.1X authentication?#show dot1x supplicant-info list-all

6. Has the client received a DHCP IP address?C:\>ipconfig/all

7. Does split-tunneling work at the client end?C:\>tracert

Is the RAP Configured in Split-Tunnel Mode?

Check the user table using the following command:#show user-table

The output should be similar to the output shown below. The command output should indicate that the port has been configured to operate in split-tunnel forwarding mode.



Is the Split-Tunnel SSID Active on the AP?

To determine whether or not the bridge SSID is active (being advertised) on the AP, check that the appropriate split-tunnel SSID is operational by running the following command:

#show ap bss-table ap-name <ap_name>

For example:

Does the Split-Tunnel SSID Have a GRE Tunnel with 802.1X?

To verify whether or not the split-tunnel SSID has a GRE tunnel with 802.1X authentication, check the controller tunnel table for the appropriate bssid, using the following command:

#show datapath tunnel table

For example:

Can the Client Associate to the SSID?

To verify whether or not the client can associate to the SSID, check the AP client table using the following command:

#show ap debug client-table ap-name <ap_name>

(vrd-rap-local) #show ap bss-table ap-name RAP70

Aruba AP BSS Table

------------------

bss ess s/p ip phy type ch/EIRP/max-EIRP cur-cl ap name ...

--- --- --- -- --- ---- ---------------- ------ ------- ...

00:0b:86:d9:11:73 split-8021x 3/6 172.16.118.12 a ap 153/19/36 1 RAP70 ...



-----------------------------

# Source Destination Prt Type MTU VLAN Acls BSSID ....

--- -------------- -------------- --- ---- ---- ---- -------------- ----------------- ....

13 10.100.135.97 172.16.118.12 47 8230 1200 21 0 0 59 00:0B:86:D9:11:73 ....



The following example shows Client MAC 00:13:02:20:4b:43 associated to ESSID split-8021X (BSSID 00:0b:86:d9:11:73).

Has the Client Succeeded with 802.1X Authentication?

To verify whether or not the client succeeded with 802.1X authentication, check the controller dot1x authentication list using the following command:

#show dot1x supplicant-info list-all

For example:

If 802.1X authentication has failed (Auth = No), check the output of #show auth-tracebuf count 40 for further hints.

(vrd-rap-local) #show ap debug client-table ap-name rap70

Client Table

------------

MAC ESSID BSSID Assoc_State HT_State AID PS_State ....

--- ----- ----- ----------- -------- --- -------- ....

00:13:02:20:4b:43 split-8021x 00:0b:86:d9:11:73 Associated None 0x1 Awake ....

(vrd-rap-local) #show dot1x supplicant-info list-all

802.1x User Information

-----------------------

MAC Name Auth AP-MAC Enc-Key/Type ... EAP-Type Remote

--- ----- ---- ------ ------------ ... -------- ------

00:13:02:20:4b:43 jsmith Yes 00:0b:86:d9:11:73 * * * * */WPA2-AES ... EAP-PEAP Yes



For example:

Auth Trace Buffer

-----------------

Jan 23 15:28:38 station-up * 00:13:02:20:4b:43 00:0b:86:d9:11:73 - - wpa2 aes

Jan 23 15:28:38 station-data-ready * 00:13:02:20:4b:43 00:00:00:00:00:00 21 -

Jan 23 15:28:38 wpa2-key1 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 117

Jan 23 15:28:38 eap-term-start -> 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - -

Jan 23 15:28:38 station-term-start * 00:13:02:20:4b:43 00:0b:86:d9:11:73 21 -

Jan 23 15:28:38 client-finish -> 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - -

Jan 23 15:28:38 server-finish <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 61

Jan 23 15:28:38 server-finish-ack -> 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - -

Jan 23 15:28:38 inner-eap-id-req <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 35

Jan 23 15:28:38 inner-eap-id-resp -> 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - - jsmith

Jan 23 15:28:38 eap-mschap-chlg <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 67

Jan 23 15:28:38 eap-mschap-response -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 6 49

Jan 23 15:28:38 mschap-request -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 6 - jsmith

Jan 23 15:28:38 mschap-response <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/ias - - jsmith

Jan 23 15:28:38 eap-mschap-success <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 83

Jan 23 15:28:38 station-data-ready * 00:13:02:20:4b:43 00:00:00:00:00:00 21 -

Jan 23 15:28:38 eap-mschap-success-ack-> 00:13:02:20:4b:43 00:0b:86:d9:11:73 - -

Jan 23 15:28:38 eap-tlv-rslt-success <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 43

Jan 23 15:28:38 eap-tlv-rslt-success -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 2

Jan 23 15:28:38 eap-success <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term - 4

Jan 23 15:28:38 wpa2-key1 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 117

Jan 23 15:28:38 wpa2-key2 -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 119

Jan 23 15:28:38 wpa2-key3 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 151

Jan 23 15:28:38 wpa2-key4 -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 95

Jan 23 15:28:38 rem-ap-setkey <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 - 16 wpa aes



Has the Client Received a DHCP IP Address from the Local LAN?

To verify whether or not the client has received a DHCP IP address from the local LAN, check the IP information for the client PC. On a system running Windows, the appropriate command is:

C:\>ipconfig /all

In the following example, the 10.168.21.0/24 subnet is the VLAN 21 subnet configured in the split-tunnel virtual-ap.

If the user has not received an IP address, it is important to check the AAA profile initial role and verify that svc-dhcp is permitted. If that is the case, then DHCP debugging may be in order.

To enable DHCP debugging on the controller, use the following command:configure terminal logging level debugging network subcat dhcp

Then display the network log using the following command:show log network count 20

Troubleshooting Tips

Wired and wireless users connected to RAPs are visible in the user table, along with the forwarding mode of the interface to which they are connected. To see an example of the user table, refer to page 217.

If the remote users do not appear in the user table, use the following commands to investigate:#show datapath user ap-name <ap_name> table

#show datapath session ap-name <ap_name> table

#show datapath bridge ap-name <ap_name> table

#show acl acl-table <acl_id>

C:\>ipconfig /all

Ethernet adapter Wireless Network Connection 7:

Connection-specific DNS Suffix . : atac.net

Description . . . . . . . . . . . : Intel(R) PRO/Wireless 3945ABG Network Connection

Physical Address. . . . . . . . . : 00-13-02-20-4B-43

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 10.168.21.254

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.168.21.1

DHCP Server . . . . . . . . . . . : 10.168.21.1

DNS Servers . . . . . . . . . . . : 10.100.135.50

10.100.135.50

Lease Obtained. . . . . . . . . . : Friday, January 23, 2009 3:26:44 PM

Lease Expires . . . . . . . . . . : Saturday, January 24, 2009 3:26:44 PM



For example:

(vrd-rap-local) #show datapath user ap-name RAP70 table

Datapath User Table Entries

---------------------------

Flags: P - Permanent, W - WEP, T- TKIP, V - ProxyArp for User, A - ProxyARP to User, N - VPN

IP MAC ACLs Contract Location Age Sessions Flags

-- --- ---- -------- -------- --- -------- ----

192.168.117.182 00:0B:86:C5:91:16 2700/0 0/0 2 0 1/65535 P

10.168.21.254 00:13:02:20:4B:43 56/0 0/0 2 0 2/65535

0.0.0.0 00:13:02:20:4B:43 56/0 0/0 2 0 0/65535 P

<-- Remote user

(vrd-rap-local) #show acl acl-table 56

AclTable

--------

ACL Type ACE Index Ace Count Name Applied

--- ---- --------- --------- ---- -------

56 role 327 7 split-role 0 <-- Default dot1x role



The command output from show datapath session indicates that the SSH connection to non-corporate networks (10.100.135.12) is source-NAT’ed to the AP IP address 192.168.117.182, which in turn pings to a corporate IP address (10.1.1.50) traveling over the tunnel.

(vrd-rap-local) #show datapath session ap-name RAP70 table

Datapath Session Table Entries

------------------------------

Flags: F - fast age, S - src NAT, N - dest NAT

D - deny, R - redirect, Y - no syn

H - high prio, P - set prio, T - set ToS

C - client, M - mirror, V - VOIP

I - Deep inspect, U - Locally destined

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags

--------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----

10.168.21.254 10.100.135.12 6 1272 22 0 0 0 1 local 7a SRC

00:0B:86:C5:91:16 0806 0 0 0 0 local 1a F

10.100.135.12 192.168.117.182 6 22 1272 0 0 0 0 local 7a N

63.82.214.206 192.168.117.182 17 4500 4500 0 0 0 0 local f77c F

10.1.1.50 10.168.21.254 1 2304 0 0 0 0 0 dev12 d FI

10.168.21.254 10.1.1.50 1 2304 2048 0 0 0 0 dev12 d FYCI

10.1.1.50 10.168.21.254 1 2048 0 0 0 0 0 dev12 12 FI

10.168.21.254 10.1.1.50 1 2048 2048 0 0 0 0 dev12 12 FYCI

10.1.1.50 10.168.21.254 1 2816 0 0 0 0 0 dev12 3 FI

10.168.21.254 10.1.1.50 1 2816 2048 0 0 0 0 dev12 3 FYCI

192.168.117.182 63.82.214.206 17 4500 4500 0 0 0 0 local f77c FC

10.1.1.50 10.168.21.254 1 2560 0 0 0 0 0 dev12 8 FI

10.168.21.254 10.1.1.50 1 2560 2048 0 0 0 0 dev12 8 FYCI

<-- SSH session

<-- Ping to corporate IP

(vrd-rap-local) #show datapath bridge ap-name RAP70 table

Datapath Bridge Table Entries

-----------------------------

Flags: P - Permanent, D - Deny, R - Route, M - Mobile, X - Xsec

MAC VLAN Assigned VLAN Destination Flags

----------------- ---- ------------- ----------- -----

00:13:02:20:4B:43 21 21 dev12

00:10:DB:5B:C0:22 1 1 dev4

00:0B:86:00:F3:20 21 21 dev7

00:0B:86:C5:91:16 1 1 local P

< User MAC address

< Controller MAC address

< Default gateway MAC address

< RAP Enet0 port MAC address



The following example shows the controller access list called split-acl:

Access-list split-acl downloaded to the RAP:

Does Split-Tunneling Work at the Client End?

To verify whether or not split-tunneling works at the client end, run a traceroute to one host on the corporate network and another to a host on the Internet and verify that the traffic takes the correct path.

(vrd-rap-local) #show netdestination corp

corp

----

Position Type IP addr Mask/Range

-------- ---- ------- ----------

1 network 10.1.1.0 255.255.255.0

2 network 10.100.101.0 255.255.255.0

3 network 10.100.105.0 255.255.255.0

4 network 10.168.21.0 255.255.255.0

(vrd-rap-local) #show ip access-list split-acl

split-acl

---------

Priority Source Destination Service Action TimeRange Log Expired Queue TOS ....

-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ....

1 any any svc-dhcp permit Low

2 any corp any permit Low

3 any any any route src-nat Low

(vrd-rap-local) #show datapath acl 56 ap-name RAP70

Datapath ACL 52 Entries

-----------------------

Flags: P - permit, L - log, E - established, M/e - MAC/etype filter

S - SNAT, D - DNAT, R - redirect, r - reverse redirect m - Mirror

I - Invert SA, i - Invert DA, H - high prio, O - set prio

A - Disable Scanning, T - set TOS, 4 - IPv4, 6 - IPv6

----------------------------------------------------------------

1: any any 17 0-65535 67-68 P4

2: any 10.1.1.0 255.255.255.0 any P4 hits 4

3: any 10.100.101.0 255.255.255.0 any P4

4: any 10.100.105.0 255.255.255.0 any P4

5: any 10.168.21.0 255.255.255.0 any P4 hits 13

6: any any any PSR4 hits 8



In the following example, host 10.100.135.12 is not on the corporate network and therefore should match the rule any any any route src-nat.

In the following example, host 10.100.105.243 belongs to the corporate network and therefore should match the rule any corp any permit.

Troubleshooting Bridge Mode ProblemsTo troubleshoot bridge mode for the RAP, verify the following conditions, using the indicated commands:

1. What does the user table indicate about the configured operational mode of the RAP?#show user-table

2. Is the bridge SSID active (being advertised) on the AP? #show ap bss-table ap-name <ap-name>

3. Is there a GRE tunnel for the bridge SSID with 802.1X authentication?#show datapath tunnel table

4. Is the client able to associate to the SSID?#show ap debug client-table ap-name <ap-name>

5. Has the client succeeded with 802.1X authentication?#show dot1x supplicant-info list-all

C:\>tracert -d 10.100.135.12

Tracing route to 10.100.135.12 over a maximum of 30 hops

1 * * * Request timed out.

2 1 ms 1 ms 1 ms 192.168.117.1

3 2 ms 2 ms 2 ms 98.234.52.193

4 3 ms 2 ms 1 ms 10.100.135.12

Trace complete.

<-- RAP local network gateway

C:\>tracert -d 10.100.105.243

Tracing route to 10.100.105.243 over a maximum of 30 hops

1 * * * Request timed out.

2 3 ms 2 ms 2 ms 10.100.101.254

3 22 ms 3 ms 3 ms 10.100.105.243

Trace complete.

<-- Controller default gateway



6. Has the client received a DHCP IP address?C:\>ipconfig/all

Figure 99 shows an overview of how to troubleshoot problems with split-tunnel or bridge mode configuration.

Figure 99 Troubleshooting Split-Tunnel and Bridge Mode Configuration

Bridge mode can be configured with either of the following encryption types: Dynamic encryption (802.1X authentication)

No GRE tunnel to the controller Only Process Application Programming Interface protocol communication with the controller

Static encryption (pre-shared key). GRE tunnel for dynamic keying (802.1X) Process Application Programming Interface protocol communication

RN

SG

_223

START HERE:

Troubleshoot bridgemode configurationproblems.

Check the user table.Enter the command:show user-table

Verify that the bridgeSSID is active on the RAP.

Enter the command:show ap bss-tableap-name <ap-name>

Verify that a GRE tunnel exists forthe SSID with 802.1X

authentication.Enter the command:

show ap datapath tunnel table

Verify that the client can associateto the SSID.

Enter the command:show ap debug client-table

ap-name <ap-name>

Verify that the client succeededwith 802.1X authentication.

Enter the command:show dot1x supplicant-info

list all

Verify that the client receiveda DHCP address.

Enter the command:C:\>ipconfig/all



Checking the Configured Mode

To check the configured mode for the RAP, check the user table using the following command:#show user-table

The output should be similar to the input sample on page 217 and should indicate that the port has been configured to operate in bridge mode.

Bridge Mode with Dynamic Encryption

Check the following conditions: Is the bridge SSID active on the AP (being advertised)? Is there a GRE tunnel for the bridge SSID with 802.1X authentication? Is the client able to associate to the SSID? Has the client succeeded with 802.1X authentication? Has the client received a DHCP IP address from the local LAN?

Is the Bridge SSID Active on the AP?

To determine whether or not the bridge SSID is active on the AP, check that the appropriate bridge SSID is operational by running the following command:

#show ap bss-table ap-name <ap_name>

For example:

(vrd-rap-local) #show ap bss-table ap-name RAP70

Aruba AP BSS Table

------------------


--- --- --- -- --- ---- ---------------- ------ ------- ...

00:0b:86:d9:11:70 bridge8021x 3/6 172.16.118.12 a ap 153/16/36 1 RAP70 ...

00:0b:86:d9:11:71 bridge-psk 3/6 172.16.118.12 a ap 153/16/36 0 RAP70 ...



Does the Bridge SSID Have a GRE Tunnel with 802.1X?

To verify whether or not the bridge SSID has a GRE tunnel with 802.1X authentication, check the controller tunnel table for the appropriate bssid, using the following command:

#show datapath tunnel table

For example:

Can the Client Associate to the SSID?

To verify whether or not the client can associate to the SSID, check the AP client table using the following command:

#show ap debug client-table ap-name <ap_name>

The following example shows Client MAC 00:13:02:20:4b:43 associated to ESSID bridge8021X (BSSID 00:0b:86:d9:11:70).

Has the Client Succeeded with 802.1X Authentication?

To verify whether or not the client succeeded with 802.1X authentication, check the controller dot1x authentication list using the following command:

#show dot1x supplicant-info list-all

For example:



-----------------------------

# Source Destination Prt Type MTU VLAN Acls BSSID ....

--- ------ ----------- ---- ---- --- ---- ---- ----- ....

20 10.100.135.97 172.16.118.12 47 8200 1200 1 0 0 59 00:0B:86:D9:11:70 ....

(vrd-rap-local) #show ap debug client-table ap-name rap70

Client Table

------------

MAC ESSID BSSID Assoc_State HT_State AID PS_State ....

--- ----- ----- ----------- -------- --- -------- ....

00:13:02:20:4b:43 bridge8021x 00:0b:86:d9:11:70 Associated None 0x1 Awake....

(vrd-rap-local) #show dot1x supplicant-info list-all

802.1x User Information

-----------------------

MAC Name Auth AP-MAC Enc-Key/Type ... EAP-Type Remote

--- ---- ---- ------ ------------ -------- ------

00:13:02:20:4b:43 jsmith Yes 00:0b:86:d9:11:70* * * * */WPA2-AES ... EAP-PEAP Yes



Has the Client Received a DHCP IP Address from the Local LAN?

To verify whether or not the client has received a DHCP IP address from the local LAN, check the IP information for the client PC. On a system running Windows, the appropriate command is:

C:\>ipconfig /all

In the following example, the 192.168.117.0/24 subnet is the local subnet where the RAP is connected.

Troubleshooting Tips

Wired and wireless users connected to the RAP are visible in the user table, along with the forwarding mode of the interface to which they are connected. To see an example of the user table, see page 217.

If the remote user does not appear in the user table, use the following commands to investigate:#show datapath user ap-name <ap_name> table

#show datapath session ap-name <ap_name> table

#show datapath bridge ap-name <ap_name> table

#show acl acl-table <acl_id>

C:\>ipconfig /all

Ethernet adapter Wireless Network Connection 7:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) PRO/Wireless 3945ABG Network Connection

Physical Address. . . . . . . . . : 00-13-02-20-4B-43

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 192.168.117.152

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.117.1

DHCP Server . . . . . . . . . . . : 192.168.117.1

DNS Servers . . . . . . . . . . . : 10.1.1.50

10.1.1.50

Lease Obtained. . . . . . . . . . : Wednesday, January 21, 2009 2:25:16 PM

Lease Expires . . . . . . . . . . : Thursday, January 22, 2009 2:25:16 PM



For example:

(vrd-rap-local) #show datapath user ap-name RAP70 table

Datapath User Table Entries

---------------------------

Flags: P - Permanent, W - WEP, T- TKIP, V - ProxyArp for User, A - ProxyARP to User, N - VPN

IP MAC ACLs Contract Location Age Sessions Flags

--------------- ----------------- ------- --------- -------- --- --------- -----

192.168.117.182 00:0B:86:C5:91:16 2700/0 0/0 2 0 1/65535 P

192.168.117.152 00:13:02:20:4B:43 52/0 0/0 2 3 0/65535

0.0.0.0 00:13:02:20:4B:43 52/0 0/0 2 0 0/65535 P

<-- Remote user

(vrd-rap-local) #show acl acl-table 52

AclTable

--------

ACL Type ACE Index Ace Count Name Applied

--- ---- --------- --------- ---- -------

52 role 277 3 authenticated 0 <-- Default dot1x role

(vrd-rap-local) #show datapath session ap-name RAP70 table

Datapath Session Table Entries

------------------------------

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags

-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----

00:13:02:20:4B:43 0806 0 0 0 0 dev12 3f F

00:0B:86:C5:91:16 0806 0 0 0 0 local 19 F

192.168.117.152 10.100.135.94 6 1508 23 0 0 0 1 dev12 3f C

10.100.135.94 192.168.117.152 6 23 1508 0 0 0 1 dev12 3f

63.82.214.206 192.168.117.182 17 4500 4500 0 0 0 0 local b97a F

192.168.117.182 63.82.214.206 17 4500 4500 0 0 0 0 local b97a FC

Telnet<--session

<-- RAPNAT-T

session



(vrd-rap-local) #show datapath bridge ap-name RAP70 table

Datapath Bridge Table Entries

-----------------------------

Flags: P - Permanent, D - Deny, R - Route, M - Mobile, X - Xsec

MAC VLAN Assigned VLAN Destination Flags

----------------- ---- ------------- ----------- -----

00:13:02:20:4B:43 1 1 dev12

00:10:DB:5B:C0:22 1 1 dev4

00:0B:86:C5:91:16 1 1 local P

<-- User MAC address<-- Default gateway MAC address

(vrd-rap-local) #show datapath acl 52 ap-name RAP70

Datapath ACL 52 Entries

-----------------------

Flags: P - permit, L - log, E - established, M/e - MAC/etype filter

S - SNAT, D - DNAT, R - redirect, r - reverse redirect m - Mirror

I - Invert SA, i - Invert DA, H - high prio, O - set prio

A - Disable Scanning, T - set TOS, 4 - IPv4, 6 - IPv6

----------------------------------------------------------------

1: any any any P4 hits 124 <-- ACL 52 downloaded to the RAP



Bridge Mode with Static Encryption (Pre-Shared Key)

The important difference between a bridge SSID with pre-shared key encryption and an SSID with dynamic key encryption is that no GRE tunnel is established with the controller. Only Process Application Programming Interface protocol communication (UDP 8211) between the controller and the RAP remains.

For example:

To troubleshoot bridge mode with static encryption, you use the same commands as those described for bridge mode with dynamic encryption.

Important:If the RAP is plugged into a switch that does not support VLAN tagging (such as most home-office low-end switches), it is important for wireless traffic to be bridged out of the enet0 port of the RAP untagged. Therefore, the VLAN configured in the bridge virtual-ap profile should match the “native VLAN” option in the ap system profile the RAP belongs to.

If this condition does not exist, a common symptom is for the client to associate and authenticate successfully without being able to get an IP address from the local network.

(vrd-rap-local) # show ap bss-table

Aruba AP BSS Table

------------------


--- --- --- -- --- ---- ---------------- ------ ------- ...

00:0b:86:d9:11:70 bridge8021x 3/6 172.16.118.12 a ap 153/21/36 0 RAP70

00:0b:86:d9:11:71 bridge-psk 3/6 172.16.118.12 a ap 153/21/36 1 RAP70 ...



-----------------------------

# Source Destination Prt Type MTU VLAN Acls BSSID ...

- ------ ----------- --- ---- ---- ---- ---------- ----- ...

20 10.100.135.97 172.16.118.12 47 8200 1200 1 0 0 59 00:0B:86:D9:11:70 ...



For example:

(vrd-rap-local) #show ap-group remote

AP group "remote"

-----------------

Parameter Value

--------- -----

Virtual AP bridge8021x-vap

Virtual AP bridge-psk-vap

….

AP system profile default….

(vrd-rap-local) #show wlan virtual-ap bridge8021x-vap

Virtual AP profile "bridge8021x-vap"

------------------------------------

Parameter Value

--------- -----

Virtual AP enable Enabled

Allowed band all

SSID Profile bridge8021x

VLAN 1

Forward mode bridge

…..

(vrd-rap-local) #show ap system-profile default

AP system profile "default"

---------------------------

Parameter Value

--------- -----

LMS IP N/A

Backup LMS IP N/A

LMS Preemption Disabled

LMS Hold-down Period 600 sec

Master controller IP address N/A

LED operating mode (AP-12x only) normal

RF Band g

Double Encrypt Disabled

Native VLAN ID 1

…



Appendix A: Forwarding Mode Feature Matrix

Table 16 Remote Access Point (RAP) Forwarding Feature Matrix

Tunnel Mode

Bridge Mode

Split-Tunnel Mode

ARM - Channel Selection Yes Yes Yes

ARM - Power Selection Yes Yes Yes

ARM - Rogue Aware Yes Yes Yes

ARM - VoIP Aware Yes No No

ARM - Configurable App Aware Yes Yes Yes

ARM - PS Aware Yes Yes Yes

ARM - Client Aware Yes Yes Yes

ARM - Mode Aware Yes Yes Yes

ARM - Load Aware Yes Yes Yes

ARM - Spectrum Load Balancing Yes No Yes

Threshold Load Balancing (clients) No No No

Threshold Load Balancing (utilization) No No No

Band Steering Yes No Yes

Air Time Fairness (default access) Yes Yes Yes

Air Time Fairness (fair access) Yes Yes Yes

Air Time Fairness (preferred access) Yes Yes Yes

SSID Bandwidth Reservations Yes Yes Yes

Local Probe Response Yes Yes Yes

Central Probe Response Yes Yes Yes

BC/MC Optimization Yes No No

Drop Mcast/Bcast Yes No No

Battery Boost Yes No No

Proxy ARP Yes No No

DoS Prevention Yes Yes Yes

Station Blacklisting Yes No Yes

Blacklist Timer Yes No Yes

Call Admission Control Yes No No

AAA User Delete Yes No Yes

Aruba Networks, Inc. Forwarding Mode Feature Matrix | 235


Aruba Networks, Inc. Forwarding Mode Feature Matrix | 236


Appendix B: Provisioning Parameters for Verified USB Modems

Aruba has assembled key provisioning settings for each of the USB modems that have been tested and verified with this software release (Table 17). This information is subject to change without notice by the modem manufacturers; it is provided on an as-is basis for the convenience of our customers.

For details about how to provision the RAP and the modem, refer to the ArubaOS Release Note, Version 3.3.2.x-rn3.0.

Table 17 3G Modem Configuration Settings by Carrier

ISP ModelDevice Product & Vendor ID

Provisioning Parametersa

ATT USBConnect 881 (Sierra 881U)

0x1199 6856 usb_type=sierra-gsm (4)

Mercury (Sierra Compass 885)

0x1199 6880 usb_type=sierra-gsm (4) usb_tty=ttyUSB4

Huawei E272, E170, E220

0x12d1 1003 usb_type=option (2)usb_init=AT+CGDCONT=1,'IP','wap.cingular' usb_dial=ATDT*99***1#

Sprint Compass 597 (Sierra)

0x1199 0023 usb_type=sierra-evdo (5)

USB 598 (Sierra) 0x1199 0025 usb_type=sierra-evdo (5)

Ovation U727 (Novatel)

0x1410 4100 usb_type=option (2)

Verizon USB U727 (Novatel) 0x1410 4100 usb_type=option (2)

USB U720 (Novatel/Qualcomm)

0x1410 2110 usb_type=option (2)

UM175 (Pantech) 0x106c 3714 usb_type=acm (3)

UM150 (Pantech) 0x106c 3711 usb_type=acm (3)

U597 (Sierra) 0x1199 0023 usb_type=sierra-evdo (5)

Telecom (New Zealand)

Tstick C597 (Sierra) 0x1199 0023 usb_type=sierra-evdo (5) usb_user=mobile@jamamobile usb_passwd=telecom

TataIndicom (India) SXC-1080 (Qualcomm)

0x1b7d 070a usb_type=acm (3) usb_init=ATQ0V1E1S0=0&C1&D2 usb_user=internet usb_passwd=internet

Telenor (Sweden) Globetrotter ICON 225

0x0af0 6971 usb_type=hso (6) usb_init=AT+CGDCONT=1,'IP','telenor' usb_dial=ATDT*99***1# usb_user=internet usb_passwd=internet

Aruba Networks, Inc. Provisioning Parameters for Verified USB Modems | 237


Vodafone/SmarTone (HK)

Huawei E272 0x12d1 1003 usb_type=option (2) usb_init=AT+CGDCONT=1,'IP','internet'usb_dial=ATDT*99***1#

NZ and JP Huawei E220 0x12d1 1003 usb_type=option (2) usb_init=AT+CGDCONT=1,'IP','internet' usb_dial=ATDT*99***1#

T-Mobile UMG181 0x12d1 1414 usb_type=option (2) usb_dev=0x12d11414 usb_init=AT+CGDCONT=1,'IP','epc.tmobile.com' usb_dial=ATDT*99***1#

a. Console equivalents in brackets. Use the numbers if you are directly provisioning from console.

Table 17 3G Modem Configuration Settings by Carrier (Continued)

ISP ModelDevice Product & Vendor ID

Provisioning Parametersa

Aruba Networks, Inc. Provisioning Parameters for Verified USB Modems | 238


Appendix C: Requirements Worksheets

Table 18 Facility Inventory Worksheet Example

Facility Type

Usage Requirements WLAN Link Requirements Provisioning

Site Count

Max Devices Per Site

Guests FamilyExisting

or New Link

Type Speed LatencyProvisioning

Method

Fixed Telecommuters




Aruba Networks, Inc. Requirements Worksheets | 239


Table 19 Site Template—Medium Branch Office Example


DescriptionMax

Devices (Today)


Wired

Wireless

Interface Auth Mode

Forwarding Mode

Operating Mode

DHCPSource

2.4 GHz 5 GHz

Enterprise Devices

Guest Devices

Total Devices



Table 20 Site Template—Fixed Telecommuter Example


DescriptionMax

Devices (Today)


Wired

Wireless

Interface Auth Mode

Forwarding Mode

Operating Mode

DHCPSource

2.4 GHz 5 GHz

Enterprise Devices

Family Devices

Total Devices



Table 21 Remote Access Point (RAP) Requirement Worksheet Example

Facility TypeLocal Wired Ports

USB Required

Wireless Required

RadioRegulatory Domain

AP Model(with

Power Supply)

WIPS Required



Fixed Telecommuter




Appendix D: Sample Configuration Files for Fixed Telecommuter Example

This appendix presents complete, annotated configuration files for the master and local controllers that result from following the procedure set forth in Chapter 9: Example Configuration for the Fixed Telecommuter Scenario on page 113. The master and local configurations are presented side by side for clarity.

Design SummaryThe following assumptions are made for the fixed telecommuter simplified example configuration:

Master/local controller design. Each RAP connects directly to the Internet via a customer-premises equipment (CPE) device

such as a DSL or cable modem. A RAP with at least four wired ports is used. Each wired port on the RAP is statically assigned to

a specific function: Port 1: Wired enterprise access (802.1X authentication via split-tunnel forwarding mode) Port 2: Wired voice handset (MAC authentication via tunnel forwarding mode) Port 3: Family general access (open authentication via bridge forwarding mode) Port 4: Family general access (open authentication via bridge forwarding mode)

Three separate wireless SSIDs for Enterprise, Voice, and Family will be broadcast for over-the-air access.

Enterprise users can reach the shared printer on the family VLAN via a one-way ACL.


Redundant master controllers (active/standby configuration) Redundant local controllers (active/active configuration) Dual AP groups to load-balance RAPs across redundant local controllers Separate wired and wireless 802.1X Authentication Profiles for flexibility

In addition, the fixed telecommuter scenario has no Provisioning profile. Provisioning profiles assume identical configurations in all premises equipment. This scenario is less likely for telecommuters who use zero touch provisioning.

Aruba Networks, Inc. Sample Configuration Files for Fixed Telecommuter Example | 243


Annotation ConventionsThe configuration files shown on the following pages in this appendix include annotations that use the following conventions:

N O T E

Configuration statements on the local controller may not appear in the same order as the configuration statements on the master controller.

The blue bubbles represent commands that are configured by hand in the procedures presented in Chapter 9: Example Configuration for the Fixed Telecommuter Scenario.

The orange bubbles represent commands that are pushed from the master controller to the local controller following the completion of the base configuration on the local controller.


Aruba N

etworks, Inc.

Sam

ple Configuration Files for Fixed Telecom

muter E

xample

|245

Virtual B

ranch Netw

orksV


esign

e725f0dc909af01de4cea59619d"

ay march 02:00 first sunday

a36ce56c51

e

Step 1F: Configure Connectivity to Local Controllers on page 122 in Complete the Base Configuration of the Local Controller (Chapter 9)

Step 1C: Specify Basic Controller Information on page 143 in Complete the Base Configuration of the Local Controller (Chapter 9)

netservice svc-http tcp 80netservice svc-http-proxy2 tcp 8080netservice svc-sip-udp udp 5060netservice svc-nterm tcp 1026 1028netservice svc-noe-oxo udp 5000 alg noenetservice svc-papi udp 8211netservice svc-natt udp 4500netservice svc-ftp tcp 21netservice svc-svp 119netservice svc-smtp tcp 25netservice svc-gre 47netservice svc-sips tcp 5061netservice svc-smb-udp udp 445netservice svc-esp 50netservice svc-v6-dhcp udp 546 547netservice svc-snmp udp 161netservice svc-bootp udp 67 69netservice svc-msrpc-udp udp 135 139netservice svc-ntp udp 123netservice svc-icmp 1

netservice svc-h323-tcp tcp 1720netservice svc-h323-udp udp 1718 1719netservice svc-nterm tcp 1026 1028netservice svc-sip-udp udp 5060netservice svc-http-proxy2 tcp 8080netservice svc-papi udp 8211netservice svc-noe-oxo udp 5000 alg nonetservice svc-ftp tcp 21netservice svc-natt udp 4500netservice svc-svp 119netservice svc-gre 47netservice svc-smtp tcp 25netservice svc-smb-udp udp 445netservice svc-sips tcp 5061netservice svc-esp 50netservice svc-bootp udp 67 69netservice svc-snmp udp 161netservice svc-v6-dhcp udp 546 547netservice svc-icmp 1

Active-Master Configurationversion 3.3enable secret "a2f880da01f5b8f25832437b2a6e58b327f085c49b8c456231"hostname "RN_Master"clock summer-time PDT recurring 2 sunday march 02:00 first sunday november 02:00 -7

clock timezone PST -8location "Building1.floor1" mms config 0controller config 159

ip access-list eth validuserethacl permit any !netservice svc-snmp-trap udp 162netservice svc-syslog udp 514netservice svc-l2tp udp 1701netservice svc-ike udp 500netservice svc-https tcp 443netservice svc-smb-tcp tcp 445netservice svc-dhcp udp 67 68netservice svc-pptp tcp 1723netservice svc-sccp tcp 2000netservice svc-telnet tcp 23netservice svc-sip-tcp tcp 5060netservice svc-tftp udp 69netservice svc-kerberos udp 88netservice svc-http-proxy3 tcp 8888netservice svc-noe udp 32512netservice svc-cfgm-tcp tcp 8211netservice svc-adp udp 8200netservice svc-pop3 tcp 110netservice svc-rtsp tcp 554netservice svc-msrpc-tcp tcp 135 139netservice svc-dns udp 53netservice svc-h323-udp udp 1718 1719netservice svc-h323-tcp tcp 1720netservice svc-vocera udp 5002

Active-Local Configurationversion 3.3enable secret "ab179448018755fe8d4c65chostname "RN_Local_1"clock summer-time PDT recurring 2 sundnovember 02:00 -7

clock timezone PST -8masterip 172.21.98.251 ipsec 2bf269fb88b3cfc7bfcbe0917a73e8220c12felocation "Building1.floor1" mms config 0controller config 159

ip access-list eth validuserethacl permit any !netservice svc-snmp-trap udp 162netservice svc-dhcp udp 67 68netservice svc-smb-tcp tcp 445netservice svc-https tcp 443netservice svc-ike udp 500netservice svc-l2tp udp 1701netservice svc-syslog udp 514netservice svc-pptp tcp 1723netservice svc-telnet tcp 23netservice svc-sccp tcp 2000netservice svc-tftp udp 69netservice svc-sip-tcp tcp 5060netservice svc-kerberos udp 88netservice svc-pop3 tcp 110netservice svc-adp udp 8200netservice svc-cfgm-tcp tcp 8211netservice svc-noe udp 32512netservice svc-http-proxy3 tcp 8888netservice svc-dns udp 53netservice svc-msrpc-tcp tcp 135 139netservice svc-rtsp tcp 554netservice svc-http tcp 80netservice svc-vocera udp 5002

Step 1C: Specify Basic Controller Information on page 119 in Complete the Base Configuration of the Master Controller (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|246

Virtual B

ranch Netw

orksV


esign

24

e_acl

it mit svc-sip-udp permit queue high svc-sip-tcp permit queue high

nat 8081

8 8 8

Pushed from master

Pushed from master

any any svc-dns permit any any svc-icmp permit any any svc-ntp permit any any svc-tftp permit alias ent_network user svc-http permit alias ent_network user svc-https permit alias voice_network alias sip_server svc-sip-udp permit queue high alias voice_network alias sip_server svc-sip-tcp permit queue high !ip access-list session captiveportal user alias controller svc-https dst-nat 8081 user any svc-http dst-nat 8080 user any svc-https dst-nat 8081 user any svc-http-proxy1 dst-nat 8088 user any svc-http-proxy2 dst-nat 8088 user any svc-http-proxy3 dst-nat 8088 !ip access-list session allowall any any any permit !

any any svc-dns permit any any svc-icmp permit any any svc-ntp permit any any svc-tftp permit alias ent_network user svc-http perm alias ent_network user svc-https per alias voice_network alias sip_server alias voice_network alias sip_server!ip access-list session captiveportal user alias controller svc-https dst- user any svc-http dst-nat 8080 user any svc-https dst-nat 8081 user any svc-http-proxy1 dst-nat 808 user any svc-http-proxy2 dst-nat 808 user any svc-http-proxy3 dst-nat 808!ip access-list session allowall any any any permit !

Step 3F: Configure the Enterprise Voice Firewall Policy on page 132(Chapter 9)

netservice svc-ssh tcp 22netservice svc-v6-icmp 58netservice svc-http-proxy1 tcp 3128

netdestination family_network network 192.168.177.0 255.255.255.0!netdestination ent_network network 10.0.0.0 255.0.0.0!netdestination voice_network network 10.168.115.160 255.255.255.224!netdestination sip_server host 10.168.115.162!ip access-list session control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-papi permit any any svc-cfgm-tcp permit any any svc-adp permit any any svc-tftp permit any any svc-dhcp permit any any svc-natt permit !ip access-list session validuser any any any permit !ip access-list session vocera-acl any any svc-vocera permit queue high !ip access-list session icmp-acl any any svc-icmp permit !ip access-list session Enterprise_voice_acl user any udp 68 deny

netservice svc-ntp udp 123netservice svc-msrpc-udp udp 135 139netservice svc-ssh tcp 22netservice svc-http-proxy1 tcp 3128netservice svc-v6-icmp 58

netdestination family_network network 192.168.177.0 255.255.255.0!netdestination ent_network network 10.0.0.0 255.0.0.0!netdestination voice_network network 10.168.115.160 255.255.255.2!netdestination sip_server host 10.168.115.162!ip access-list session control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-papi permit any any svc-cfgm-tcp permit any any svc-adp permit any any svc-tftp permit any any svc-dhcp permit any any svc-natt permit !ip access-list session validuser any any any permit !ip access-list session vocera-acl any any svc-vocera permit queue high!ip access-list session icmp-acl any any svc-icmp permit !ip access-list session Enterprise_voic user any udp 68 deny

Step 3A: Configure Network Destination Aliases on page 130 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|247

Virtual B

ranch Netw

orksV


esign

se_acl

permit k any permit

h h

t-nat 8081

Pushed from master

any any svc-pptp permit any any svc-gre permit !ip access-list session logon-control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-dhcp permit any any svc-natt permit !ip access-list session cplogout user alias controller svc-https dst-nat 8081 !ip access-list session http-acl any any svc-http permit !ip access-list session dhcp-acl any any svc-dhcp permit !

!ip access-list session srcnat user any any src-nat !ip access-list session skinny-acl any any svc-sccp permit queue high !ip access-list session tftp-acl any any svc-tftp permit !ip access-list session cplogout user alias controller svc-https ds!ip access-list session dhcp-acl any any svc-dhcp permit !ip access-list session http-acl any any svc-http permit !

ip access-list session RemoteAP_acl any any svc-papi permit any any svc-tftp permit any any svc-ftp permit any any svc-ntp permit any any svc-syslog permit any any svc-gre permit any any svc-icmp permit !ip access-list session Remote_Enterprise_acl any any svc-dhcp permit user alias ent_network any permit alias ent_network user any permit user network 224.0.0.0 255.0.0.0 any permit alias ent_network alias ent_network any permit user any any route src-nat !ip access-list session https-acl any any svc-https permit !ip access-list session sip-acl any any svc-sip-udp permit queue high any any svc-sip-tcp permit queue high !ip access-list session dns-acl any any svc-dns permit !ip access-list session tftp-acl any any svc-tftp permit !ip access-list session skinny-acl any any svc-sccp permit queue high !ip access-list session srcnat user any any src-nat !ip access-list session vpnlogon user any svc-ike permit user any svc-esp permit any any svc-l2tp permit

ip access-list session RemoteAP_acl any any svc-papi permit any any svc-tftp permit any any svc-ftp permit any any svc-ntp permit any any svc-syslog permit any any svc-gre permit any any svc-icmp permit !ip access-list session Remote_Enterpri any any svc-dhcp permit user alias ent_network any permit alias ent_network user any permit user network 224.0.0.0 255.0.0.0 any alias ent_network alias ent_networ user any any route src-nat !ip access-list session sip-acl any any svc-sip-udp permit queue hig any any svc-sip-tcp permit queue hig!ip access-list session https-acl any any svc-https permit !ip access-list session dns-acl any any svc-dns permit !ip access-list session logon-control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-dhcp permit any any svc-natt permit !ip access-list session vpnlogon user any svc-ike permit user any svc-esp permit any any svc-l2tp permit any any svc-pptp permit any any svc-gre permit

Step 3B: Configure RAP Firewall Policy on page 130 (Chapter 9)

Step 3D: Configure Remote Enterprise Firewall Policy on page 131 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|248

Virtual B

ranch Netw

orksV


esign

it

gh gh

7.1 any route src-nat network any permit .0 255.0.0.0 any permit work any permit

rol

6115b6097c

Pushed from master

Pushed from master

any any svc-dns permit !ipv6 access-list session v6-allowall any any any permit !ipv6 access-list session v6-http-acl any any svc-http permit !ipv6 access-list session v6-logon-control user any udp 68 deny any any svc-v6-icmp permit any any svc-v6-dhcp permit any any svc-dns permit !vpn-dialer default-dialer ike authentication PRE-SHARE 6f8a10617dc623d97f0e87c9b357d15a9b15ac56e23f49fe!

any any svc-dns permit !ipv6 access-list session v6-allowall any any any permit !ipv6 access-list session v6-http-acl any any svc-http permit !ipv6 access-list session v6-logon-cont user any udp 68 deny any any svc-v6-icmp permit any any svc-v6-dhcp permit any any svc-dns permit !vpn-dialer default-dialer ike authentication PRE-SHARE 81f23b325c68183224ee6c69dcfdfa3bdd120d!

ip access-list session denyall_acl any any any deny !ip access-list session noe-acl any any svc-noe permit queue high !ip access-list session svp-acl any any svc-svp permit queue high user host 224.0.1.116 any permit !ip access-list session ap-acl any any svc-gre permit any any svc-syslog permit any user svc-snmp permit user any svc-snmp-trap permit user any svc-ntp permit user alias controller svc-ftp permit !ip access-list session h323-acl any any svc-h323-tcp permit queue high any any svc-h323-udp permit queue high!ip access-list session Family_acl any any svc-dhcp permit alias family_network host 192.168.177.1 any route src-nat alias family_network alias family_network any permit alias family_network network 224.0.0.0 255.0.0.0 any permit alias ent_network alias family_network any permit user any any route src-nat !ipv6 access-list session v6-icmp-acl any any svc-v6-icmp permit !ipv6 access-list session v6-https-acl any any svc-https permit !ipv6 access-list session v6-dhcp-acl any any svc-v6-dhcp permit !ipv6 access-list session v6-dns-acl

ip access-list session denyall_acl any any any deny !ip access-list session noe-acl any any svc-noe permit queue high !ip access-list session svp-acl any any svc-svp permit queue high user host 224.0.1.116 any permit !ip access-list session ap-acl any any svc-gre permit any any svc-syslog permit any user svc-snmp permit user any svc-snmp-trap permit user any svc-ntp permit user alias controller svc-ftp perm!ip access-list session h323-acl any any svc-h323-tcp permit queue hi any any svc-h323-udp permit queue hi!ip access-list session Family_acl any any svc-dhcp permit alias family_network host 192.168.17 alias family_network alias family_ alias family_network network 224.0.0 alias ent_network alias family_net user any any route src-nat !ipv6 access-list session v6-icmp-acl any any svc-v6-icmp permit !ipv6 access-list session v6-https-acl any any svc-https permit !ipv6 access-list session v6-dhcp-acl any any svc-v6-dhcp permit !ipv6 access-list session v6-dns-acl

Step 3J: Configure the Block All Firewall Policy on page 133(Chapter 9)

Step 3H: Configure the Family Firewall Policy on page 132 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|249

Virtual B

ranch Netw

orksV


esign

Pushed from master

Pushed from master

Pushed from master

Pushed from master

ipv6 session-acl v6-http-acl ipv6 session-acl v6-https-acl ipv6 session-acl v6-dhcp-acl ipv6 session-acl v6-icmp-acl ipv6 session-acl v6-dns-acl!user-role denyall_user_role session-acl denyall_acl!user-role stateful-dot1x!user-role authenticated session-acl allowall ipv6 session-acl v6-allowall!user-role logon session-acl logon-control session-acl captiveportal session-acl vpnlogon ipv6 session-acl v6-logon-control

ipv6 session-acl v6-http-acl ipv6 session-acl v6-https-acl ipv6 session-acl v6-dhcp-acl ipv6 session-acl v6-icmp-acl ipv6 session-acl v6-dns-acl!user-role denyall_user_role session-acl denyall_acl!user-role stateful-dot1x!user-role authenticated session-acl allowall ipv6 session-acl v6-allowall!user-role logon session-acl logon-control session-acl captiveportal session-acl vpnlogon ipv6 session-acl v6-logon-control

Step 3K: Configure the Block All User Role on page 133 (Chapter 9)

user-role ap-role session-acl control session-acl ap-acl!user-role RemoteAP_user_role session-acl RemoteAP_acl!user-role Remote_Enterprise_user_role session-acl Remote_Enterprise_acl!user-role default-vpn-role session-acl allowall ipv6 session-acl v6-allowall!user-role Family_user_role session-acl Family_acl!user-role voice session-acl sip-acl session-acl noe-acl session-acl svp-acl session-acl vocera-acl session-acl skinny-acl session-acl h323-acl session-acl dhcp-acl session-acl tftp-acl session-acl dns-acl session-acl icmp-acl!user-role guest-logon captive-portal default session-acl logon-control session-acl captiveportal!user-role guest session-acl http-acl session-acl https-acl session-acl dhcp-acl session-acl icmp-acl session-acl dns-acl

user-role ap-role session-acl control session-acl ap-acl!user-role RemoteAP_user_role session-acl RemoteAP_acl!user-role Remote_Enterprise_user_role session-acl Remote_Enterprise_acl!user-role default-vpn-role session-acl allowall ipv6 session-acl v6-allowall!user-role Family_user_role session-acl Family_acl!user-role voice session-acl sip-acl session-acl noe-acl session-acl svp-acl session-acl vocera-acl session-acl skinny-acl session-acl h323-acl session-acl dhcp-acl session-acl tftp-acl session-acl dns-acl session-acl icmp-acl!user-role guest-logon captive-portal default session-acl logon-control session-acl captiveportal!user-role guest session-acl http-acl session-acl https-acl session-acl dhcp-acl session-acl icmp-acl session-acl dns-acl

Step 3E: Configure the Remote Enterprise User Role on page 131 (Chapter 9)

Step 3I: Configure the Family User Role on page 133 (Chapter 9)

Step 3C: Configure the RAP User Role on page 131 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|250

Virtual B

ranch Netw

orksV


esign

5.0

55.224

55.224

224

.21.99.1

Pushed from master

Step 1E: Configure the VLAN and IP Interfaces on page 144 in Complete the Base Configuration of the Local Controller (Chapter 9)

Step 1F: Configure Connectivity to the Master Controller on page 146 in Complete the Base Configuration of the Local Controller (Chapter 9)

Task 2: Add Any Necessary Static Routes on page 153 in Complete the Base Configuration of the Local Controller (Chapter 9)

wms general poll-interval 60000 general poll-retries 3 general ap-ageout-interval 30 general sta-ageout-interval 30 general learn-ap disable general persistent-known-interfering enable general propagate-wired-macs enable general stat-update enable general collect-stats disable!crypto isakmp policy 20 encryption aes256!no crypto isakmp psk-cachingno crypto-local isakmp permit-invalid-certcrypto ipsec transform-set default-aes esp-aes256 esp-sha-hmaccrypto dynamic-map default-dynamicmap 10000 set transform-set default-transform default-aes

interface vlan 128ip address 10.168.115.129 255.255.2description "EnterpriseNet"

!interface vlan 160

ip address 10.168.115.161 255.255.2description "VoiceNet"

!interface vlan 214

ip address 99.99.99.14 255.255.255.description "PublicNet"

!ip default-gateway 99.99.99.1

ip route 172.21.98.0 255.255.255.0 172

wms general poll-interval 60000 general poll-retries 3 general ap-ageout-interval 30

Local Controllers on page 122in Complete the Base Configuration of the Master Controller (Chapter 9)

!user-role Enterprise_voice_user_role session-acl Enterprise_voice_acl!aaa pubcookie-authentication!no spanning-treeinterface mgmt

shutdown!vlan 98

interface gigabitethernet 1/0description "GE1/0"trusted

!interface gigabitethernet 1/1

description "GE1/1"trusted




description "GE1/2"trustedswitchport mode trunkswitchport trunk allowed vlan 98

!interface vlan 1!interface vlan 98

ip address 172.21.98.251 255.255.255.0description "ControllerNet"

!ip default-gateway 172.21.98.1

!user-role Enterprise_voice_user_role session-acl Enterprise_voice_acl!aaa pubcookie-authentication!no spanning-treeinterface mgmt

shutdown!vlan 99vlan 128vlan 160vlan 214

interface gigabitethernet 1/0description "GE1/0"trusted


description "GE1/1"trustedswitchport access vlan 214


description "GE1/2"trustedswitchport mode trunkswitchport trunk allowed vlan 99



!interface vlan 1!interface vlan 99

ip address 172.21.99.250 255.255.25description "ControllerNet"

!

Step 1E: Configure the VLAN and IP Interfaces on page 120in Complete the Base Configuration of the Master Controller (Chapter 9)

Step 1F: Configure Connectivity to

Step 3G: Configure the Enterprise Voice User Role on page 132(Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|251

Virtual B

ranch Netw

orksV


esign

enable

cert esp-aes256 esp-sha-hmac10000default-aes

2 retry-timeout 2 retry-attempts 3

225 10.168.115.239

fb615260fb209b44b097557051f947d23

p disable sysmsg disable other

c"

prise_dot1x"

Pushed from master

Step 1H: Configure the IP Address Pools on page 148 in Complete the Base Configuration of the Local Controller (Chapter 9)

packet-capture-defaults tcp disable udp disable sysmsg disable other disable!ip domain lookup!

country USaaa authentication mac "default"!aaa authentication mac "Wired_Voice_mac"!aaa authentication dot1x "default"!aaa authentication dot1x "Remote_Enterprise_dot1x"!

database synchronize rf-plan-data

ip mobile domain default!ip igmp!packet-capture-defaults tcp disable uddisable!ip domain lookup!country USaaa authentication mac "default"!aaa authentication mac "Wired_Voice_ma!aaa authentication dot1x "default"!aaa authentication dot1x "Remote_Enter!

Step 4B: Create the Shared 802.1X Authentication Profile on page 134 (Chapter 9)

Step 4C: Create the Wired Voice MAC Authentication Profile on page 134 (Chapter 9)

!

localip 0.0.0.0 ipsec 5c7e58d5d3946dfe00e88daf8c98cf2225dd5fdb8c41b8a2crypto isakmp groupname changemecrypto-local isakmp dpd idle-timeout 22 retry-timeout 2 retry-attempts 3crypto-local isakmp xauthcrypto-local isakmp sa-cleanupcrypto-local ipsec sa-cleanup

vpdn group l2tp ppp authentication PAP!

vpdn group pptp ppp authentication MSCHAPv2!

mux-address 0.0.0.0

adp discovery enableadp igmp-join enableadp igmp-vlan 0

ssh mgmt-auth username/password mgmt-user admin root e2e4e10901f4041bd8e2b8875f192b4943352b29ee45088088

no database synchronizedatabase synchronize rf-plan-data

ip mobile domain default!

ip igmp!

general sta-ageout-interval 30 general learn-ap disable general persistent-known-interfering general propagate-wired-macs enable general stat-update enable general collect-stats disable!crypto isakmp policy 20 encryption aes256!no crypto isakmp psk-cachingno crypto-local isakmp permit-invalid-crypto ipsec transform-set default-aescrypto dynamic-map default-dynamicmap set transform-set default-transform !crypto isakmp groupname changemecrypto-local isakmp dpd idle-timeout 2crypto-local isakmp xauthcrypto-local isakmp sa-cleanupcrypto-local ipsec sa-cleanup

ip local pool "RAP_Pool_1" 10.168.115.vpdn group l2tp ppp authentication PAP!vpdn group pptp ppp authentication MSCHAPv2!

mux-address 0.0.0.0

adp discovery enableadp igmp-join enableadp igmp-vlan 0

ssh mgmt-auth username/password mgmt-user admin root 3c309af301820a67b

no database synchronize

Aruba N

etworks, Inc.

Sam


muter E

xample

|252

Virtual B

ranch Netw

orksV


esign

x_server1"

721e5d2631163f

rise_dot1x"se_user_role"

rise_dot1x"e_user_role"

"user_role"

rise_dot1x"e_user_role"

ault"

e"

.1

Pushed from master

Pushed from master

Pushed from master

Pushed from master

aaa authentication mgmt!aaa authentication stateful-dot1x!aaa authentication wired profile "Remote_Ent_aaa_profile"!web-server!ap system-profile "APGroup1_sys_profile" lms-ip 99.99.99.1 rap-dhcp-server-vlan 177 rap-dhcp-server-id 192.168.177.1 rap-dhcp-default-router 192.168.177.1 rap-dhcp-pool-start 192.168.177.100 rap-dhcp-pool-end 192.168.177.254 dns-domain "arubanetworks.com" dns-domain "airwave.com"!

aaa authentication mgmt!aaa authentication stateful-dot1x!aaa authentication wired profile "Remote_Ent_aaa_profile"!web-server!ap system-profile "APGroup1_sys_profil lms-ip 99.99.99.1 rap-dhcp-server-vlan 177 rap-dhcp-server-id 192.168.177.1 rap-dhcp-default-router 192.168.177 rap-dhcp-pool-start 192.168.177.100 rap-dhcp-pool-end 192.168.177.254 dns-domain "arubanetworks.com" dns-domain "airwave.com"!

Step 4E: Create the Global Wired Authentication Profile on page 135 (Chapter 9)

Step 7A: Create the AP System Profile on page 140 (Chapter 9)

Step 7B: DNS Proxy for Split-Tunnel SSID (Optional) on page 140 (Chapter 9)

aaa authentication-server radius "dot1x_server1" host 10.168.115.130 key 85b72ce618636a7e81f28e516f89be2c116bbae0e1631ea6!aaa server-group "default" auth-server Internal set role condition role value-of!aaa server-group "RADIUS_Servers" auth-server dot1x_server1!aaa profile "default"!aaa profile "Family_aaa_profile" initial-role "Family_user_role" authentication-dot1x "default-psk"!aaa profile "Remote_Ent_aaa_profile" initial-role "denyall_user_role" authentication-dot1x "Remote_Enterprise_dot1x" dot1x-default-role "Remote_Enterprise_user_role" dot1x-server-group "RADIUS_Servers"!aaa profile "Voice_aaa_profile" authentication-dot1x "Remote_Enterprise_dot1x" dot1x-default-role "Enterprise_voice_user_role" dot1x-server-group "RADIUS_Servers"!aaa profile "Wired_Voice_aaa_profile" authentication-mac "Wired_Voice_mac" mac-default-role "Enterprise_voice_user_role" mac-server-group "internal" authentication-dot1x "Remote_Enterprise_dot1x" dot1x-default-role "Enterprise_voice_user_role" dot1x-server-group "RADIUS_Servers"!aaa authentication captive-portal "default"!aaa authentication vpn!

aaa authentication-server radius "dot1 host 10.168.115.130 key daa65ef2d5ec725ee054ecc09fc6a0d58b!aaa server-group "default" auth-server Internal set role condition role value-of!aaa server-group "RADIUS_Servers" auth-server dot1x_server1!aaa profile "default"!aaa profile "Family_aaa_profile" initial-role "Family_user_role" authentication-dot1x "default-psk"!aaa profile "Remote_Ent_aaa_profile" initial-role "denyall_user_role" authentication-dot1x "Remote_Enterp dot1x-default-role "Remote_Enterpri dot1x-server-group "RADIUS_Servers"!aaa profile "Voice_aaa_profile" authentication-dot1x "Remote_Enterp dot1x-default-role "Enterprise_voic dot1x-server-group "RADIUS_Servers"!aaa profile "Wired_Voice_aaa_profile" authentication-mac "Wired_Voice_mac mac-default-role "Enterprise_voice_ mac-server-group "internal" authentication-dot1x "Remote_Enterp dot1x-default-role "Enterprise_voic dot1x-server-group "RADIUS_Servers"!aaa authentication captive-portal "def!aaa authentication vpn!

Step 4A: Create a Server for 802.1X Authentication on page 133 (Chapter 9)

Step 4D: Create the Enterprise AAA Profile on page 134 (Chapter 9)

Step 4F: Create the Wired and Wireless Voice AAA Profiles on page 135 (Chapter 9)

Step 4G: Create the Family AAA Profile on page 136 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|253

Virtual B

ranch Netw

orksV


esign

ile"

rofile"

ofile"

profile"ile""

rt_profile"rofile"

t_profile"ofile"e"

Pushed from master

Pushed from master

!ap wired-ap-profile "Wired_Voice_ap_profile" wired-ap-enable switchport access vlan 160!ap enet-link-profile "default"!ap wired-port-profile "default"!ap wired-port-profile "Wired_Ent_port_profile" wired-ap-profile "Wired_Ent_ap_profile" aaa-profile "Remote_Ent_aaa_profile"!ap wired-port-profile "Wired_Family_port_profile" wired-ap-profile "Wired_Family_ap_profile" aaa-profile "Family_aaa_profile"!ap wired-port-profile "Wired_Voice_port_profile" wired-ap-profile "Wired_Voice_ap_profile" aaa-profile "Wired_Voice_aaa_profile"

!ap wired-ap-profile "Wired_Voice_ap_pr wired-ap-enable switchport access vlan 160!ap enet-link-profile "default"!ap wired-port-profile "default"!ap wired-port-profile "Wired_Ent_port_ wired-ap-profile "Wired_Ent_ap_prof aaa-profile "Remote_Ent_aaa_profile!ap wired-port-profile "Wired_Family_po wired-ap-profile "Wired_Family_ap_p aaa-profile "Family_aaa_profile"!ap wired-port-profile "Wired_Voice_por wired-ap-profile "Wired_Voice_ap_pr aaa-profile "Wired_Voice_aaa_profil

Step 6B: Create the Voice Wired AP and Port Profiles (Port 2) on page 139 (Chapter 9)

Voice Wired AP and Port Profiles (Port 2) on page 139 (Chapter 9)

Step 6A: Create the Enterprise Wired AP and Port Profiles (Port 1) on page 138 (Chapter 9)

Step 6C: Create the Family Wired AP and Port Profiles (Ports 3 and 4) on page 139 (Chapter 9)

ap system-profile "default"!ap regulatory-domain-profile "default" country-code US valid-11g-channel 1 valid-11g-channel 6 valid-11g-channel 11 valid-11a-channel 36 valid-11a-channel 40 valid-11a-channel 44 valid-11a-channel 48 valid-11a-channel 149 valid-11a-channel 153 valid-11a-channel 157 valid-11a-channel 161 valid-11a-channel 165 valid-11g-40mhz-channel-pair 1+ valid-11g-40mhz-channel-pair 5- valid-11g-40mhz-channel-pair 7+ valid-11g-40mhz-channel-pair 11- valid-11a-40mhz-channel-pair 36+ valid-11a-40mhz-channel-pair 40- valid-11a-40mhz-channel-pair 44+ valid-11a-40mhz-channel-pair 48- valid-11a-40mhz-channel-pair 149+ valid-11a-40mhz-channel-pair 153- valid-11a-40mhz-channel-pair 157+ valid-11a-40mhz-channel-pair 161-!ap wired-ap-profile "default"!ap wired-ap-profile "Wired_Ent_ap_profile" wired-ap-enable forward-mode split-tunnel switchport access vlan 128!ap wired-ap-profile "Wired_Family_ap_profile" wired-ap-enable forward-mode bridge switchport access vlan 177

ap system-profile "default"!ap regulatory-domain-profile "default" country-code US valid-11g-channel 1 valid-11g-channel 6 valid-11g-channel 11 valid-11a-channel 36 valid-11a-channel 40 valid-11a-channel 44 valid-11a-channel 48 valid-11a-channel 149 valid-11a-channel 153 valid-11a-channel 157 valid-11a-channel 161 valid-11a-channel 165 valid-11g-40mhz-channel-pair 1+ valid-11g-40mhz-channel-pair 5- valid-11g-40mhz-channel-pair 7+ valid-11g-40mhz-channel-pair 11- valid-11a-40mhz-channel-pair 36+ valid-11a-40mhz-channel-pair 40- valid-11a-40mhz-channel-pair 44+ valid-11a-40mhz-channel-pair 48- valid-11a-40mhz-channel-pair 149+ valid-11a-40mhz-channel-pair 153- valid-11a-40mhz-channel-pair 157+ valid-11a-40mhz-channel-pair 161-!ap wired-ap-profile "default"!ap wired-ap-profile "Wired_Ent_ap_prof wired-ap-enable forward-mode split-tunnel switchport access vlan 128!ap wired-ap-profile "Wired_Family_ap_p wired-ap-enable forward-mode bridge switchport access vlan 177

Step 6A: Create the Enterprise Wired AP and Port Profiles (Port 1) on page 138 (Chapter 9)

Step 6B: Create the

Step 6C: Create the Family Wired AP and Port Profiles (Ports 3 and 4) on page 139 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|254

Virtual B

ranch Netw

orksV


esign

lt"

t"

file"

"

192edb974c98956025fd72d3dbd9

e"le"

"

Pushed from master

Pushed from master

Pushed from master

wpa-passphrase cc5e10b47af17603090b6e9159ab082a71fb574ffeec28ab!wlan ssid-profile "Voice_ssid_profile" essid "Voice" opmode wpa2-aes!wlan virtual-ap "default"!wlan virtual-ap "Enterprise_vap_profile" ssid-profile "Enterprise_ssid_profile" vlan 128 forward-mode split-tunnel aaa-profile "Remote_Ent_aaa_profile"!wlan virtual-ap "Family_vap_profile" ssid-profile "Family_ssid_profile" vlan 177 forward-mode bridge aaa-profile "Family_aaa_profile" rap-operation always

wpa-passphrase bf747cd922d85ee46499!wlan ssid-profile "Voice_ssid_profile" essid "Voice" opmode wpa2-aes!wlan virtual-ap "default"!wlan virtual-ap "Enterprise_vap_profil ssid-profile "Enterprise_ssid_profi vlan 128 forward-mode split-tunnel aaa-profile "Remote_Ent_aaa_profile!wlan virtual-ap "Family_vap_profile" ssid-profile "Family_ssid_profile" vlan 177 forward-mode bridge aaa-profile "Family_aaa_profile" rap-operation always

Step 5B: Create the Voice SSID and Virtual AP Profiles on page 137 (Chapter 9)

Step 5C: Create the Family SSID and Virtual AP Profiles on page 137 (Chapter 9)

Step 5A: Create the Enterprise SSID and Virtual AP Profiles on page 136 (Chapter 9)

!ap snmp-profile "default"!ids general-profile "default"!ids rate-thresholds-profile "default"!ids signature-profile "default"!ids impersonation-profile "default"!ids unauthorized-device-profile "default"!ids signature-matching-profile "default"!ids dos-profile "default"!ids profile "default"!rf arm-profile "default"!rf optimization-profile "default"!rf event-thresholds-profile "default"!rf dot11a-radio-profile "default"!rf dot11g-radio-profile "default"!wlan ht-ssid-profile "default"!wlan ssid-profile "default"!wlan ssid-profile "Enterprise_ssid_profile" essid "Enterprise" opmode wpa2-aes!wlan ssid-profile "Family_ssid_profile" essid "Family" opmode wpa2-psk-aes

!ap snmp-profile "default"!ids general-profile "default"!ids rate-thresholds-profile "default"!ids signature-profile "default"!ids impersonation-profile "default"!ids unauthorized-device-profile "defau!ids signature-matching-profile "defaul!ids dos-profile "default"!ids profile "default"!rf arm-profile "default"!rf optimization-profile "default"!rf event-thresholds-profile "default"!rf dot11a-radio-profile "default"!rf dot11g-radio-profile "default"!wlan ht-ssid-profile "default"!wlan ssid-profile "default"!wlan ssid-profile "Enterprise_ssid_pro essid "Enterprise" opmode wpa2-aes!wlan ssid-profile "Family_ssid_profile essid "Family" opmode wpa2-psk-aes

Step 5A: Create the Enterprise SSID and Virtual AP Profiles on page 136 (Chapter 9)

Step 5C: Create the Family SSID and Virtual AP Profiles on page 137 (Chapter 9)

Aruba N

etworks, Inc.

Sam


muter E

xample

|255

Virtual B

ranch Netw

orksV


esign

profile"t_profile"rt_profile"rt_profile"file"

Pushed from master

Pushed from master

!wlan virtual-ap "Voice_vap_profile" ssid-profile "Voice_ssid_profile" vlan 160 aaa-profile "Voice_aaa_profile"!ap provisioning-profile "default"!ap-group "default" virtual-ap "default"!ap-group "Fixed_Telecommuter_APGroup1" virtual-ap "Enterprise_vap_profile" virtual-ap "Voice_vap_profile" virtual-ap "Family_vap_profile" enet1-port-profile "Wired_Ent_port_profile" enet2-port-profile "Wired_Voice_port_profile" enet3-port-profile "Wired_Family_port_profile" enet4-port-profile "Wired_Family_port_profile" ap-system-profile "APGroup1_sys_profile"!

end

!wlan virtual-ap "Voice_vap_profile" ssid-profile "Voice_ssid_profile" vlan 160 aaa-profile "Voice_aaa_profile"!ap provisioning-profile "default"!ap-group "default" virtual-ap "default"!ap-group "Fixed_Telecommuter_APGroup1" virtual-ap "Enterprise_vap_profile" virtual-ap "Voice_vap_profile" virtual-ap "Family_vap_profile" enet1-port-profile "Wired_Ent_port_ enet2-port-profile "Wired_Voice_por enet3-port-profile "Wired_Family_po enet4-port-profile "Wired_Family_po ap-system-profile "APGroup1_sys_pro!

end

Task 8: Configure the AP Group on page 141 (Chapter 9)

Step 5B: Create the Voice SSID and Virtual AP Profiles on page 137 (Chapter 9)


Appendix E: Aruba Contact Information

Contacting Aruba Networks

Web Site Support

Main Site http://www.arubanetworks.com

Support Site https://support.arubanetworks.com

Software Licensing Site https://licensing.arubanetworks.com/login.php

Wireless Security IncidentResponse Team (WSIRT)

http://www.arubanetworks.com/support/wsirt.php

Support Emails

Americas and APAC [email protected]

EMEA [email protected]

WSIRT EmailPlease email details of any securityproblem found in an Aruba product.

[email protected]

Validated Reference Design Contact and User Forum

Validated Reference Designs http://www.arubanetworks.com/vrd

VRD Contact Email [email protected]

AirHeads Online User Forum http://airheads.arubanetworks.com

Telephone Support

Aruba Corporate +1 (408) 227-4500

FAX +1 (408) 227-4550

Support

United States +1-800-WI-FI-LAN (800-943-4526)

Universal Free Phone Service Numbers (UIFN):

Australia Reach: 1300 4 ARUBA (27822)

United States 1 800 94345261 650 3856589

Canada 1 800 94345261 650 3856589

United Kingdom BT: 0 825 494 34526MCL: 0 825 494 34526

Aruba Networks, Inc. Aruba Contact Information | 257

http://www.arubanetworks.com

https://support.arubanetworks.com

https://licensing.arubanetworks.com/login.php

http://www.arubanetworks.com/support/wsirt.php

mailto:[email protected]



http://www.arubanetworks.com/vrd%20



Universal Free Phone Service Numbers (UIFN):

Japan IDC: 10 810 494 34526 * Select fixed phonesIDC: 0061 010 812 494 34526 * Any fixed, mobile & payphoneKDD: 10 813 494 34526 * Select fixed phonesJT: 10 815 494 34526 * Select fixed phonesJT: 0041 010 816 494 34526 * Any fixed, mobile & payphone

Korea DACOM: 2 819 494 34526KT: 1 820 494 34526ONSE: 8 821 494 34526

Singapore Singapore Telecom: 1 822 494 34526

Taiwan (U) CHT-I: 0 824 494 34526

Belgium Belgacom: 0 827 494 34526

Israel Bezeq: 14 807 494 34526Barack ITC: 13 808 494 34526

Ireland EIRCOM: 0 806 494 34526

Hong Kong HKTI: 1 805 494 34526

Germany Deutsche Telkom: 0 804 494 34526

France France Telecom: 0 803 494 34526

China (P) China Telecom South: 0 801 494 34526China Netcom Group: 0 802 494 34526

Saudi Arabia 800 8445708

UAE 800 04416077

Egypt 2510-0200 8885177267 * within Cairo02-2510-0200 8885177267 * outside Cairo

India 91 044 66768150

Telephone Support

Aruba Networks, Inc. Aruba Contact Information | 258

Virtual Branch Networks

Technology

Transcript of Virtual Branch Networks