virtual branch networks
Post on 20-Aug-2015
4.165 Views
Preview:
TRANSCRIPT
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
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Contents | 4
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Contents | 5
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Contents | 6
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. | 8
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Introduction | 10
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Introduction | 11
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Introduction | 12
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 14
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 15
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 16
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 17
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 18
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 19
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 20
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 21
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 22
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Virtual Branch Theory of Operations | 23
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 24
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Virtual Branch Theory of Operations | 25
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Virtual Branch Theory of Operations | 26
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. The Network Technology Lifecycle | 28
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. The Network Technology Lifecycle | 29
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. The Network Technology Lifecycle | 30
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Defining Requirements for Remote Networks | 32
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Defining Requirements for Remote Networks | 33
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Defining Requirements for Remote Networks | 34
Virtual Branch Networks Validated Reference Design
The following is an example of an application worksheet for the fixed telecommuter site.
Table 3 Site Template Example— Fixed Telecommuter
Forecast Connection Method Logical & Security Design
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)
Open Bridge Always RAP
Wireless Devices
2 10 X X Family SSID
Open Bridge Always RAP
Total Devices
7 20
*Over time, wired devices transition to wireless.
Aruba Networks, Inc. Defining Requirements for Remote Networks | 35
Virtual Branch Networks Validated Reference Design
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?
Aruba Networks, Inc. Defining Requirements for Remote Networks | 36
Virtual Branch Networks Validated Reference Design
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
Medium Branch Offices
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
Small Branch Offices
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
Remote Call Center Agents
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
Aruba Networks, Inc. Defining Requirements for Remote Networks | 37
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Defining Requirements for Remote Networks | 38
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 40
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 41
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 42
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 43
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 44
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 45
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 46
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 47
Virtual Branch Networks Validated Reference Design
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)
Aruba Networks, Inc. Physical Design | 48
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 49
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Physical Design | 50
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 51
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Physical Design | 52
Virtual Branch Networks Validated Reference Design
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)
Aruba Networks, Inc. Physical Design | 53
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 54
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Physical Design | 55
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Physical Design | 56
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 57
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Physical Design | 58
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
AirWave ManagementPlatform
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
Aruba Networks, Inc. Logical Design | 60
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Logical Design | 61
Virtual Branch Networks Validated Reference Design
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
AirWave ManagementPlatform
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
Aruba Networks, Inc. Logical Design | 62
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Logical Design | 63
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 64
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 65
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Logical Design | 66
Virtual Branch Networks Validated Reference Design
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
Management Frame Type Open, Static WEP, PSK Processing Location
802.1XProcessing Location
Probea
a. Requires that local probe response be enabled.
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
Aruba Networks, Inc. Logical Design | 67
Virtual Branch Networks Validated Reference Design
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
Management Frame Type Open, Static WEP, PSK Processing Location
802.1XProcessing 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
Aruba Networks, Inc. Logical Design | 68
Virtual Branch Networks Validated Reference Design
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
IPsec/AES-CCM Encrypted Control Channel
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
Aruba Networks, Inc. Logical Design | 69
Virtual Branch Networks Validated Reference Design
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
IPsec/AES-CCM Encrypted Control Channel
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
Aruba Networks, Inc. Logical Design | 70
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 71
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 72
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Logical Design | 73
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 74
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 75
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 76
Virtual Branch Networks Validated Reference Design
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
authentication <password>
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>
!
Aruba Networks, Inc. Logical Design | 77
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 78
Virtual Branch Networks Validated Reference Design
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
authentication <password>
description initial-primary-23
no shutdown
!
vrrp 24
vlan 24
ip address 10.200.24.254
priority 110
preempt
authentication <password>
description initial-standby-24
no shutdown
!
arun
_045
RN
SG
_045
Local
Active VIPActive VIP
Local
Unreachable
Aruba Networks, Inc. Logical Design | 79
Virtual Branch Networks Validated Reference Design
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
authentication <password>
description initial-primary-24
no shutdown
!
vrrp 23
vlan 23
ip address 10.200.23.254
priority 110
preempt
authentication <password>
description initial-standby-23
no shutdown
!
Aruba Networks, Inc. Logical Design | 80
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 81
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Logical Design | 82
Virtual Branch Networks Validated Reference Design
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)
Aruba Networks, Inc. Logical Design | 83
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Logical Design | 84
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Authentication and Security Design | 86
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Authentication and Security Design | 87
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 88
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 89
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Authentication and Security Design | 90
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Authentication and Security Design | 91
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 92
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Authentication and Security Design | 93
Virtual Branch Networks Validated Reference Design
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 = “ias@summit.corp.com”Server Type = RADIUSFail-Through = No
802.1X Server Group
802.1X Authentication Profile
Aruba Networks, Inc. Authentication and Security Design | 94
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 95
Virtual Branch Networks Validated Reference Design
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”
Aruba Networks, Inc. Authentication and Security Design | 96
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 97
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 98
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 99
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 100
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Authentication and Security Design | 101
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Authentication and Security Design | 102
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 104
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 105
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 106
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 107
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Deploying Aruba Remote Networks | 108
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 109
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Deploying Aruba Remote Networks | 110
Virtual Branch Networks Validated Reference Design
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.)
Aruba Networks, Inc. Deploying Aruba Remote Networks | 111
Virtual Branch Networks Validated Reference Design
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).
Aruba Networks, Inc. Deploying Aruba Remote Networks | 112
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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 Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 114
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
Enet3 Port Profile Virtual AP Profile
Enet4 Port Profile
Dependent Profiles - General
AP System Profile
AP Wired Port ProfileWired_Ent_Port_profile
(Task 6A)
Dependent ProfilesAAA Profile
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)
Dependent ProfilesAAA Profile
Wired AP Profile
Dependent ProfilesAAA Profile
Wired AP ProfileDependent Profiles
AAA Profile
SSID Profile
Dependent ProfilesAAA 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
Dependent Profiles802.1X Server Group
802.1X AuthenticationProfile
Dependent Profiles802.1X Server Group
802.1X AuthenticationProfile
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 116
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 117
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 118
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 119
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 120
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 121
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 122
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 123
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 124
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 125
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 126
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 127
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 128
Virtual Branch Networks Validated Reference Design
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
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.
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 129
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 130
Virtual Branch Networks Validated Reference Design
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 131
Virtual Branch Networks Validated Reference Design
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
any any svc-dhcp 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
!
user-role Enterprise_voice_user_role
session-acl Enterprise_voice_acl
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 132
Virtual Branch Networks Validated Reference Design
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
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
!
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 133
Virtual Branch Networks Validated Reference Design
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 134
Virtual Branch Networks Validated Reference Design
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
authentication-dot1x Remote_Enterprise_dot1x
dot1x-default-role Enterprise_voice_user_role
dot1x-server-group RADIUS_Servers
initial-role logon
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 135
Virtual Branch Networks Validated Reference Design
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-dot1x Remote_Enterprise_dot1x
authentication-mac Wired_Voice_mac
dot1x-default-role Enterprise_voice_user_role
dot1x-server-group RADIUS_Servers
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 136
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 137
Virtual Branch Networks Validated Reference Design
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
forward-mode split-tunnel
switchport access vlan 128
!
ap wired-port-profile Wired_Ent_port_profile
aaa-profile Remote_Ent_aaa_profile
wired-ap-profile Wired_Ent_ap_profile
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 138
Virtual Branch Networks Validated Reference Design
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
switchport access vlan 160
!
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
switchport access vlan 177
!
ap wired-port-profile Wired_Family_port_profile
wired-ap-profile Wired_Family_ap_profile
aaa-profile Family_aaa_profile
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 139
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 140
Virtual Branch Networks Validated Reference Design
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.
ap system-profile APGroup1_sys_profile
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 141
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 142
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 143
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 144
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 145
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 146
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 147
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 148
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 149
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 150
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 151
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 152
Virtual Branch Networks Validated Reference Design
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
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 153
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 154
Virtual Branch Networks Validated Reference Design
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>
!
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 155
Virtual Branch Networks Validated Reference Design
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)
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 156
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 157
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 158
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
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 Networks, Inc. Example Configuration for the Branch Office Scenario | 160
Aruba N
etworks, Inc.
Exam
ple Configuration for the B
ranch Office S
cenario|
161
Virtual B
ranch Netw
orksV
alidated Reference D
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)
Dependent ProfilesAAA Profile
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
Enet2 Port Profile Virtual AP Profile
Enet3 Port Profile Virtual AP Profile
Enet4 Port Profile
Dependent Profiles - General
AP System Profile
AP Wired Port ProfileWired_Branch_Port_profile
(Task 6A)
Dependent ProfilesAAA Profile
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)
Dependent ProfilesAAA Profile
Wired AP Profile
Dependent ProfilesAAA Profile
Wired AP Profile
AP Wired Port ProfileWired_Server_Port_profile
(Task 6C)
Dependent ProfilesAAA Profile
Wired AP ProfileDependent Profiles
AAA Profile
SSID Profile
Dependent ProfilesAAA Profile
SSID Profile
Wired AP ProfileWired_Branch_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_Guest_ap_profile
(Task 6D)
wired-ap-enable = yesforward-mode = bridgeswitchport access vlan = 177
Wired AP ProfileWired_Server_ap_profile
(Task 6C)
wired-ap-enable = yesforward-mode = split-tunnelswitchport access vlan = 128
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)
Dependent Profiles802.1X Server Group
dot1x-default-role = Remote_Enterprise_user_roleinitial-role = denyall_user_role
802.1X AuthenticationProfile
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
Dependent Profiles802.1X Server Group
802.1X AuthenticationProfile
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 162
Virtual Branch Networks Validated Reference Design
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
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.
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 163
Virtual Branch Networks Validated Reference Design
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-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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 164
Virtual Branch Networks Validated Reference Design
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
any any svc-dhcp 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
!
user-role Enterprise_voice_user_role
session-acl Enterprise_voice_acl
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 165
Virtual Branch Networks Validated Reference Design
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 any any route src-nat
!
user-role Remote_App_Server_user_role
session-acl Remote_Application_Server_acl
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 166
Virtual Branch Networks Validated Reference Design
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
any any svc-dhcp permit
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 any any route src-nat
!
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 167
Virtual Branch Networks Validated Reference Design
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 168
Virtual Branch Networks Validated Reference Design
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
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 Wired_Server_aaa_profile
initial-role Remote_App_Server_user_role
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 169
Virtual Branch Networks Validated Reference Design
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
authentication-dot1x Remote_Enterprise_dot1x
dot1x-default-role Enterprise_voice_user_role
dot1x-server-group RADIUS_Servers
initial-role logon
!
aaa profile Wired_Voice_aaa_profile
authentication-dot1x Remote_Enterprise_dot1x
authentication-mac Wired_Voice_mac
dot1x-default-role Enterprise_voice_user_role
dot1x-server-group RADIUS_Servers
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 170
Virtual Branch Networks Validated Reference Design
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
aaa-profile Remote_Ent_aaa_profile
ssid-profile Enterprise_ssid_profile
vlan 128
forward-mode split-tunnel
!
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.
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 171
Virtual Branch Networks Validated Reference Design
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
forward-mode split-tunnel
switchport access vlan 128
!
ap wired-port-profile Wired_Branch_port_profile
aaa-profile Remote_Ent_aaa_profile
wired-ap-profile Wired_Branch_ap_profile
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 172
Virtual Branch Networks Validated Reference Design
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
switchport access vlan 160
!
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
forward-mode split-tunnel
switchport access vlan 128
!
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
switchport access vlan 177
!
ap wired-port-profile Wired_Guest_port_profile
wired-ap-profile Wired_Guest_ap_profile
aaa-profile Guest_aaa_profile
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 173
Virtual Branch Networks Validated Reference Design
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.
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.
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 174
Virtual Branch Networks Validated Reference Design
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.
ap system-profile APGroup1_sys_profile
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 175
Virtual Branch Networks Validated Reference Design
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
!
Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 176
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 178
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Reporting and Management | 179
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 180
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 181
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Reporting and Management | 182
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 183
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Reporting and Management | 184
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 185
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Reporting and Management | 186
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 188
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Troubleshooting Remote Access Points | 189
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 190
Virtual Branch Networks Validated Reference Design
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”
Aruba Networks, Inc. Troubleshooting Remote Access Points | 191
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 192
Virtual Branch Networks Validated Reference Design
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?
Aruba Networks, Inc. Troubleshooting Remote Access Points | 193
Virtual Branch Networks Validated Reference Design
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 ....
Aruba Networks, Inc. Troubleshooting Remote Access Points | 194
Virtual Branch Networks Validated Reference Design
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"
The command output should be similar to the following:
(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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 195
Virtual Branch Networks Validated Reference Design
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
The command output should be similar to the following:
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:admin@10.100.135.112 COMMAND:<provision-ap pap-user "RAP01" > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap pap-passwd "GoAruba" > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap ikepsk "secret" > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap master "63.82.214.206" > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap no server-name > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap server-ip 63.82.214.206 > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap ap-group "remote" > -- command executed successfully
Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap ap-name "RAP70" > -- command executed successfully
Aruba Networks, Inc. Troubleshooting Remote Access Points | 196
Virtual Branch Networks Validated Reference Design
The command output should be similar to the following:
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)
hash algorithm: Secure Hash Algorithm
authentication method: Rivest-Shamir-Adelman Signature
Diffie-Hellman Group: #2 (1024 bit)
lifetime: [300 - 86400] seconds, no volume limit
Default RAP PSK protection suite
encryption algorithm: AES - Advanced Encryption Standard (256 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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 197
Virtual Branch Networks Validated Reference Design
The command output should be similar to the following:
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 198
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 199
Virtual Branch Networks Validated Reference Design
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>]
The command output should be similar to the following:
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 200
Virtual Branch Networks Validated Reference Design
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
The command output should be similar to the following:
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 }
will negotiate = { Transport, Tunnel }
Transform set default-aes: { esp-aes256 esp-sha-hmac }
will negotiate = { Transport, Tunnel }
Aruba Networks, Inc. Troubleshooting Remote Access Points | 201
Virtual Branch Networks Validated Reference Design
The command output should be similar to the following:
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 202
Virtual Branch Networks Validated Reference Design
Crypto Debug Output
To display the crypto debug output, use the following command: (vrd-rap-local) #show log security 100 | include ike
The command output should be similar to the following:
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 !!
Jun 30 18:35:51 :103063: <DBUG> |ike| ipc_setup_ipsec_dp_sa add=1, out=0,
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::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
Jun 30 18:35:53 :103063: <DBUG> |ike| ipc_setup_ipsec_dp_sa add=1, out=1,
sa=0x10292c5c, proto=0x10292fc4
Jun 30 18:35:53 :103063: <DBUG> |ike| ipc_setup_ipsec_dp_sa sa src=0x0aa85202,
dst=0x0a64652a
Aruba Networks, Inc. Troubleshooting Remote Access Points | 203
Virtual Branch Networks Validated Reference Design
Crypto Data Path Statistics
To display the crypto data path statistics, use the following command:(vrd-rap-local) #show datapath crypto
The command output should be similar to the following:
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 204
Virtual Branch Networks Validated Reference Design
The collected data is stored as the file filter.pcap file. Convert the file into a .tar file.
The command output should be similar to the following:
No. Time Source Destination Protocol Info
172 17:20:15.02133498.234.52.200 63.82.214.206 ISAKMP Identity Protection (Main Mode)
173 17:20:15.02137963.82.214.206 98.234.52.200 ISAKMP Identity Protection (Main Mode)
174 17:20:15.51257898.234.52.200 63.82.214.206 ISAKMP Identity Protection (Main Mode)
175 17:20:15.53734963.82.214.206 98.234.52.200 ISAKMP Identity Protection (Main Mode)
176 17:20:15.99758998.234.52.200 63.82.214.206 ISAKMP Identity Protection (Main Mode)
177 17:20:16.12566963.82.214.206 98.234.52.200 ISAKMP Identity Protection (Main Mode)
178 17:20:16.13087898.234.52.200 63.82.214.206 ISAKMP Quick Mode
179 17:20:16.13523163.82.214.206 98.234.52.200 ISAKMP Quick Mode
180 17:20:16.13761198.234.52.200 63.82.214.206 ISAKMP Quick Mode
181 17:20:16.13926463.82.214.206 98.234.52.200 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.
Aruba Networks, Inc. Troubleshooting Remote Access Points | 205
Virtual Branch Networks Validated Reference Design
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
The command output should be similar to the following:
To check usage of the IP pool, use the following command:(vrd-rap-local) #show vpdn l2tp local pool
The command output should be similar to the following:
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 206
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Troubleshooting Remote Access Points | 207
Virtual Branch Networks Validated Reference Design
The command output should be similar to the following (not all fields shown):
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>
The command output should be similar to the following (not all fields shown):
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 208
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 209
Virtual Branch Networks Validated Reference Design
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
------
Priority Source Destination Service Action TimeRange Log Expired Queue ....
-------- ------ ----------- ------- ------ --------- --- ------- ----- ----
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 210
Virtual Branch Networks Validated Reference Design
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):
Priority Source Destination Service Action TimeRange Log Expired 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
(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 ...
Aruba Networks, Inc. Troubleshooting Remote Access Points | 211
Virtual Branch Networks Validated Reference Design
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>
Aruba Networks, Inc. Troubleshooting Remote Access Points | 212
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 213
Virtual Branch Networks Validated Reference Design
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
The command output should be similar to the following:
(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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 214
Virtual Branch Networks Validated Reference Design
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>
The command output should be similar to the following:
(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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 215
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 216
Virtual Branch Networks Validated Reference Design
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.
Aruba Networks, Inc. Troubleshooting Remote Access Points | 217
Virtual Branch Networks Validated Reference Design
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 ...
(vrd-rap-local) #show datapath tunnel table
Datapath Tunnel Table Entries
-----------------------------
# 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 ....
Aruba Networks, Inc. Troubleshooting Remote Access Points | 218
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 219
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 220
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 221
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 222
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 223
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 224
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 225
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 226
Virtual Branch Networks Validated Reference Design
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
------------------
bss ess s/p ip phy type ch/EIRP/max-EIRP cur-cl ap name ...
--- --- --- -- --- ---- ---------------- ------ ------- ...
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 ...
Aruba Networks, Inc. Troubleshooting Remote Access Points | 227
Virtual Branch Networks Validated Reference Design
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:
(vrd-rap-local) #show datapath tunnel table
Datapath Tunnel Table Entries
-----------------------------
# 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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 228
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 229
Virtual Branch Networks Validated Reference Design
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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 230
Virtual Branch Networks Validated Reference Design
(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
Aruba Networks, Inc. Troubleshooting Remote Access Points | 231
Virtual Branch Networks Validated Reference Design
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
------------------
bss ess s/p ip phy type ch/EIRP/max-EIRP cur-cl ap name ...
--- --- --- -- --- ---- ---------------- ------ ------- ...
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 ...
(vrd-rap-local) #show datapath tunnel table
Datapath Tunnel Table Entries
-----------------------------
# 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 ...
Aruba Networks, Inc. Troubleshooting Remote Access Points | 232
Virtual Branch Networks Validated Reference Design
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
…
Aruba Networks, Inc. Troubleshooting Remote Access Points | 233
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Troubleshooting Remote Access Points | 234
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Forwarding Mode Feature Matrix | 236
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Virtual Branch Networks Validated Reference Design
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
Remote Call Center Agents
Small Branch Offices
Medium Branch Offices
Aruba Networks, Inc. Requirements Worksheets | 239
Virtual Branch Networks Validated Reference Design
Table 19 Site Template—Medium Branch Office Example
Forecast Connection Method Logical & Security Design
DescriptionMax
Devices (Today)
Max Devices(5 Years)
Wired
Wireless
Interface Auth Mode
Forwarding Mode
Operating Mode
DHCPSource
2.4 GHz 5 GHz
Enterprise Devices
Guest Devices
Total Devices
Aruba Networks, Inc. Requirements Worksheets | 240
Virtual Branch Networks Validated Reference Design
Table 20 Site Template—Fixed Telecommuter Example
Forecast Connection Method Logical & Security Design
DescriptionMax
Devices (Today)
Max Devices(5 Years)
Wired
Wireless
Interface Auth Mode
Forwarding Mode
Operating Mode
DHCPSource
2.4 GHz 5 GHz
Enterprise Devices
Family Devices
Total Devices
Aruba Networks, Inc. Requirements Worksheets | 241
Virtual Branch Networks Validated Reference Design
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
Medium Branch Offices
Small Branch Offices
Fixed Telecommuter
Remote Call Center Agents
Aruba Networks, Inc. Requirements Worksheets | 242
Virtual Branch Networks Validated Reference Design
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.
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.
Aruba Networks, Inc. Sample Configuration Files for Fixed Telecommuter Example | 243
Virtual Branch Networks Validated Reference Design
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 Networks, Inc. Sample Configuration Files for Fixed Telecommuter Example | 244
Aruba N
etworks, Inc.
Sam
ple Configuration Files for Fixed Telecom
muter E
xample
|245
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|246
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|247
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|248
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|249
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|250
Virtual B
ranch Netw
orksV
alidated Reference D
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
!interface gigabitethernet 1/2
description "GE1/3"trusted
!interface gigabitethernet 1/3
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
!interface gigabitethernet 1/1
description "GE1/1"trustedswitchport access vlan 214
!interface gigabitethernet 1/2
description "GE1/2"trustedswitchport mode trunkswitchport trunk allowed vlan 99
!interface gigabitethernet 1/3
description "GE1/3"trusted
!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
ple Configuration Files for Fixed Telecom
muter E
xample
|251
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|252
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|253
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|254
Virtual B
ranch Netw
orksV
alidated Reference D
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
ple Configuration Files for Fixed Telecom
muter E
xample
|255
Virtual B
ranch Netw
orksV
alidated Reference D
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)
Virtual Branch Networks Validated Reference Design
Aruba Networks, Inc. Sample Configuration Files for Fixed Telecommuter Example | 256
Virtual Branch Networks Validated Reference Design
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 support@arubanetworks.com
EMEA emea_support@arubanetworks.com
WSIRT EmailPlease email details of any securityproblem found in an Aruba product.
wsirt@arubanetworks.com
Validated Reference Design Contact and User Forum
Validated Reference Designs http://www.arubanetworks.com/vrd
VRD Contact Email referencedesign@arubanetworks.com
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
Virtual Branch Networks Validated Reference Design
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
top related