Your SlideShare is downloading. ×

Virtual Branch Networks

4,045

Published on

Published in: Technology, Travel
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,045
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Virtual Branch Networks Version 3.3.2-rn3.0
  • 2. 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 Code Certain 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 Notice The 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 Avenue Sunnyvale, California 94089 Phone: 408.227.4500 Fax 408.227.4550 Aruba Networks, Inc. 2
  • 3. Virtual Branch Networks Validated Reference Design Contents Chapter 1: Introduction 9 About the Aruba Virtual Branch Network 9 Aruba Validated Reference Designs 9 Design Validation and Testing Reference Documents 16 16 20 24 25 The Network Technology Lifecycle 27 The Network Technology Lifecycle 27 Defining Requirements for Remote Networks 31 Step 1 – Quantify Facility Requirements 31 Step 2 – Quantify Device Connectivity Requirements 32 Step 3 – Define RAP Equipment Requirements 36 Physical Design 39 Aruba Physical Architecture for Remote Networks Remote Site Physical Architectures Data Center Physical Architecture 39 41 45 Required Equipment Access Points Local Controllers Master Controllers AirWave Appliance 46 47 48 50 52 Required Licenses Local Controllers Master Controllers AirWave Appliance Aruba Networks, Inc. 13 13 14 14 Remote Networks Key Benefits Chapter 5: 13 Design Considerations for Remote Networks Chapter 4: Virtual Branch Theory of Operations Understanding the Aruba Virtual Branch Network Architecture Components of the Architecture Operation of the Architecture Chapter 3: 11 Virtual Branch Network Overview The Fixed Telecommuter—A One-Person Branch Medium and Small Branch Offices The Aruba Virtual Branch Network Solution Chapter 2: 11 52 52 52 53 Contents | 3
  • 4. Virtual Branch Networks Validated Reference Design 3G Modem Selection Wide-Area Network Considerations Bandwidth Constraints Latency Constraints 3G Wireless Constraints Recommendations for Minimizing Constraints Logical Design 59 59 60 62 63 Forwarding Modes Split-Tunnel Mode Tunnel Mode Bridge Mode Operating Modes Combined Forwarding and Operating Modes 64 64 66 68 69 70 AP/AM Data and Control Tunnels AP Tunnels AM Tunnels IP Ports Used by Aruba Devices Establish a Routable IP Subnet to the Master Controller 71 71 72 72 72 RAP Bootstrapping and Load Balancing 73 Controller High Availability Master Controller Redundancy Local Controller Redundancy (VRRP Layer 2 Method) Local Controller Redundancy (LMS-IP Layer 3 Method) 75 76 78 80 VLAN Design Choosing the Default Router 82 83 Authentication and Security Design 85 Authentication Methods (Wired and Wireless) Authenticating with 802.1X Authenticating with Captive Portal MAC Address Authentication 85 86 88 88 Authentication Methods (Wireless Only) 89 SSIDs for Secure WLANs Aruba Networks, Inc. 56 56 57 Aruba Logical Architecture for Remote Networks Fixed Telecommuter Logical Design Branch Office Logical Design Data Center Logical Design Chapter 7: 54 54 55 55 55 Regulatory Compliance for International Deployments Access Point Compliance Controller Compliance Chapter 6: 53 89 Contents | 4
  • 5. Virtual Branch Networks Validated Reference Design SSIDs 89 Role Derivation 90 Configuring Roles for Different Users Secure Role for Mobile Wireless Data Terminals Secure Role for Stationary Wired Devices Voice Handset Role Guest Access Role 92 92 92 92 93 Putting It All Together: Building an Authentication Design What Is A Profile? Aggregating Profiles into a Complete Configuration Planning AAA and SSID Profiles Example 802.1X Profile Configuration Best Practices for Profiles 94 94 96 97 98 99 Wireless Intrusion Detection System Operation and Design Detection of Rogue APs Classification of Rogue APs 103 103 103 104 105 106 107 107 Recommended Provisioning Methods Zero Touch Provisioning Pre-Provisioning 108 109 109 Site Procedure for Zero Touch Method Pre-Installation Checklist Site Installation Provisioning the RAPs 109 110 110 110 Site Procedure for Pre-Provisioning Method Pre-Installation Checklist Provisioning the RAPs Site Selection Site Installation 111 111 111 111 111 Site Validation Considerations Cabling and RAP Validation Client Device Validation Aruba Networks, Inc. Deploying Aruba Remote Networks Aruba Deployment Process for Remote Networks Step 1 – Deploy Data Center Step 2 – Install Pilot Sites Step 3 – Provision Backhaul Circuits Step 4 – Train the Help Desk Step 5 – Stage Site Equipment Step 6 – Execute Full Deployment Chapter 8: 100 100 101 112 112 112 Contents | 5
  • 6. Virtual Branch Networks Chapter 9: Validated Reference Design Example Configuration for the Branch Office Scenario 159 159 Configuring the Aruba Branch Office Solution Configure the Master Controller Configure the Local Controller Provision and Deploy RAPs 162 162 175 176 Reporting and Management 177 Remote Management Managing Both Legacy and New Network Elements Role-Based Management Planning and Location Services for Wireless Clients Scalability Trend Reporting Diverse WAN Environments 177 180 180 182 184 185 186 Troubleshooting Remote Access Points 187 Troubleshooting Categories 187 Troubleshooting Zero Touch Provisioning Problems 188 Troubleshooting Basic Connectivity Problems Working from the RAP Working from the Controller Troubleshooting the IPsec Tunnel Checking the IP Address Pool and Usage 189 189 191 192 206 Troubleshooting RAP Bootstrapping Problems Checking the VPN Role Policies Checking the RAP Role Transition Common Problem Symptoms 207 207 208 210 Troubleshooting Wired Port Configuration Problems Checking for an Enabled Wired Port Checking the Port Profile Checking the Authentication Profile 212 213 214 215 Troubleshooting Split-Tunnel Mode Problems Is the RAP Configured in Split-Tunnel Mode? Aruba Networks, Inc. 116 116 141 154 Simplified Design for the Branch Office Chapter 12: 113 Configuring the Aruba Fixed Telecommuter Solution Configure the Master Controller Configure Local Controllers Deploy RAP(s) Chapter 11: 113 Simplified Design for the Fixed Telecommuter Chapter 10: Example Configuration for the Fixed Telecommuter Scenario 216 217 Contents | 6
  • 7. Virtual Branch Networks Validated Reference Design Is the Split-Tunnel SSID Active on the AP? Does the Split-Tunnel SSID Have a GRE Tunnel with 802.1X? Has the Client Succeeded with 802.1X Authentication? Has the Client Received a DHCP IP Address from the Local LAN? Does Split-Tunneling Work at the Client End? Troubleshooting Bridge Mode Problems Checking the Configured Mode Bridge Mode with Dynamic Encryption Troubleshooting Tips Bridge Mode with Static Encryption (Pre-Shared Key) 218 218 219 221 224 225 227 227 229 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 243 Design Summary 243 Annotation Conventions Active-Master Configuration Active-Local Configuration 244 245 245 Appendix E: Aruba Contact Information 257 Contacting Aruba Networks Aruba Networks, Inc. 257 | 7
  • 8. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design | 8
  • 9. 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 plugand-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 Network With 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 Designs An 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
  • 10. 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. Optimizing Aruba WLANs for Roaming Devices Retail Wireless Networks High Density Wireless Networks Incremental Designs Virtual Branch Networks Base Designs RNSG_190 Campus Wireless Networks Wired Multiplexer (MUX) 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. Aruba Networks, Inc. Introduction | 10
  • 11. Virtual Branch Networks Validated Reference Design Design Validation and Testing The 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 Documents The 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
  • 12. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Introduction | 12
  • 13. Virtual Branch Networks Validated Reference Design Chapter 2: Virtual Branch Theory of Operations Virtual Branch Network Overview Enterprises 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
  • 14. 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
  • 15. 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: Branch Office / Telecommuter Home Internet Services Enterprise LAN Guest / Family Voice Enterprise Network Split Tunnel VL AN C Guest / Family Bridge VLAN Enterprise Controller Remote Access Point Internet or WAN Firewall/ NAT-T RNSG_066 VL AN A VLAN B Voice 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 Aruba Networks, Inc. Virtual Branch Theory of Operations | 15
  • 16. 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. Internet rnet Inte Enterprise Enterprise Wi-Fi & WIPS LAN Dynamic Role Assignment PEF Internet Enterprise Ethernet Secured Wired “NAC” (Per-User Stateful Policy Forwarding) VPN Client Enterprise To Controller USB Modem LAN RNSG_064 LAN 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.   Aruba Networks, Inc. Virtual Branch Theory of Operations | 16
  • 17. 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.   Management RADIUS / Active Directory / LDAP Mobility Controller Encryption To RAPs Authentication VPN Server Policy Definition and System Management To Enterprise Network Central Wireless & WIPS PEF (Policy Enforcement Firewall) Central Wireless & Wired NAC Redundancy QoS Rich Networking Figure 4  Integrate with Network RNSG_065 VRRP for Controller High Availability 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. Aruba Networks, Inc. Virtual Branch Theory of Operations | 17
  • 18. Virtual Branch Networks   Validated Reference Design PEF (Policy Enforcement Firewall): Aruba is currently the only vendor to integrate an ICSAcertified 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
  • 19. 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 Enterprise SSID RNSG_145 Family/Guest SSID Voice/Video SSID 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. High Security SSID Figure 6 Aruba Networks, Inc. Voice/Video SSID RNSG_144 Pre-Shared Key SSID Guest SSID Branch Office SSIDs Virtual Branch Theory of Operations | 19
  • 20. 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 preprovisioned 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
  • 21. 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. Associate Associate response EAP request identity EAP response EAP exchange Key1 Station Key2 RAP Key3 802.11 Association Figure 7 802.1X Authentication 4-way Handshake RNSG_057 Key4 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 Aruba Networks, Inc. Virtual Branch Theory of Operations | 21
  • 22. 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
  • 23. 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
  • 24. 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 Networks The 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
  • 25. 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 Benefits In 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
  • 26. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Virtual Branch Theory of Operations | 26
  • 27. 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 Lifecycle The 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. Define Operate Design RNSG_110 Deploy Figure 8 Aruba Networks, Inc. Network Technology Lifecycle The Network Technology Lifecycle | 27
  • 28. 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 predeployment 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
  • 29. 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 controllerbased 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
  • 30. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design The Network Technology Lifecycle | 30
  • 31. 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 Requirements Begin 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
  • 32. 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. Table 1 Facility Inventory Worksheet Example Usage Requirements Facility Type WAN Link Requirements Provisioni ng Max Devices per Site Guests Family Existing or New Link Type Speed Latency Provisioning Method 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 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 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 Site Count Fixed Telecommuters  USA Remote Call Center Agents  USA Small Branch Offices  USA 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 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 Requirements Completing 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. Aruba Networks, Inc. Defining Requirements for Remote Networks | 32
  • 33. 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
  • 34. 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 Description Max Devices (Today) Connection Method Wireless Max Devices (5 Years) Wired 2.4 GHz 5 GHz Logical & Security Design Interface Auth Mode Forwarding Mode Operating Mode DHCP Source 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 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 Wired PCs 2 5 fe/3 (L2 switch) Captive Portal Split-Tunnel n/a Enterprise Wireless Laptops 2 10 Guest SSID Captive Portal Split-Tunnel n/a Enterprise Total Devices 17 35 X Guest Devices X X X *Over time, wired devices transition to wireless. Aruba Networks, Inc. Defining Requirements for Remote Networks | 34
  • 35. 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 Description Max Devices (Today) Connection Method Logical & Security Design Wireless Max Device (5 years) Wired 2.4 GHz Interface Auth Mode Forwardin g Mode Operating Mode DHCP Source 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 Enterprise SSID 802.1X Split-Tunnel n/a Enterprise Voice Handset 0 1 Voice SSID MAC Tunnel n/a Enterprise 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 Family SSID Open Bridge Always RAP Total Devices 7 20 X X Family Devices X X *Over time, wired devices transition to wireless. Aruba Networks, Inc. Defining Requirements for Remote Networks | 35
  • 36. Virtual Branch Networks Validated Reference Design Step 3 – Define RAP Equipment Requirements With 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. Start Is Wireless Required? Yes No Is Dual-Radio Required? Yes No Is 802.11n Required? Yes No Over 5 Users Per AP? Yes No Select AP-125 Select Power Supply (US or ROW) Figure 9 Aruba Networks, Inc. Select RAP-2WG Select RAP-5WN Select Power Supply (US, EU or ROW) Select Power Supply (US or ROW) RNSG_155 Select RAP-5 RAP Selection Decision Tree Defining Requirements for Remote Networks | 36
  • 37. Virtual Branch Networks Table 4 Validated Reference Design 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 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 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 Small Branch Offices Fixed Telecommuter 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
  • 38. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Defining Requirements for Remote Networks | 38
  • 39. 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 Networks As 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
  • 40. 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. AirWave Management Platform Master active Master standby Application DHCP/ DNS PBX RADIUS Data Center DMZ Local active Internet or WAN Local active Branch Office Sites Fixed Telecommuter Sites 3G EVDO/GSM Carrier Broadband Carrier Cable Provider RAP-5 3G EVDO/GSM Carrier RAP-2WG RAP-5WN Medium Branch Figure 10 Aruba Networks, Inc. Small Branch Remote Call Center Agent Fixed Telecommuter RNSG_120 RAP-5WN Aruba Remote Network Physical Architecture Physical Design | 40
  • 41. 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
  • 42. 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. Data Center Internet or WAN Enterprise LAN 3G WWAN Enterprise IP Address Pool (Remote DHCP) Roles Enterprise Voice SSID DSL MPLS Frame Relay Voice Guest Internet Services Family SSID Remote Access Point IP Address Pool (Local DHCP) Enterprise SSID Enterprise Wired Access IP Phone Game Console/ DVR Shared Printer Family PC Wired PC Figure 11 RNSG_108 Family Wired Access 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 Aruba Networks, Inc. Physical Design | 42
  • 43. Virtual Branch Networks Validated Reference Design family printer can be accessed from the employee devices. Internet access is implemented via splittunnel for both employee and family devices. NOTE 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. 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. NOTE Do not use a layer 2 switch in front of a RAP wired port if 802.1X authentication is in use. 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. Enterprise Access RAP Data Center IP Phone Internet Services Figure 12 Aruba Networks, Inc. Wired PC Roles Enterprise Voice RNSG_109 802.1Q Trunk Internet or WAN Fixed Telecommuter Call Center Application Physical Design | 43
  • 44. 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. Roles Enterprise Data Center Enterprise LAN 3G WWAN Enterprise IP Address Pool (Remote DHCP) Voice Internet or WAN Guest DSL MPLS Frame Relay Internet Services Remote Access Point IP Address Pool (Local DHCP) Voice SSID Guest SSID Enterprise SSID Guest Wired Access RNSG_107 Enterprise Wired Access HTTPS Application Server 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. Aruba Networks, Inc. Physical Design | 44
  • 45. 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. Data Center AirWave Management Platform Remote Network Campus Network Master active Master standby Master active Master standby Application DHCP/ DNS PBX RADIUS Distribution Layer DMZ Campus RAP Local active Local active RAP Local active Local active Internet or WAN Figure 14 Aruba Networks, Inc. RNSG_114 Campus Aruba Remote Network Physical Architecture Physical Design | 45
  • 46. 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 Equipment To 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. Branch Office Select RAP Model(s) Select RAP Model(s) Estimate Client Device Count (using Table 2) Estimate Client Device Count (using Table 3) Multiply Client Device Count by Site Count (using Table 1) Remote Sites Fixed Telecommuter Multiply Client Device Count by Site Count (using Table 1) Select Local Controller Model equal to 150% of Total Client Device Count (each) DMZ Select Master Controller Model (using Table 3) Multiple Masters required? Data Center Yes Assign all Locals to separate Master/Local clusters Select AirWave Server Appliance equal to 150% of All APs & Controllers Figure 15 Aruba Networks, Inc. RNSG_153 No Equipment Decision Tree Physical Design | 46
  • 47. 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: Aruba RAP-5 Remote Access Point 4 Wired Ports + 1 Uplink Port No Wireless Radio Up to 256 users/devices 1 USB Port PoE or 12V DC Powered Aruba RAP-2WG Remote Access Point 1 Wired Port + 1 Uplink Port Single 802.11 b/g Radio Up to 5 users/devices 12V DC Powered Figure 16 Aruba RAP-5WN Remote Access Point 4 Wired Ports + 1 Uplink Port Single 3x3 MIMO Radio, 802.11a/b/g/n Up to 256 users/devices 1 USB Port PoE or 12V DC Powered Aruba AP-125 Access Point 1 Wired Port + 1 Uplink Port Dual 3x3 MIMO Radios, 802.11/a/b/g/n Up to 256 users/devices PoE or 5V DC Powered 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. NOTE Aruba Networks, Inc. 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. Physical Design | 47
  • 48. 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: 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 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. Aruba 3600 Controller Up to 512 RAPs (2,048 Users) 4 Gigabit Ethernet (1000Base-T or 1000Base-X SFP) Figure 17 Aruba Networks, Inc. Aruba M3 Blade Up 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 Controller Blades for MMC-6000 Chassis Physical Design | 48
  • 49. 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. Certificate-based provisioning and zero touch provisioning are only supported on the M3 Blade and 3000 series controllers. NOTE Table 6 Controller Product Line Matrix MMC-3000 Series MMC-6000 Series Features 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 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 MAC addresses Aruba Networks, Inc. Physical Design | 49
  • 50. 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. Table 7 Local Controller Sizing by License Count RAP Site Count Devices per Site 50 100 250 500 1,000 2,000 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 MMC-3400 MMC-3600 1xM3 1xM3 2xM3 4xM3 15 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 6000series chassis with redundant 400W power supplies. NOTE Certificate-based provisioning and zero touch provisioning are only supported on the M3 Blade and 3000 series controllers. Figure 18 Aruba Networks, Inc. Aruba MMC-6000 Chassis with 4 M3 Blades Physical Design | 50
  • 51. 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. Table 8 Maximum Number of APs and Users or Devices per Master Controller Model 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 Master 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. Table 9 Master Controller Sizing by Client Device Count Number of RAP Sites Devices per Site 50 100 250 500 1,000 2,000 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 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. Aruba Networks, Inc. Physical Design | 51
  • 52. 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 Licenses To support RAPs, the local controllers must have RAP licenses to provide IPsec encryption and splittunnel or local bridging features. All controllers in a Master/Local cluster must be running the same version of software. NOTE 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. 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. 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
  • 53. 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 Selection 3G 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
  • 54. Virtual Branch Networks Validated Reference Design Manufacturer Model 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 NOTE 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. 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 Considerations The 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 lowspeed 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,” reestablishing 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. Aruba Networks, Inc. Physical Design | 54
  • 55. 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 highlatency 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
  • 56. 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 Deployments AP 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. NOTE Aruba Networks, Inc. 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. Physical Design | 56
  • 57. 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. Rest-Of-World Controller Managing APs in Multiple Regional Domains UK_AP_group FRG_AP_group ROW Controller USA Controller France_AP_group Region-Specific Country Code RNSG_071 Italy_AP_group Spain_AP_group Figure 19 Aruba Networks, Inc. United States Controllers Cannot Manage RAPs In Other Countries Physical Design | 57
  • 58. 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. UK_AP_group FRG_AP_group ROW Controller Rest of World Controller Managing APs in Multiple Regional Domains Italy_AP_group Spain_AP_group Figure 20 RNSG_070 France_AP_group 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. Aruba Networks, Inc. Physical Design | 58
  • 59. 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 Networks A 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 GREencapsulated 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
  • 60. 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. Management AirWave Management Platform Master active Master standby RADIUS DHCP / DNS Application Data Center Enterprise LAN Voice LAN PBX Aggregation Local active Local active DMZ Internet or WAN Overlay Internet Services Network Access Family SSID Voice SSID Wired PC IP Phone Figure 21 Aruba Networks, Inc. Shared Printer Family PC Game Console/ DVR RNSG_121 Enterprise SSID Remote Network Logical Architecture–Fixed Telecommuter Logical Design | 60
  • 61. 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 preshared 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
  • 62. 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. Management AirWave Management Platform Master active Master standby RADIUS DHCP / DNS Application Data Center Enterprise LAN Voice LAN PBX Aggregation Local active Local active DMZ Internet or WAN Overlay Internet Services Guest Laptops Network Access Enterprise SSID Voice SSID PC HTTPS Application Server Figure 22 Aruba Networks, Inc. Printer IP Phone RNSG_105 Guest Laptop Remote Network Logical Architecture–Branch Office Logical Design | 62
  • 63. 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
  • 64. Virtual Branch Networks Management Validated Reference Design Airwave Management Platform Master active Master standby RADIUS DHCP / DNS VRRP WMS Offload WMS DB Sync 802.1X Authentications Data Center Enterprise LAN Voice LAN Con trol Local active VRRP PBX Local active RNSG_154 Aggregation DMZ Figure 23 Application 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 Modes A 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-bySSID 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 Aruba Networks, Inc. Logical Design | 64
  • 65. 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. IPsec/AES-CCM Encrypted Control Channel Remote Location Enterprise HQ LAN PC Shared Use Printer Guest/Family SSID Websites RAP (with firewall) Enterprise SSID (Split Tunnel Mode-802.1X) Firewall / NAT-T Internet or WAN Enterprise SSID Voice SSID Voice SSID Figure 24 Aruba Networks, Inc. RNSG_124 Enterprise IP Phone Split-Tunnel Mode Logical Design | 65
  • 66. 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. Table 10 Management Frame Processing–Split-Tunnel Mode Management Frame Type Open, Static WEP, PSK Processing Location 802.1X Processing Location Probea RAP RAP 802.11 Auth RAP RAP 802.11 Assoc RAP Controller EAP n/a Controller Key Exchange RAP Controller a. Requires that local probe response be enabled.   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. NOTE Each device on split-tunnel mode VLANs counts towards the PEF license limit on the local controller. 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. Aruba Networks, Inc. Logical Design | 66
  • 67. 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. Tunnel mode traffic from the wired port is always IPsec encrypted, regardless of the double-encrypt settings. NOTE Remote Location LAN PC Enterprise LAN Shared Use Printer Websites Guest/Family SSID Enterprise SSID Internet Traffic Enterprise SSID Voice SSID IPsec Tunnel RAP (no firewall) Internet or WAN Firewall / NAT-T Voice SSID Figure 25 RNSG_122 Enterprise IP Phone 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 Table 11 Management Frame Processing–Tunnel Mode Management Frame Type Open, Static WEP, PSK Processing Location 802.1X Processing Location Probea RAP RAP 802.11 Auth RAP RAP 802.11 Assoc Controller Controller EAP n/a Controller Key Exchange Controller Controller a. Requires that local probe response be enabled. Aruba Networks, Inc. Logical Design | 67
  • 68. Virtual Branch Networks NOTE Validated Reference Design Each device on a tunnel mode VLAN counts towards the PEF license limit on the local controller. 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. Table 12 Management Frame Processing–Bridge Mode Management Frame Type Open, Static WEP, PSK Processing Location 802.1X Processing Location Probea RAP RAP 802.11 Auth RAP RAP 802.11 Assoc RAP Controller EAP n/a Controller Key Exchange RAP Controller a. Requires that local probe response be enabled. 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. Aruba Networks, Inc. Logical Design | 68
  • 69. Virtual Branch Networks Validated Reference Design IPsec/AES-CCM Encrypted Control Channel Remote Location Guest/Family SSID (Bridge Mode-PSK) Shared Use Printer Enterprise HQ LAN PC Websites Locally Bridged Data Firewall / NAT-T Internet or WAN RAP (with firewall) Enterprise SSID Voice SSID RNSG_123 Enterprise SSID Voice SSID Figure 26 Bridge Mode Devices on bridge mode VLANs do not count towards the PEF license limit on the local controller. NOTE 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. 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  Bridge  Bridge  Bridge 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  Split-tunnel  Bridge ESSID Availability Aruba Networks, Inc. Up only when controller is reachable Logical Design | 69
  • 70. Virtual Branch Networks Table 13 Validated Reference Design Operating Modes (Continued) Standard Persistent Backup Always 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 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. IPsec/AES-CCM Encrypted Control Channel LAN PC Guest/Family SSID (Bridge Mode-PSK) Enterprise HQ Shared Use Printer Websites Firewall / NAT-T Enterprise SSID (Split-Tunnel Mode-802.1X) Voice SSID (Full Tunnel Mode-PSK) Figure 27 RAP (with firewall) Internet or WAN Enterprise SSID Voice SSID RNSG_128 Remote Location Enterprise IP Phone 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. Aruba Networks, Inc. Logical Design | 70
  • 71. Virtual Branch Networks Validated Reference Design AP/AM Data and Control Tunnels Aruba 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. Management Master ol ntr Co Aggregation Local IPsec NAT-T UDP 4500 PAPI Control Tunnels Network Access Ada WIP ptiv Det eR ecti adio on & Man age Con tain SSID “Voice” (2.4 GHz) Tunnel Mode Secure Jack Secure Jack (IP Phone) (Wired PC) Tunnel SplitSSID SSID SSID SSID Mode “Enterprise” “Enterprise” Tunnel “Guest” “Voice” Mode (2.4 GHz) (5 GHz) (2.4 GHz) (5 GHz) Split-Tunnel Split-Tunnel Bridge Tunnel Mode Mode Mode Mode Figure 28 Aruba Networks, Inc. men t Tr men SSID “Guest” (5 GHz) Bridge Mode t Tr affic affic Secure Jack (Guest PC) Bridge Mode Air Monitor RNSG_106 GRE Data Tunnels Aruba WLAN AP/AM Communication and Tunneling Logical Design | 71
  • 72. 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. NOTE Split-tunnel and bridge mode are only available for RAPs. All campusconnected APs with onsite local controllers use tunnel mode. 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) NOTE PAPI between a master and a local controller is encapsulated in IPsec in ArubaOS 3.x 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 Aruba Networks, Inc. Logical Design | 72
  • 73. 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 NOTE 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. RAP Bootstrapping and Load Balancing The 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.  Aruba Networks, Inc. Logical Design | 73
  • 74. Virtual Branch Networks Validated Reference Design IKE Phase 1 Security Association Within VPN Tunnel 6 Frames Main Mode Auth) esult (X on R enticati Auth Extract RAP MAC Address from Certificate and Validate Against Local Database ACK (X Auth) Reque st (XAu th) IPSEC th) d (XAu ssigne A Inner IP SA 3 Frames Aggressive Mode  RNSG_227 Inner IP 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. NOTE Aruba Networks, Inc. Remote access points must be L3 separated from Aruba controllers. Never bootstrap a RAP when it is on the same VLAN as a controller. Logical Design | 74
  • 75. 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. San Francisco Data Center Master New York Data Center Master 229.10.1.1 229.20.1.1 “rapcontroller.companyABC.com”= 229.10.1.1 Internet or WAN “rapcontroller.companyABC.com”= 229.20.1.1 San Francisco Home Office Figure 29 New York Home Office RNSG_125 DNS Server DNS Server Bootstrapping and Load Balancing Configuration Controller High Availability For 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. Aruba Networks, Inc. Logical Design | 75
  • 76. 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. Active Master Periodic database synchronization Standby Master VRRP keepalives RNSG_043 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. NOTE 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. 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. Aruba Networks, Inc. Logical Design | 76
  • 77. Virtual Branch Networks Validated Reference Design Use the following commands to create the IP and VRRP configuration for the primary master controller: 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> ! Use the following CLI commands to create the IP and VRRP configuration for the backup master controller: 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> ! 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: database synchronize period 30 database synchronize rf-plan-data ! Use the following CLI command to configure the local controllers to use the virtual IP address as their master controller address. masterip 172.21.998.100 ipsec <key> ! Aruba Networks, Inc. Logical Design | 77
  • 78. 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. Keepalives Local Local arun_044 Figure 31 RNSG_044 Active VIP Standby VIP Active VIP Standby VIP 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. Aruba Networks, Inc. Logical Design | 78
  • 79. 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. Active VIP Active VIP Unreachable arun_045 Local Figure 32 RNSG_045 Local 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 ! Aruba Networks, Inc. Logical Design | 79
  • 80. Virtual Branch Networks Validated Reference Design The second local controller has an opposite configuration: 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 ! 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. Aruba Networks, Inc. Logical Design | 80
  • 81. 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. Data Center 1 Active Data Center 2 Backup IP Address = “a” IP Address = “b” Internet or WAN Primary Tunnel Backup Tunnel RNSG_126 RAP configuration: Ims-ip = “a” bkupIms-ip = “b” Home Office Figure 33 Aruba Networks, Inc. Inter-Site Redundancy Logical Design | 81
  • 82. 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. Data Center 1 Data Center 2 VRRP a VR IP = “a” VRRP b VR IP = “b” Internet or WAN Home Office Figure 34 RNSG_127 RAP configuration: Ims-ip = “a” bkupIms-ip = “b” Inter-Site and Intra-Site Redundancy Used Together VLAN Design One 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. Aruba Networks, Inc. Logical Design | 82
  • 83. 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. 300 Employee (802.1X) VLAN 200 PBX VLAN 300 200 Wi-Fi Voice (WPA2-PSK) Application Figure 35 RNSG_053b Internet or WAN 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. Aruba Networks, Inc. Logical Design | 83
  • 84. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Logical Design | 84
  • 85. 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. NOTE Aruba Networks, Inc. Do not use a layer 2 switch in front of a RAP wired port if 802.1X authentication is in use. Authentication and Security Design | 85
  • 86. 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. Associate Associate response EAP request identity EAP response EAP exchange Key1 Key2 Station RAP Key3 802.11 Association Figure 36 Aruba Networks, Inc. 802.1X Authentication 4-way Handshake RNSG_057 Key4 802.1X Authentication Handshake Authentication and Security Design | 86
  • 87. 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. Aruba Controller L2/L3 Switch 5 3 2 3 1 AP 4 Corporate Backbone 1. Client sends 802.11 association request that is automatically forwarded by the AP to the Aruba Controller RADIUS Server 2. Aruba Controller responds with association acknowledgement 3. Client and Aruba Controller start 802.1X authentication conversation along with RADIUS server RNSG_056 4. Encryption keys passed to the Aruba Controller, and user derives own encryption keys, begins sending encrypted data 5. Aruba Controller decrypts data, processes packets, applies services and forwards packets based on 802.11 MAC 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. Aruba Networks, Inc. Authentication and Security Design | 87
  • 88. 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
  • 89. 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 WLANs Each 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
  • 90. Virtual Branch Networks Validated Reference Design Clients typically make roaming decisions based on the received signal strength of the audible BSSIDs they can hear. Pre-Shared Key SSID Figure 39 Guest SSID Voice/Video SSID RNSG_144 High Security SSID 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 Derivation Aruba 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 Aruba Networks, Inc. Authentication and Security Design | 90
  • 91. 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. START Collect Aruba DSA’s 802.3 User MAC (Example: 00:34:d4:ca:58:0f) Port ID (Example: FastEthernet 1/8) Tunnel ID (Example: Tunnel-109) Collect Aruba DSA’s (Device Specific Attribute) BSSID ESSID Location User MAC Encryption No VLAN derivation past this point YES 802.11 PHY (Example: 00:0b:86:12:fd:37) (Example: guest, contractor, staff) (Example: 10.0.0, 27.4.0, 41.2.5) (Example: 00:34:d4:ca:58:0f) (Example: WEP, TKIP, AES, etc.) 802.11 is always Un-Trusted Trust NO 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. Is User in Database? VPN Login? YES NO NO CP Login? YES NO User Derivation? NO Authentication YES NO dot1x Auth YES YES MAC Auth YES USER Derivation Radius contains ends with equals does not equal starts with value of NO User Derivation will be overridden by later processes NO AUTHENTICATION SOURCES XML LDAP AUTHENTICATION SOURCES NO Server Derivation YES TACACS+ Internal YES Aruba VSA’s Authenticated NO YES Aruba DSA’s Aruba-User-Role Aruba-User-Vlan Aruba-Priv-Admin-User Aruba-Admin-Role Aruba-Essid-Name Aruba-Location-Id Aruba-Port-Identifier SERVER Derivation BSSID ESSID Location User MAC Encryption-Type DHCP-opt-77 Authentication contains ends with equals does not equal starts with value of YES Radius Returned VSA’s NO Aruba DSA’s YES NO User Derived Role/VLAN Logon Role/Default VLAN ESSID Location User MAC Role/VLAN Auto Applied Default Role/VLAN Radius VSA Derived Role/VLAN Aruba DSA Derived Role/VAN Aruba VSA Derived Role/VLAN NO ESI YES ESI Derived Role/VAN Figure 40 Aruba Networks, Inc. RNSG_225 EXIT TO DATA PATH Role Derivation Flowchart Authentication and Security Design | 91
  • 92. 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 Users The 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
  • 93. 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. Access controlled Figure 41 No access after hours RNSG+067 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. 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. Data Figure 42 Controlled data RNSG_068 Mobility controller 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. Aruba Networks, Inc. Authentication and Security Design | 93
  • 94. Virtual Branch Networks Validated Reference Design Putting It All Together: Building an Authentication Design The 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. SSID Profile AAA Profile “XYZ_Corp_Employees” “XYZ_dot1x_AAA_Profile” Properties Properties Network Name = “Employee_SSID” Authentication = 802.1X Encryption = AES 802.11g Rates = 1,2,5,6,9,11,12,18,24,36,48,54 802.11a Rates = 6,9,12,18,24,36,48,54 RTS Threshold = 2333 bytes Hide SSID = No Short Preamble = Yes Initial Role = Logon 802.1X Default Role = “XYZ_Corp_dot1x_Role” User Derivation Rules = None Wired-to-Wireless Roaming = Yes Dependent Profiles 802.1X Server Group 802.1X Authentication Profile 802.1X Authentication Profile “XYZ_Corp_dot1x_Server” Name = “ias@summit.corp.com” Server Type = RADIUS Fail-Through = No Figure 43 “XYZ_Corp_dot1x_Profile” Max Auth Failures = 0 Termination EAP-Type = “EAP-PEAP” Termination Inner EAP-Type = “EAP-MSCHAPv2” RNSG_077 802.1X Server Group 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 Aruba Networks, Inc. Authentication and Security Design | 94
  • 95. 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 NOTE Aruba Networks, Inc. Configuring an SSID Profile in the Controller GUI Profile names, AP names, and AP Group names must not contain any spaces or other white space characters. Authentication and Security Design | 95
  • 96. 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. AP Group “Small_Branch_Office_Group” VAP Profile VAP Profile VAP Profile VAP Profile “HighSecurity_VAP_Profile” “Pre-Shared_Key_VAP_Profile” “Guest_VAP_Profile” “Voice_VAP_Profile” VLAN = 100 VLAN = 200 VLAN = 300 VLAN = 400 SSID Profile SSID Profile SSID Profile SSID Profile “HighSecurity_SSID_Profile” “Pre-Shared_Key_SSID_Profile” “Guest_SSID_Profile” “Voice_SSID_Profile” AAA Profile AAA Profile AAA Profile “HighSecurity_AAA_Profile” “Pre-Shared_Key_AAA_Profile” “Guest_AAA_Profile” Dependent Profiles 802.1X Server Group 802.1X Authentication Profile Dependent Profiles 802.1X Server Group 802.1X Authentication Profile 802.1X Authentication Profile 802.1X Authentication Profile “HighSecurity_dot1x_Profile” “Pre-Shared_Key_dot1x_Profile” 802.1X Server Group Figure 45 Aruba Networks, Inc. AAA Profile “Voice_AAA_Profile” CP Server Group CP Authentication Profile Captive Portal Authentication Profile “Guest_CP_Profile” Captive Portal Server Group RNSG_079 Dependent Profiles Typical AP Group for Remote Networks SSIDs with Nested VAP Profiles Authentication and Security Design | 96
  • 97. 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
  • 98. 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
  • 99. 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. NOTE All APs configured in a mass configuration must be of the same type, but an AP group can contain APs of various types. 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_Servers b. 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. Aruba Networks, Inc. Authentication and Security Design | 99
  • 100. 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 Design This 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
  • 101. 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. 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. 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. Aruba Networks, Inc. Authentication and Security Design | 101
  • 102. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Authentication and Security Design | 102
  • 103. 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 Networks Aruba recommends a six-step process for large-scale remote network rollouts. The general deployment sequence is shown in Figure 47. Step 2 Install Pilot Sites Step 3 Provision Backhaul Circuits Step 4 Train Help Desk Step 5 Stage Site Equipment Step 6 Execute Full Deployment Retail_100 RNSG_111 Step 1 Deploy Data Center 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. Aruba Networks, Inc. Deploying Aruba Remote Networks | 103
  • 104. 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
  • 105. 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
  • 106. 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
  • 107. 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
  • 108. Virtual Branch Networks Validated Reference Design Recommended Provisioning Methods Aruba 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. Table 15 RAP Provisioning Methods Method Description Selection Criteria Zero Touch Provisioning  RAP is drop-shipped directly to the site  Home-based employees or very small branch offices.  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.  AP with security certificate and provisioning image (RAP-2WG, RAP-5, RAP-5WN)  Controllers with security certificate (3000 Series, M3 blades)  RAP is connected to a LAN-accessible controller at  Medium or small branch offices where employees a staging site and programmed.  RAP is shipped “ready to go” to the site (possibly along with other equipment to be installed). Pre-Provisioning 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) Zero touch and pre-provisioning methods are shown in Figure 48. Pre-Provisioning Method Zero Touch Provisioning Method Site Equipment Remote Access Points ship Data Center Site-to-Site VPN ship Site # 1 Load Whitelist Data Center Staging Center ship ship ship Site # 2 Site # 3 Site # 1 ship Site # 2 ship Site # 3 Certificate-Based Whitelist Authentication Figure 48 RNSG_221 Remote Access Points 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. Aruba Networks, Inc. Deploying Aruba Remote Networks | 108
  • 109. 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 Method This 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
  • 110. 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
  • 111. Virtual Branch Networks Validated Reference Design Site Procedure for Pre-Provisioning Method This 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
  • 112. Virtual Branch Networks Validated Reference Design Site Validation Considerations It 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
  • 113. 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 Telecommuter This 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-theair 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
  • 114. 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. Master Controller ge1/3 172.21.98.251 (Router configured to route 172.21.98.1 RAP IP Pool & Local to Master) 10.0.0.0 (Static Route from Local) RADIUS Enterprise 172.21.98.0/24 VLAN 98 10.168.115.130 10.168.115.128/27 VLAN 128 Alias = “ent_network” SIP Server 172.21.99.1 Voice 172.21.99.0/24 VLAN 99 172.21.99.250 ge1/2 (.1Q) Local Controller 10.168.115.160/27 VLAN 160 Alias = “voice_network” 10.168.115.162 RAP IP Pool 10.168.115.225 10.168.115.239 Voice Voice SSID fe1/2 VLAN 160 Fwd Mode = Tunnel 99.99.99.00/24 VLAN 214 99.99.99.1 Enterprise SSID RAP-5WN LMSIP = 99.99.99.14 Internet or WAN fe1/0 Family SSID fe1/3 & fe1/4 192.168.177.1 Shared Printer Figure 49 Aruba Networks, Inc. Enterprise fe1/1 VLAN 128 Fwd Mode = Split-Tunnel 192.168.177.0/24 Alias = “family_network” VLAN 177 Fwd Mode = Bridge DHCP Start = 192.168.177.100 DHCP End = 192.168.177.254 RNSG_116 ge1/1 99.99.99.14 Network Design for the Fixed Telecommuter Example Example Configuration for the Fixed Telecommuter Scenario | 114
  • 115. Dependent Profiles - Wireless Enet1 Port Profile Enet2 Port Profile Virtual AP Profile Enet3 Port Profile Dependent Profiles - General Virtual AP Profile Virtual AP Profile AP System Profile Enet4 Port Profile AP Wired Port Profile Wired_Ent_Port_profile (Task 6A) Dependent Profiles AP Wired Port Profile Wired_Voice_Port_profile (Task 6B) Dependent Profiles AP Wired Port Profile Wired_Family_Port_profile (Task 6C) Dependent Profiles AAA Profile AAA Profile AAA Profile Wired AP Profile Wired AP Profile Wired AP Profile VAP Profile Enterprise_vap_profile (Task 5A) vlan = 128 forward-mode = split-tunnel Dependent Profiles VAP Profile Voice_vap_profile (Task 5B) VAP Profile Family_vap_profile (Task 5C) vlan = 160 forward-mode = tunnel vlan = 177 forward-mode = bridge rap-operation = always Dependent Profiles AAA Profile AAA Profile SSID Profile SSID Profile Dependent Profiles AAA Profile SSID Profile Wired AP Profile Wired_Voice_ap_profile (Task 6B) Wired AP Profile Wired_Family_ap_profile (Task 6C) wired-ap-enable = yes forward-mode = split-tunnel switchport access vlan = 128 wired-ap-enable = yes switchport access vlan = 160 wired-ap-enable = yes forward-mode = bridge switchport access vlan = 177 AAA Profile Remote_Ent_aaa_profile (Task 4D) AAA Profile Wired_Voice_aaa_profile (Task 4F) dot1x-default-role = Remote_Enterprise_user_role initial-role = denyall_user_role Dependent Profiles 802.1X Server Group 802.1X Authentication Profile dot1x-default-role = Enterprise_Voice_user_role initial-role = logon mac-default-role = Enterprise_Voice_user_role mac-server-group = internal SSID Profile Enterprise_ssid_profile (Task 5A) essid = “Enterprise” opmode = wpa2-aes AAA Profile Family_aaa_profile (Task 4G) SSID Profile Voice_ssid_profile (Task 5B) essid = “Voice” opmode = wpa2-aes SSID Profile Family_ssid_profile (Task 5C) essid = “Family” wpa-passphrase = “arubarocks” opmode = wpa2-psk-aes AAA Profile Voice_aaa_profile (Task 4F) dot1x-default-role = Enterprise_Voice_user_role initial-role = logon initial-role = family_user_role authentication-dot1x = default-psk Dependent Profiles 802.1X Server Group Dependent Profiles 802.1X Authentication Profile 802.1X Server Group 802.1X Authentication Profile AP System Profile APGroup1_sys_profile (Tasks 7A & 7B) 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 dns-domain = arubanetworks.com dns-domain = airwave.com 802.1X Authentication Profile Remote_Enterprise_dot1x (Task 4B) MAC Authentication Profile Wired_Voice_mac (Task 4C) AP Server Group RADIUS_Servers (Task 4A) Dependent Profiles AAA Authentication Server AAA Authentication Server dot1x_server1 (Task 4A) type = RADIUS host = 10.168.115.130 key = “arubasecure” Figure 50 Profile Design for the Fixed Telecommuter Example RNSG_226 MAC Authentication Profile Validated Reference Design Example Configuration for the Fixed Telecommuter Scenario | 115 Wired AP Profile Wired_Ent_ap_profile (Task 6A) Virtual Branch Networks Dependent Profiles - Wired From an Aruba controller perspective, the profile design required to implement this reference model can be seen in Figure 50. Aruba Networks, Inc. AP Group Fixed_Telecommuter_APGroup1 (Task 8)
  • 116. Virtual Branch Networks Validated Reference Design Configuring the Aruba Fixed Telecommuter Solution The 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. Configure Local Deploy RAP RNSG_129 Configure Master Figure 51 Three Steps to Configure the Aruba Fixed Telecommuter Solution Configure the Master Controller 3. 4. 5. 6. 7. 8. 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. Configure the network destination, firewall policies, and user roles. Configure the AAA server, AAA server group, AAA profile, and AAA authentication profiles. Configure the SSID and virtual AP profiles. Configure the wired AP and wired port profiles. Configure the AP system profile. 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 116
  • 117. 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. NOTE 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. 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 117
  • 118. 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 Aruba Networks, Inc. GUI Setup Wizard Welcome Screen Example Configuration for the Fixed Telecommuter Scenario | 118
  • 119. 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 Aruba Networks, Inc. Controller Basic Information Setup Example Configuration for the Fixed Telecommuter Scenario | 119
  • 120. 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. NOTE 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. 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 120
  • 121. 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
  • 122. 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
  • 123. 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
  • 124. Virtual Branch Networks Validated Reference Design 3. Click Next. Figure 59 NOTE Aruba Networks, Inc. Port Configuration It is assumed that both the active and standby master controllers have “onearmed” connections to distribution switches as recommended in Chapter 6. If this is not the case in your environment, this step may not be necessary. Example Configuration for the Fixed Telecommuter Scenario | 124
  • 125. 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
  • 126. 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. NOTE Aruba Networks, Inc. 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. Example Configuration for the Fixed Telecommuter Scenario | 126
  • 127. 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
  • 128. 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
  • 129. 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. NOTE NOTE Aruba Networks, Inc. If it is not desirable to add a routable IP address to the Aruba controller, use an external router or firewall address and forward the traffic to an existing interface on the controller. Only NAT-T traffic (udp/4500) needs to be forwarded. If the RAPs use DNS to resolve the IP address of the DMZ controller, add the appropriate records to the DNS servers. Example Configuration for the Fixed Telecommuter Scenario | 129
  • 130. 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: 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 ! 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 NOTE Aruba Networks, Inc. This simplified example configuration assumes that the local controller is inside a DMZ and is not connected directly to the Internet. Example Configuration for the Fixed Telecommuter Scenario | 130
  • 131. 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. 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 ! 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: user-role RemoteAP_user_role session-acl RemoteAP_acl ! 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. 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 ! 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: user-role Remote_Enterprise_user_role session-acl Remote_Enterprise_acl ! Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 131
  • 132. 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: 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 ! 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 Enterprise_voice_user_role session-acl Enterprise_voice_acl ! 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). Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 132
  • 133. 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. 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 ! Step 3I: Configure the Family User Role Use the following CLI commands to create the user role Family_user_role: user-role Family_user_role session-acl Family_acl ! 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: ip access-list session denyall_acl any any any deny ! 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: user-role denyall_user_role session-acl denyall_acl ! 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 Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 133
  • 134. 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: aaa authentication-server radius dot1x_server1 host 10.168.115.130 key arubasecure ! aaa server-group RADIUS_Servers auth-server dot1x_server1 ! 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. NOTE 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. Use the following CLI command to create the remote enterprise 802.1X profile: aaa authentication dot1x Remote_Enterprise_dot1x ! 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 mac Wired_Voice_mac ! Step 4D: Create the Enterprise AAA Profile An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients on wireless SSIDs and wired ports. The AAA profile also specifies the default user roles for 802.1X and MAC authentication. The remote enterprise AAA profile will force devices to authenticate with the RADIUS server using the 802.1X profile before any access is granted. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 134
  • 135. 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: 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 ! 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: aaa authentication wired profile Remote_Ent_aaa_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 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
  • 136. 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: 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 ! 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: aaa profile Family_aaa_profile initial-role Family_user_role authentication-dot1x default-psk ! 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: 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
  • 137. 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: 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 ! 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. NOTE Aruba Networks, Inc. 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. Example Configuration for the Fixed Telecommuter Scenario | 137
  • 138. Virtual Branch Networks Validated Reference Design Use the following CLI commands to create the family SSID and VAP 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 ! 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: 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
  • 139. 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: 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 ! 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_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
  • 140. 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). NOTE 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. Use the following CLI commands to create the AP system profile: 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 ! 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. NOTE If a RAP DHCP DNS server is not defined, the DNS server obtained from DHCP on the uplink enet0 port will be used. 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 Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 140
  • 141. 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. ap system-profile APGroup1_sys_profile dns-domain arubanetworks.com dns-domain airwave.com ! 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: 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 ! 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 141
  • 142. 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 Aruba Networks, Inc. GUI Setup Wizard Welcome Screen Example Configuration for the Fixed Telecommuter Scenario | 142
  • 143. 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 Aruba Networks, Inc. Controller Basic Information Setup Example Configuration for the Fixed Telecommuter Scenario | 143
  • 144. 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. The VLANs displayed in this section are used as examples only. NOTE 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 144
  • 145. 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
  • 146. 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 Aruba Networks, Inc. Configuring Controller Connectivity Example Configuration for the Fixed Telecommuter Scenario | 146
  • 147. 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 NOTE Configuring Ports It is assumed that both the active and standby master controllers have “onearmed” connections to distribution switches as recommended in Chapter 6. If this is not the case in your environment, this step may not be necessary. 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. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 147
  • 148. 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. NOTE 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. 5. Click Next. Figure 71 Aruba Networks, Inc. Configure the IP Address Pools for RAPs Example Configuration for the Fixed Telecommuter Scenario | 148
  • 149. 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
  • 150. 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
  • 151. 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
  • 152. 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
  • 153. 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
  • 154. 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 Aruba Networks, Inc. RAP Whitelist Example Configuration for the Fixed Telecommuter Scenario | 154
  • 155. 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: local-userdb-ap add mac-address <Remote AP Ethernet Mac Address> ap-group Fixed_Telecommuter_APGroup1 ! 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. NOTE 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. 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 add username <phone mac address> password <phone mac address> ! Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 155
  • 156. 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. NOTE 2. 3. 4. 5. If the CPE device provides voice services, it may contain a backup battery. The backup battery must also be disconnected for 10 seconds. Power up the RAP. Connect ENET0 to the upstream CPE device (DSL or cable modem). Power up the CPE device. Make sure that the network is set up such that the RAP will obtain an IP address using DHCP on this link. Make sure that no Aruba controllers are in the network where the RAP is being installed. NOTE Make sure that the RAP obtains an IP address on enet0. 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. NOTE 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) The browser will be re-directed to the RAP web page asking for the controller IP or hostname. Aruba Networks, Inc. Example Configuration for the Fixed Telecommuter Scenario | 156
  • 157. 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
  • 158. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Example Configuration for the Fixed Telecommuter Scenario | 158
  • 159. Virtual Branch Networks Validated Reference Design Chapter 10: Example Configuration for the Branch Office Scenario Historically, most branch offices have received less-sophisticated and lowerperformance 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 multidevice, 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 Office This 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-theair 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
  • 160. 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. Master Controller ge1/3 172.21.98.251 (Router configured to route 172.21.98.1 RAP IP Pool & Local to Master) 10.0.0.0 (Static Route from Local) RADIUS Enterprise 172.21.98.0/24 VLAN 98 10.168.115.130 10.168.115.128/27 VLAN 128 Alias = “ent_network” SIP Server 172.21.99.1 Voice 172.21.99.250 ge1/2 (.1Q) Local Controller 172.21.99.0/24 VLAN 99 10.168.115.162 10.168.115.160/27 VLAN 160 Alias = “voice_network” RAP IP Pool 10.168.115.225 10.168.115.239 Voice SSID Voice fe1/2 VLAN 160 Fwd Mode = Tunnel 99.99.99.00/24 VLAN 214 99.99.99.1 RAP-5WN LMSIP = 99.99.99.14 Internet or WAN fe1/0 Guest SSID Enterprise SSID fe1/1 fe1/4 192.168.177.1 192.168.177.0/24 Alias = “guest_network” VLAN 177 Fwd Mode = Bridge DHCP Start = 192.168.177.100 DHCP End = 192.168.177.254 Figure 79 Aruba Networks, Inc. Enterprise VLAN 128 Fwd Mode = Split-Tunnel Application fe1/3 10.168.115.131 RNSG_228 ge1/1 99.99.99.14 Network Design for the Branch Office Example Example Configuration for the Branch Office Scenario | 160
  • 161. Dependent Profiles - Wireless Enet1 Port Profile Enet2 Port Profile Virtual AP Profile Enet3 Port Profile Dependent Profiles - General Virtual AP Profile Virtual AP Profile AP System Profile Enet4 Port Profile AP Wired Port Profile Wired_Branch_Port_profile (Task 6A) Dependent Profiles AP Wired Port Profile Wired_Voice_Port_profile (Task 6B) Dependent Profiles AP Wired Port Profile Wired_Server_Port_profile (Task 6C) Dependent Profiles AP Wired Port Profile Wired_Guest_Port_profile (Task 6D) VAP Profile Enterprise_vap_profile (Task 5A) Dependent Profiles vlan = 128 forward-mode = split-tunnel AAA Profile AAA Profile AAA Profile AAA Profile Wired AP Profile Wired AP Profile Wired AP Profile Wired AP Profile Dependent Profiles VAP Profile Voice_vap_profile (Task 5B) VAP Profile Guest_vap_profile (Task 5C) vlan = 160 forward-mode = tunnel vlan = 177 forward-mode = bridge rap-operation = always Dependent Profiles AAA Profile AAA Profile SSID Profile SSID Profile Dependent Profiles AAA Profile SSID Profile Wired AP Profile Wired_Branch_ap_profile (Task 6A) Wired AP Profile Wired_Voice_ap_profile (Task 6B) Wired AP Profile Wired_Server_ap_profile (Task 6C) Wired AP Profile Wired_Guest_ap_profile (Task 6D) wired-ap-enable = yes forward-mode = split-tunnel switchport access vlan = 128 wired-ap-enable = yes switchport access vlan = 160 wired-ap-enable = yes forward-mode = split-tunnel switchport access vlan = 128 wired-ap-enable = yes forward-mode = bridge switchport access vlan = 177 AAA Profile Remote_Ent_aaa_profile (Task 4D) AAA Profile Wired_Voice_aaa_profile (Task 4G) AAA Profile Wired_Server_aaa_profile (Task 4F) AAA Profile Guest_aaa_profile (Task 4H) dot1x-default-role = Remote_Enterprise_user_role initial-role = denyall_user_role Dependent Profiles 802.1X Server Group 802.1X Authentication Profile dot1x-default-role = Enterprise_Voice_user_role initial-role = logon mac-default-role = Enterprise_Voice_user_role mac-server-group = internal initial-role = Remote_App_Server_user_role SSID Profile Enterprise_ssid_profile (Task 5A) essid = “Enterprise” opmode = wpa2-aes SSID Profile Voice_ssid_profile (Task 5B) essid = “Voice” opmode = wpa2-aes SSID Profile Guest_ssid_profile (Task 5C) essid = “Guest” wpa-passphrase = “arubarocks” opmode = wpa2-psk-aes AAA Profile Voice_aaa_profile (Task 4G) dot1x-default-role = Enterprise_Voice_user_role initial-role = logon initial-role = guest_user_role authentication-dot1x = default-psk Dependent Profiles 802.1X Server Group Dependent Profiles 802.1X Authentication Profile 802.1X Server Group 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 dns-domain = arubanetworks.com dns-domain = airwave.com 802.1X Authentication Profile Remote_Enterprise_dot1x (Task 4B) MAC Authentication Profile Wired_Voice_mac (Task 4C) AP Server Group RADIUS_Servers (Task 4A) Dependent Profiles AAA Authentication Server AAA Authentication Server dot1x_server1 (Task 4A) type = RADIUS host = 10.168.115.130 key = “arubasecure” Figure 80 Profile Design for the Branch Office Example RNSG_229 MAC Authentication Profile Validated Reference Design Example Configuration for the Branch Office Scenario | 161 802.1X Authentication Profile AP System Profile APGroup1_sys_profile (Tasks 7A & 7B) Virtual Branch Networks Dependent Profiles - Wired From an Aruba controller perspective, the profile design required to implement this reference model can be seen in Figure 80. Aruba Networks, Inc. AP Group Branch_Office_APGroup1 (Task 8)
  • 162. Virtual Branch Networks Validated Reference Design Configuring the Aruba Branch Office Solution The 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. Configure Local Provision & Deploy RAP RNSG_129 Configure Master Figure 81 Three steps to configure the Aruba Branch Office solution Configure the Master Controller 2. 3. 4. 5. 6. 7. 8. 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. Provide a route to the master controller. Configure the network destination, firewall policies and user roles. Configure the AAA server, AAA server group, AAA profile, and AAA authentication profiles. Configure the SSID and virtual AP profiles. Configure the wired AP and wired port profiles. Configure the AP system profile. 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 162
  • 163. 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. NOTE NOTE If it is not desirable to add a routable IP address to the Aruba controller, use an external router or firewall address and forward the traffic to an existing interface on the controller. Only NAT-T traffic (udp/4500) needs to be forwarded. If the RAPs use DNS to resolve the IP address of the DMZ controller, add the appropriate records to the DNS servers. Task 3: Configure Network Destination, Firewall Policies, and User Roles Now that the basic controller IP settings, RAP IP 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. 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 ! 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 Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 163
  • 164. Virtual Branch Networks    Validated Reference Design Syslog: udp/514 802.11 traffic inside GRE tunnels ICMP ping NOTE This simplified example configuration assumes that the local controller is inside a DMZ and is not connected directly to the Internet Use the following CLI commands, in the order listed, to create the firewall policy called RemoteAP_acl. This policy applies the rules i the same order as the bullets listed above. 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 ! 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: user-role RemoteAP_user_role session-acl RemoteAP_acl ! 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: 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 ! 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 164
  • 165. Virtual Branch Networks Validated Reference Design Use the following CLI commands to create the user role called Remote_Enterprise_user_role: user-role Remote_Enterprise_user_role session-acl Remote_Enterprise_acl ! Step 3F: Configure the Enterprise Voice Firewall Policy The Enterprise_Voice_acl policy is a security best practice that enables only the specific protocols needed by voice devices, including DNS, DHCP, HTTP, HTTPS, ICMP, NTP and TFTP. SIP traffic is allowed only to the voice server. The Enterprise_Voice_acl policy is mapped to Enterprise_Voice_user_role. We assume that the controllers have a Voice License. These ACLs also note network destination aliases that are used to group several hosts and networks together. Use the following CLI commands to create the access list Enterprise_voice_acl: 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 ! 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 Enterprise_voice_user_role session-acl Enterprise_voice_acl ! Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 165
  • 166. 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: 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 ! 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 user-role Remote_App_Server_user_role session-acl Remote_Application_Server_acl ! 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). Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 166
  • 167. 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 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 ! 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: user-role Guest_user_role session-acl Guest_acl ! 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: ip access-list session denyall_acl any any any deny ! 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:. user-role denyall_user_role session-acl denyall_acl ! 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 Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 167
  • 168. 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: aaa authentication-server radius dot1x_server1 host 10.168.115.130 key arubasecure ! aaa server-group RADIUS_Servers auth-server dot1x_server1 ! 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. NOTE 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. Use the following CLI command to create the remote enterprise 802.1X profile: aaa authentication dot1x Remote_Enterprise_dot1x ! 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 mac Wired_Voice_mac ! Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 168
  • 169. 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: 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 ! 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: aaa authentication wired profile Remote_Ent_aaa_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: aaa profile Wired_Server_aaa_profile initial-role Remote_App_Server_user_role ! 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 169
  • 170. Virtual Branch Networks Validated Reference Design Use the following CLI commands to create the wireless voice 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 ! 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: 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 ! 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: aaa profile Guest_aaa_profile initial-role Guest_user_role authentication-dot1x default-psk ! 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 170
  • 171. Virtual Branch Networks Validated Reference Design Use the following CLI commands to create the enterprise SSID and VAP (Virtual AP) profiles: wlan ssid-profile Enterprise_ssid_profile essid Enterprise opmode wpa2-aes ! wlan virtual-ap Enterprise_vap_profile aaa-profile Remote_Ent_aaa_profile ssid-profile Enterprise_ssid_profile vlan 128 forward-mode split-tunnel ! Step 5B: Create the Voice SSID and Virtual AP Profiles The Voice SSID profile is configured with 802.1X WPA2-AES. The Voice Virtual AP profile will be configured with forward mode tunnel and use VLAN 128 for its IP subnet. Use the following CLI commands to create the voice SSID and VAP profiles: 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 ! 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. NOTE Aruba Networks, Inc. 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. Example Configuration for the Branch Office Scenario | 171
  • 172. Virtual Branch Networks Validated Reference Design Use the following CLI commands to create the guest SSID and VAP 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 ! 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: 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
  • 173. 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: 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 ! 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: 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 ! 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_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
  • 174. 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). NOTE 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. Use the following CLI commands to create the AP system profiles: 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 ! 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. NOTE If a RAP DHCP DNS server is not defined, the DNS server obtained from DHCP on the uplink enet0 port will be used. 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 Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 174
  • 175. 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. ap system-profile APGroup1_sys_profile dns-domain arubanetworks.com dns-domain airwave.com ! 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: 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 ! 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 175
  • 176. 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: 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 ! 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. Aruba Networks, Inc. Example Configuration for the Branch Office Scenario | 176
  • 177. 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 Management In 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
  • 178. 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
  • 179. 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 Aruba Networks, Inc. AirWave User Detail Page Reporting and Management | 179
  • 180. 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
  • 181. 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 configurationcompliance 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
  • 182. 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 Aruba Networks, Inc. 3-D Navigation With VisualRF Reporting and Management | 182
  • 183. 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
  • 184. 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. AirWave Master Console™ NOC #1 NOC #2 AirWave Failover AirWave Failover AWMS Software AWMS Software Enterprise Site A Enterprise Site B Centralized Architecture Centralized Architecture Fixed Telecommuter Sites Branch Office Sites Figure 88 Aruba Networks, Inc. Network Fixed Telecommuter Sites Branch Office Sites RNSG_222 Network Master Console Reporting and Management | 184
  • 185. 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
  • 186. 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
  • 187. 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 Categories This chapter includes information about the following types of troubleshooting: Zero Touch Provisioning Problems Users 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 Problems This 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 Problems RAP 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 Problems The 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 Problems Problems 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 Problems Problems 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
  • 188. Virtual Branch Networks Validated Reference Design Troubleshooting Zero Touch Provisioning Problems  To 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 Aruba Networks, Inc. RAP Console Page Troubleshooting Remote Access Points | 188
  • 189. 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 Problems To 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. NOTE 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. 2. Point the browser to the following URL: http://rapconsole.arubanetworks.com The RAP Console screen opens with the Summary tab active. 3. From the Summary tab, click Advanced. Aruba Networks, Inc. Troubleshooting Remote Access Points | 189
  • 190. 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 Aruba Networks, Inc. Diagnostics Tab Troubleshooting Remote Access Points | 190
  • 191. 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. START HERE: Is output present? Enter the command: show crypto ipsec sa No See “Troubleshooting the IPsec Tunnel” Yes Does the output include an inner IP? No See “Checking the XAuth” and “Checking the IP Address Pool and Usage” Yes Figure 94 RNSG_213 See See “Troubleshooting RAP “TroubleshootingRAP Bootstrapping Problems” Bootstrapping Problems” 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 191
  • 192. Virtual Branch Networks Validated Reference Design The command output should be similar to the following: (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 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 192
  • 193. Virtual Branch Networks Validated Reference Design Figure 95 shows the sequence for troubleshooting the IPsec tunnel. START HERE: No Troubleshoot the IPsec tunnel. Did show crypto ipsec sa produce output? Yes Enter the command: show datapath session table Does the output show a NAT-T (UDP 4500) session? No See “Checking the UDP 4500 Session” Yes Enter the command: show crypto isakmp sa Does the output show a Phase 1 SA? No See “Preshared Key Mismatch” and “ISAKMP Policy Changes” Yes Enter the command: show crypto ipsec sa Does the output show a Phase 2 SA? No Contact Aruba for assistance Gather data as described in “Information for Technical Support” RNSG_214 Yes See “Checking XAuth” and “Checking the IP Address Pool and Usage” 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.) Aruba Networks, Inc. Troubleshooting Remote Access Points | 193
  • 194. 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): Source IP -------------98.234.52.200 63.82.214.206 Destination IP -------------63.82.214.206 98.234.52.200 Prot ---17 17 SPort ----33782 4500 DPort ----4500 33782 ... ... ... ... TAge ---8c8b 8c8b Flags ----FC F 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): User Role ACL Hits -----------------Role Policy --------ap-role ap-acl RemoteAP RemoteAP RemoteAP RemoteAP Src --any any any Dst --any any any Service ------svc-syslog svc-papi svc-ntp Action -----permit permit permit Dest/Opcode ----------- New Hits -------0 0 0 Total Hits ---------3 1 1 .... .... .... .... .... 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 Aruba Networks, Inc. crypto isakmp sa [peer <ip-address>] Troubleshooting Remote Access Points | 194
  • 195. Virtual Branch Networks Validated Reference Design The 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 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 This information applies only to legacy equipment running software that is earlier than the RN version. NOTE 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: 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
  • 196. 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: 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 apgroup "remote" > -- command executed successfully Jan 16 16:28:04 webui[508]: USER:admin@10.100.135.112 COMMAND:<provision-ap apname "RAP70" > -- command executed successfully 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 Aruba Networks, Inc. crypto isakmp policy Troubleshooting Remote Access Points | 196
  • 197. Virtual Branch Networks Validated Reference Design The command output should be similar to the following: 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 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 crypto terminal logging level debugging security process 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 Aruba Networks, Inc. log security all | inc ike Troubleshooting Remote Access Points | 197
  • 198. Virtual Branch Networks Validated Reference Design The command output should be similar to the following: 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 Check the IKE main mode phase lines in the command output for errors. Aruba Networks, Inc. Troubleshooting Remote Access Points | 198
  • 199. 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: 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 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): AP-entry Details ---------------Name ---00:0b:86:66:05:a1 00:0b:86:c3:58:4c 00:0b:86:c3:58:96 00:0b:86:c3:58:92 00:0b:86:c3:58:58 00:0b:86:c3:58:c0 00:0b:86:66:07:18 00:0b:86:66:02:31 AP Entries: 8 AP-Group -------Partha Fixed-Telecommuter WPA2_ONLY Fixed-Telecommuter Fixed-Telecommuter Fixed-Telecommuter branch branch Full-Name --------- . . . . . . Amit kazi chuck@home Brian (@home) Kiran Prasad Martin AP_Authenticated . . . Enabled --------------- . . .------Provisioned Yes Provisioned Yes Provisioned Yes Provisioned Yes Provisioned Yes Provisioned Yes Provisioned Yes Provisioned Yes If the RAP is missing from the whitelist, add it using the following command: (vrd-rap-local) <full name> #local-userdb-ap add mac-address <mac> ap-group <group> full-name To correct an entry that has a mistake in the MAC address or other part of the entry, use the following command: #local-userdb-ap modify mac-address <mac> ap-group <group> fullname <full name> mode [enable | disable] (vrd-rap-local) Aruba Networks, Inc. Troubleshooting Remote Access Points | 199
  • 200. 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: (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 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 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 200
  • 201. 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: 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 } ISAKMP Statistics To display ISAKMP statistics, use the following command: (vrd-rap-local) #show Aruba Networks, Inc. crypto isakmp stats Troubleshooting Remote Access Points | 201
  • 202. Virtual Branch Networks Validated Reference Design The command output should be similar to the following: Main Mode Initiator exchanges started/completed Main Mode Responder exchanges started/completed Aggr Mode Initiator exchanges started/completed Aggr Mode Responder exchanges started/completed Quick Mode Initiator exchanges started/completed Quick Mode Responder exchanges started/completed XAuth Type1 Responder exchanges started/completed XAuth Type2 Responder exchanges started/completed Mode-Config Responder exchanges started/completed Phase1 SAs Current/Max/Total Phase2 SAs Current/Max/Total VPN Sessions Total/RAPs/Master-Local/Redundancy VPN License Limits Total/Platform/Current/Violation Switch Role: CFGM triggers: Master/Local/Redund/Failed/Total Redundancy changes: Master->Standby/Standby->Master FPAPPS TX messages: Tunnel-Up/Tunnel-Down FPAPPS TX messages: cfg-map-add/cfg-map-del FPAPPS TX messages: Peer-map-add/Peer-map-del FPAPPS TX messages: SwitchIP-mapadd/SwitchIP-mapdel FPAPPS TX messages: New-SwitchIP-map-adds Datapath To Control DPD Triggers Received DPD Initiate Reqs-Sent/Re-Sent/Replies-Rcvd/Dropped DPD Responder Reqs-Rcvd/Reqs-Dropped/Replies-Sent DPD peers detected as Dead L2TP tunnel events received: Add/Delete L2TP Delete tunnel events sent: Success/Fail RAP-PSK-caching IKE SA: New-PSK/Old-PSK/Expired/Bad Garbage SA deletions: ISAKMP-SA/IPSec-SA Rcvd Cert-chain: Verified/Failed Rcvd Cert-chain error: Invalid ID and pubkey Rcvd Cert-chain error: no username(mode-cfg only) Cert-chain error in encryption/decryption Cert-manager registration: Started/Completed Cert-manager errors: Cert-Not-found/No-reply IKE To CPFW DST-NAT messages sent Control To Datapath SA Adds/Failed Adds Control To Datapath SA Deletions/Failed Deletions Datapath To Control IKE Triggers Received/Ignored Timers Current/Max/Total SA Soft timers Current/Max/Total SA Hard timers Current/Max/Total NAT-T Timers Current/Max/Total IKE Messages Current/Max/Total Message Payloads Current/Max/Total Message Timers Current/Max/Total IKE Exchanges Current/Max/Total Exchange Timers Current/Max/Total Aruba Networks, Inc. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 0/0 273/68 14/14 0/0 54/54 117/117 0/0 0/0 0/0 2/5/287 3/4/171 1/10/1/0 16777215/16777215/0/0 Local 0/1/0/0/1 0/0 1/0 0/0 1/0 0/0 0 1056 1056/0/1056/0 1140/0/1140 0 13/9 3/0 0/0/0/0 14/6 0/0 0 0 0/0 0/0 0/0 54 310/0 242/0 0/0 11/17/25180 4/4/185 5/8/316 0/0/0 0/5/7446 0/29/24588 0/2/939 0/4/5027 0/4/5027 Troubleshooting Remote Access Points | 202
  • 203. 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
  • 204. 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: Datapath Crypto Statistics -------------------------Crypto Accelerator Crypto Cores In Use Crypto Cores Total Crypto Requests Total Crypto Requests Queued Crypto Requests Failed Crypto Timeouts IPSec Encryption Failures IPSec Decryption Failures IPSec Decryption Loops IPSec Decryption BufFail IPSec Decr SPI(client) ERR IPSec Decrypt SA Not Ready ... . . Max Crypto HW Queues Crypto HW Queues Used Crypto HW Queue Alloc Fail ... . . L2TP Hellos Sent L2TP Hello Timeouts Present 2 2 1357231 0 0 0 0 0 0 0 0 0 64 15 0 69 9 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 Aruba Networks, Inc. udp 4500 Troubleshooting Remote Access Points | 204
  • 205. 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. 172 173 174 175 176 177 178 179 180 181 Time Source 17:20:15.02133498.234.52.200 17:20:15.02137963.82.214.206 17:20:15.51257898.234.52.200 17:20:15.53734963.82.214.206 17:20:15.99758998.234.52.200 17:20:16.12566963.82.214.206 17:20:16.13087898.234.52.200 17:20:16.13523163.82.214.206 17:20:16.13761198.234.52.200 17:20:16.13926463.82.214.206 NOTE Aruba Networks, Inc. Destination 63.82.214.206 98.234.52.200 63.82.214.206 98.234.52.200 63.82.214.206 98.234.52.200 63.82.214.206 98.234.52.200 63.82.214.206 98.234.52.200 Protocol ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP Info Identity Protection Identity Protection Identity Protection Identity Protection Identity Protection Identity Protection Quick Mode Quick Mode Quick Mode Quick Mode (Main (Main (Main (Main (Main (Main Mode) Mode) Mode) Mode) Mode) Mode) 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. Troubleshooting Remote Access Points | 205
  • 206. 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: 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 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: 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 Verify that the local pool has free IP addresses available. Aruba Networks, Inc. Troubleshooting Remote Access Points | 206
  • 207. Virtual Branch Networks Validated Reference Design Troubleshooting RAP Bootstrapping Problems After 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. Troubleshoot RAP bootstrapping problems. Check the VPN role policies. Check the RAP role transition. Figure 96 RNSG_218 START HERE: 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 Aruba Networks, Inc. rights RemoteAP Troubleshooting Remote Access Points | 207
  • 208. Virtual Branch Networks Validated Reference Design The command output should be similar to the following (not all fields shown): access-list List ---------------Position Name -------- ---1 RemoteAP Location -------- RemoteAP -------Priority -------1 2 3 4 5 6 Source -----any any any any any any Destination ----------any any any any any any Service ------svc-papi svc-ntp svc-syslog svc-tftp svc-ftp svc-gre Action -----permit permit permit permit permit permit . . . . Queue . . . . . . . . ------- . . . Low . . . . Low . . . Low . . . Low . . . Low . . . Low . . . Expired Policies (due to time constraints) = 0 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): (vrd-rap-local) #show Users ----IP --------172.16.118.12 98.234.52.200 user-table verbose | inc 98.234.52.200 MAC ---------00:a0:c8:1c:fe:eb 00:a0:c8:1c:fe:eb Name ---RAP01 Role ---ap-role logon Age(d:h:m) --------01:23:08 01:23:08 Auth ---VPN VPN Link --------8.234.52.200 ... ... ... ... User Entries: 2/2 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 208
  • 209. 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 (vrd-rap-local) #show ap active ip-address <l2tp-ip-address> 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): (vrd-rap-local) #show ap active ip-address 172.16.118.12 Active AP Table --------------Name Group IP Address ----- -------------RAP70 remote 172.16.118.12 11g Clients ----------0 11g Ch/EIRP/MaxEIRP . . . . AP Type ------------------- . . . . ------AP:11/1.5/33 . . . . 70 Flags ----RA Uptime -----7h:30m:42s Num APs:1 If the RAP is advertising the correct SSIDs, the command output should be similar to the following (not all fields shown): (vrd-rap-local) #show ap bss ip-address 172.16.118.12 Aruba AP BSS Table -----------------bss --00:0b:86:d9:11:70 00:0b:86:d9:11:60 ess --tunneled tunneled s/p --3/6 3/6 ip -172.16.118.12 172.16.118.12 phy --a g type ---ap ap ch/EIRP/max-EIR --------------153/21/36 11/1.5/33 P cur-cl ------0 0 ap name ------RAP70 RAP70 ... ... ... ... Num APs:2 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 Aruba Networks, Inc. rights ap-role Troubleshooting Remote Access Points | 209
  • 210. Virtual Branch Networks Validated Reference Design Verify that the system role ap-role contains the rules shown in the following command output: . . . control ------Priority -------1 2 3 4 5 6 7 8 9 Source -----user any any any any any any any any Destination ----------any any any any any any any any any Service ------udp 68 svc-icmp svc-dns svc-papi svc-cfgm-tcp svc-adp svc-tftp svc-dhcp svc-natt ap-acl -----Priority -------1 2 3 4 5 Source -----any any any user user Destination ----------any any user any any Service ------svc-gre svc-syslog svc-snmp svc-snmp-trap svc-ntp Action TimeRange Log Expired ------ --------- --- ------deny permit permit permit permit permit permit permit permit Queue .... ----- ---Low Low Low Low Low Low Low Low Low Action TimeRange Log Expired Queue .... ------ --------- --- ------- ----- ---permit Low permit Low permit Low permit Low permit Low Expired Policies (due to time constraints) = 0 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 Aruba Networks, Inc. ip access-list RemoteAP Troubleshooting Remote Access Points | 210
  • 211. 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. Priority -------1 2 3 4 5 6 Source -----any any any any any any Destination -----------any any any any any any Service ------svc-papi svc-ntp svc-syslog svc-tftp svc-ftp svc-gre Action -----permit permit permit permit permit permit TimeRange --------- Log --- Expired ------- Queue ----Low Low Low Low Low Low .... 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): (vrd-rap-local) #show User Role ACL Hits -----------------Role Policy --------logon allow-l2tp ap-role control ap-role control ap-role ap-acl ap-role ap-acl ap-role ap-acl RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP RemoteAP Aruba Networks, Inc. acl hits Src --any any any any any user any any any any any any Dst --any any any any any any any any any any any any Service ------svc-l2tp svc-icmp svc-papi svc-gre svc-syslog svc-ntp svc-dns svc-papi svc-ftp svc-syslog svc-ntp 0 Action -----permit permit permit permit permit permit permit permit permit permit permit deny Dest/Opcode ----------- New Hits -------13 5 588 11 635 15 2 19 3 2 13 2 Total Hits ---------13 5 588 11 635 15 2 19 3 2 13 2 ... --... ... ... ... ... ... ... ... ... ... ... ... Troubleshooting Remote Access Points | 211
  • 212. 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 Problems Ports 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. START HERE: Troubleshoot wired port configuration problems. Verify that the wired port has been enabled. Enter the command: show ap active or show ap bss-table or show datapath tunnel table Check the authentication profile. Enter the commands: show aaa authentication wired show aaa profile <profile-name> Figure 97 Aruba Networks, Inc. RNSG_219 Check the port profile. Enter the commands: show ap wired-ap-profile rap Troubleshooting Wired Port Configuration Problems Troubleshooting Remote Access Points | 212
  • 213. 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 ------------------------------RAP70 remote 172.16.118.12 0 Ch/EIRP/MaxEIRP... ---------------... AP:11/1.5/33 ... AP Type ------70 Flags ----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 ------- 00:0b:86:d9:11:70 tunneled 3/6 172.16.118.12 00:0b:86:d9:11:60 tunneled 3/6 172.16.118.12 00:0b:86:c5:91:17 N/A 3/6 172.16.118.12 ... phy --a g e type ---ap ap N/A ch/EIRP/max-EIRP -------------36/13/23 11/1.5/33 N/A cur-cl ---0 0 N/A ap name ------RAP70 RAP70 RAP70 in-t(s) -----0 0 0 ... ... ... ... ... Num APs:3 Num Associations:0 Aruba Networks, Inc. Troubleshooting Remote Access Points | 213
  • 214. Virtual Branch Networks Validated Reference Design (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 # 13 12 11 14 Source -----SPI03242300 in 10.100.135.97 10.100.135.97 10.100.135.97 Destination -----------63.82.214.206 172.16.118.12 172.16.118.12 172.16.118.12 Prt --50 47 47 47 Type ----IPSE 8300 8200 8100 MTU --1500 1200 1200 1200 VLAN ---0 88 88 88 Acls ---0 0 0 0 0 0 BSSID ----routeDest FFFF 1 00:0B:86:D9:11:60 1 00:0B:86:D9:11:70 0 00:00:00:00:00:00 ... ... ... ... ... ... Flags ----IMAS IMAS E 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: Wired AP profile "rap" ---------------------Parameter --------Wired AP enable Forward mode Switchport mode Access mode VLAN Trunk mode native VLAN Trunk mode allowed VLANs Trusted Broadcast Aruba Networks, Inc. Value ----Enabled tunnel access 88 1 all Not Trusted Broadcast Troubleshooting Remote Access Points | 214
  • 215. 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 #show aaa authentication wired 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 --------Initial role MAC Authentication Profile MAC Authentication Default Role MAC Authentication Server Group 802.1X Authentication Profile 802.1X Authentication Default Role 802.1X Authentication Server Group RADIUS Accounting Server Group XML API server RFC 3576 server User derivation rules Wired to Wireless Roaming SIP authentication role Aruba Networks, Inc. Value ----logon N/A guest default 8021x-wired employee radius_servers N/A N/A N/A N/A Disabled N/A Troubleshooting Remote Access Points | 215
  • 216. Virtual Branch Networks Validated Reference Design Troubleshooting Split-Tunnel Mode Problems Figure 98 shows an overview of how to troubleshoot problems with split-tunnel mode configuration. START HERE: Troubleshoot split-tunnel mode configuration problems. Check the user table. Enter the command: show user-table Verify that the split-tunnel SSID is active on the RAP. Enter the command: show ap bss-table ap-name <ap-name> Verify that a GRE tunnel exists for the SSID with 802.1X authentication. Enter the command: show ap datapath tunnel table Verify that the client can associate to the SSID. Enter the command: show ap debug client-table ap-name <ap-name> Verify that the client received a DHCP address. Enter the command: C:>ipconfig/all Figure 98 RNSG_220 Verify that the client succeeded with 802.1X authentication. Enter the command: show dot1x supplicant-info list all 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.  Aruba Networks, Inc. Troubleshooting Remote Access Points | 216
  • 217. 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
  • 218. 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: (vrd-rap-local) #show ap bss-table ap-name RAP70 Aruba AP BSS Table -----------------bss ess ----00:0b:86:d9:11:73 split-8021x s/p --3/6 ip phy type ch/EIRP/max-EIRP ---- ---- ---------------172.16.118.12 a ap 153/19/36 cur-cl ap name ... ------ ------- ... 1 RAP70 ... 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: (vrd-rap-local) #show datapath tunnel table Datapath Tunnel Table Entries ----------------------------# --13 Source -------------10.100.135.97 Destination Prt Type MTU VLAN Acls -------------- --- ---- ---- ---- -------------172.16.118.12 47 8230 1200 21 0 0 59 BSSID .... ----------------- .... 00:0B:86:D9:11:73 .... 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> Aruba Networks, Inc. Troubleshooting Remote Access Points | 218
  • 219. 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). (vrd-rap-local) #show ap debug client-table ap-name rap70 Client Table -----------MAC --00:13:02:20:4b:43 ESSID ----split-8021x BSSID ----00:0b:86:d9:11:73 Assoc_State ----------Associated HT_State -------None AID --0x1 PS_State -------Awake .... .... .... 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 dot1x supplicant-info list-all 802.1x User Information ----------------------MAC Name ------00:13:02:20:4b:43 jsmith Auth ---Yes AP-MAC Enc-Key/Type ... ----------------... 00:0b:86:d9:11:73 * * * * */WPA2-AES ... EAP-Type -------EAP-PEAP Remote -----Yes If 802.1X authentication has failed (Auth = No), check the output of #show auth-tracebuf count 40 for further hints. Aruba Networks, Inc. Troubleshooting Remote Access Points | 219
  • 220. 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 Jan 23 15:28:38 wpa2-key1 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 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 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 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 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 Jan 23 15:28:38 eap-mschap-response -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 mschap-request -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 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 Jan 23 15:28:38 station-data-ready * 00:13:02:20:4b:43 00:00:00:00:00:00 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 Jan 23 15:28:38 eap-tlv-rslt-success -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 eap-success <- 00:13:02:20:4b:43 00:0b:86:d9:11:73/8021x-term Jan 23 15:28:38 wpa2-key1 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 wpa2-key2 -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 wpa2-key3 <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 wpa2-key4 -> 00:13:02:20:4b:43 00:0b:86:d9:11:73 Jan 23 15:28:38 rem-ap-setkey <- 00:13:02:20:4b:43 00:0b:86:d9:11:73 wpa aes Aruba Networks, Inc. - - 21 117 - 21 - 61 - - 35 - 6 6 67 49 - - - 21 - 83 43 2 4 117 119 151 95 16 Troubleshooting Remote Access Points | 220
  • 221. 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 splittunnel virtual-ap. C:>ipconfig /all Ethernet adapter Wireless Network Connection 7: Connection-specific DNS Suffix Description . . . . . . . . . . Physical Address. . . . . . . . Dhcp Enabled. . . . . . . . . . Autoconfiguration Enabled . . . IP Address. . . . . . . . . . . Subnet Mask . . . . . . . . . . Default Gateway . . . . . . . . DHCP Server . . . . . . . . . . DNS Servers . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : atac.net Intel(R) PRO/Wireless 3945ABG Network Connection 00-13-02-20-4B-43 Yes Yes 10.168.21.254 255.255.255.0 10.168.21.1 10.168.21.1 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 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 #show #show #show datapath user ap-name <ap_name> table datapath session ap-name <ap_name> table datapath bridge ap-name <ap_name> table acl acl-table <acl_id> Aruba Networks, Inc. Troubleshooting Remote Access Points | 221
  • 222. 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 -192.168.117.182 10.168.21.254 0.0.0.0 MAC --00:0B:86:C5:91:16 00:13:02:20:4B:43 00:13:02:20:4B:43 ACLs ---2700/0 56/0 56/0 Contract -------0/0 0/0 0/0 Location -------2 2 2 Age --0 0 0 Sessions -------1/65535 2/65535 0/65535 Flags ---P <-- Remote user P (vrd-rap-local) #show acl acl-table 56 AclTable -------ACL Type --- ---56 role Aruba Networks, Inc. ACE Index --------327 Ace Count --------7 Name ---split-role Applied ------<-- Default dot1x role 0 Troubleshooting Remote Access Points | 222
  • 223. Virtual Branch Networks Validated Reference Design (vrd-rap-local) #show datapath session ap-name RAP70 table Datapath Session Table Entries -----------------------------Flags: F D H C I - fast age, S - src NAT, N - dest NAT deny, R - redirect, Y - no syn high prio, P - set prio, T - set ToS client, M - mirror, V - VOIP Deep inspect, U - Locally destined Source IP Destination IP ---------------------10.168.21.254 10.100.135.12 00:0B:86:C5:91:16 10.100.135.12 192.168.117.182 63.82.214.206 192.168.117.182 10.1.1.50 10.168.21.254 10.168.21.254 10.1.1.50 10.1.1.50 10.168.21.254 10.168.21.254 10.1.1.50 10.1.1.50 10.168.21.254 10.168.21.254 10.1.1.50 192.168.117.182 63.82.214.206 10.1.1.50 10.168.21.254 10.168.21.254 10.1.1.50 Prot ---6 0806 6 17 1 1 1 1 1 1 17 1 1 SPort DPort ----- ----1272 22 22 4500 2304 2304 2048 2048 2816 2816 4500 2560 2560 1272 4500 0 2048 0 2048 0 2048 4500 0 2048 Cntr ---0 0 0 0 0 0 0 0 0 0 0 0 0 Prio ---0 0 0 0 0 0 0 0 0 0 0 0 0 ToS --0 0 0 0 0 0 0 0 0 0 0 0 0 Age --1 0 0 0 0 0 0 0 0 0 0 0 0 Destination ----------local local local local dev12 dev12 dev12 dev12 dev12 dev12 local dev12 dev12 TAge ---7a 1a 7a f77c d d 12 12 3 3 f77c 8 8 Flags ----<-- SSH SRC session F N F FI FYCI <-- Ping to corporate FI IP FYCI FI FYCI FC FI FYCI The command output from show datapath session indicates that the SSH connection to noncorporate 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 bridge ap-name RAP70 table Datapath Bridge Table Entries ----------------------------Flags: P - Permanent, D - Deny, R - Route, M - Mobile, X - Xsec MAC ----------------00:13:02:20:4B:43 00:10:DB:5B:C0:22 00:0B:86:00:F3:20 00:0B:86:C5:91:16 Aruba Networks, Inc. VLAN ---21 1 21 1 Assigned VLAN ------------21 1 21 1 Destination ----------dev12 dev4 dev7 local Flags ----< User MAC address < Default gateway MAC address < Controller MAC address P < RAP Enet0 port MAC address Troubleshooting Remote Access Points | 223
  • 224. Virtual Branch Networks Validated Reference Design The following example shows the controller access list called split-acl: (vrd-rap-local) #show netdestination corp corp ---Position -------1 2 3 4 Type ---network network network network IP addr ------10.1.1.0 10.100.101.0 10.100.105.0 10.168.21.0 Mask/Range ---------255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 (vrd-rap-local) #show ip access-list split-acl split-acl --------Priority -------1 2 3 Source -----any any any Destination Service Action TimeRange Log Expired ----------- -------------------- --- ------any svc-dhcp permit corp any permit any any route src-nat Queue ----Low Low Low TOS --- .... .... Access-list split-acl downloaded to the RAP: (vrd-rap-local) #show datapath acl 56 ap-name RAP70 Datapath ACL 52 Entries ----------------------Flags: P S I A - permit, L - log, E - established, M/e - MAC/etype filter SNAT, D - DNAT, R - redirect, r - reverse redirect m - Mirror Invert SA, i - Invert DA, H - high prio, O - set prio 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 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 224
  • 225. 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. C:>tracert -d 10.100.135.12 Tracing route to 10.100.135.12 over a maximum of 30 hops 1 2 3 4 * 1 ms 2 ms 3 ms * 1 ms 2 ms 2 ms * 1 ms 2 ms 1 ms Request timed out. 192.168.117.1 98.234.52.193 10.100.135.12 <-- RAP local network gateway Trace complete. In the following example, host 10.100.105.243 belongs to the corporate network and therefore should match the rule any corp any permit. C:>tracert -d 10.100.105.243 Tracing route to 10.100.105.243 over a maximum of 30 hops 1 2 3 * 3 ms 22 ms * 2 ms 3 ms * 2 ms 3 ms Request timed out. 10.100.101.254 10.100.105.243 <-- Controller default gateway Trace complete. Troubleshooting Bridge Mode Problems To 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 Aruba Networks, Inc. Troubleshooting Remote Access Points | 225
  • 226. 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. START HERE: Troubleshoot bridge mode configuration problems. Check the user table. Enter the command: show user-table Verify that the bridge SSID is active on the RAP. Enter the command: show ap bss-table ap-name <ap-name> Verify that a GRE tunnel exists for the SSID with 802.1X authentication. Enter the command: show ap datapath tunnel table Verify that the client can associate to the SSID. Enter the command: show ap debug client-table ap-name <ap-name> Verify that the client received a DHCP address. Enter the command: C:>ipconfig/all Figure 99 RNSG_223 Verify that the client succeeded with 802.1X authentication. Enter the command: show dot1x supplicant-info list all 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 Aruba Networks, Inc. Troubleshooting Remote Access Points | 226
  • 227. 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 --00:0b:86:d9:11:70 00:0b:86:d9:11:71 Aruba Networks, Inc. ess --bridge8021x bridge-psk s/p --3/6 3/6 ip -172.16.118.12 172.16.118.12 phy --a a type ---ap ap ch/EIRP/max-EIRP ---------------153/16/36 153/16/36 cur-cl -----1 0 ap name ------RAP70 RAP70 ... ... ... ... Troubleshooting Remote Access Points | 227
  • 228. 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: (vrd-rap-local) #show datapath tunnel table Datapath Tunnel Table Entries ----------------------------# Source --- -----20 10.100.135.97 Destination ----------172.16.118.12 Prt Type ---- ---47 8200 MTU --1200 VLAN ---1 Acls ---0 0 59 BSSID .... ----.... 00:0B:86:D9:11:70 .... 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). (vrd-rap-local) #show ap debug client-table ap-name rap70 Client Table -----------MAC --00:13:02:20:4b:43 ESSID ----bridge8021x BSSID ----00:0b:86:d9:11:70 Assoc_State ----------Associated HT_State -------None AID --0x1 PS_State .... -------- .... Awake.... 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 dot1x supplicant-info list-all 802.1x User Information ----------------------MAC Name -----00:13:02:20:4b:43 jsmith Aruba Networks, Inc. Auth ---Yes AP-MAC Enc-Key/Type ----------------00:0b:86:d9:11:70* * * * */WPA2-AES ... ... EAP-Type -------EAP-PEAP Remote -----Yes Troubleshooting Remote Access Points | 228
  • 229. 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. C:>ipconfig /all Ethernet adapter Wireless Network Connection 7: Connection-specific DNS Suffix Description . . . . . . . . . . Physical Address. . . . . . . . Dhcp Enabled. . . . . . . . . . Autoconfiguration Enabled . . . IP Address. . . . . . . . . . . Subnet Mask . . . . . . . . . . Default Gateway . . . . . . . . DHCP Server . . . . . . . . . . DNS Servers . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : Intel(R) PRO/Wireless 3945ABG Network Connection 00-13-02-20-4B-43 Yes Yes 192.168.117.152 255.255.255.0 192.168.117.1 192.168.117.1 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 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 #show #show #show datapath user ap-name <ap_name> table datapath session ap-name <ap_name> table datapath bridge ap-name <ap_name> table acl acl-table <acl_id> Aruba Networks, Inc. Troubleshooting Remote Access Points | 229
  • 230. 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 --------------192.168.117.182 192.168.117.152 0.0.0.0 MAC ----------------00:0B:86:C5:91:16 00:13:02:20:4B:43 00:13:02:20:4B:43 ACLs ------2700/0 52/0 52/0 Contract --------0/0 0/0 0/0 Location -------2 2 2 Age --0 3 0 Sessions --------1/65535 0/65535 0/65535 Flags ----P <-- Remote user P (vrd-rap-local) #show acl acl-table 52 AclTable -------ACL Type --- ---52 role ACE Index --------277 Ace Count --------3 Name ---authenticated Applied ------0 <-- Default dot1x role (vrd-rap-local) #show datapath session ap-name RAP70 table Datapath Session Table Entries -----------------------------Source IP Destination IP -------------- -------------00:13:02:20:4B:43 00:0B:86:C5:91:16 192.168.117.152 10.100.135.94 10.100.135.94 192.168.117.152 63.82.214.206 192.168.117.182 192.168.117.182 63.82.214.206 Aruba Networks, Inc. Prot ---0806 0806 6 6 17 17 SPort DPort ----- ----- 1508 23 4500 4500 23 1508 4500 4500 Cntr ---0 0 0 0 0 0 Prio ---0 0 0 0 0 0 ToS --0 0 0 0 0 0 Age --0 0 1 1 0 0 Destination ----------dev12 local dev12 dev12 local local TAge ---3f 19 3f 3f b97a b97a Flags ----F F Telnet <--session C <-- RAP F NAT-T FC session Troubleshooting Remote Access Points | 230
  • 231. 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 ----------------00:13:02:20:4B:43 00:10:DB:5B:C0:22 00:0B:86:C5:91:16 VLAN ---1 1 1 Assigned VLAN ------------1 1 1 Destination ----------dev12 dev4 local Flags ----<-- User MAC address P <-- Default gateway MAC address (vrd-rap-local) #show datapath acl 52 ap-name RAP70 Datapath ACL 52 Entries ----------------------Flags: P S I A - permit, L - log, E - established, M/e - MAC/etype filter SNAT, D - DNAT, R - redirect, r - reverse redirect m - Mirror Invert SA, i - Invert DA, H - high prio, O - set prio 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
  • 232. 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: (vrd-rap-local) # show ap bss-table Aruba AP BSS Table -----------------bss ess s/p ------00:0b:86:d9:11:70 bridge8021x 3/6 00:0b:86:d9:11:71 bridge-psk 3/6 ip -172.16.118.12 172.16.118.12 phy --a a type ch/EIRP/max-EIRP ---- ---------------ap 153/21/36 ap 153/21/36 cur-cl -----0 1 ap name ... ------- ... RAP70 RAP70 ... (vrd-rap-local) #show datapath tunnel table Datapath Tunnel Table Entries ----------------------------# 20 Source -----10.100.135.97 Destination ----------172.16.118.12 Prt --47 Type ---8200 MTU ---1200 VLAN ---1 Acls ---------0 0 59 BSSID ----00:0B:86:D9:11:70 ... ... ... 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 lowend 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. Aruba Networks, Inc. Troubleshooting Remote Access Points | 232
  • 233. Virtual Branch Networks Validated Reference Design For example: (vrd-rap-local) #show ap-group remote AP group "remote" ----------------Parameter --------Virtual AP Virtual AP …. AP system profile …. Value ----bridge8021x-vap bridge-psk-vap default (vrd-rap-local) #show wlan virtual-ap bridge8021x-vap Virtual AP profile "bridge8021x-vap" -----------------------------------Parameter --------Virtual AP enable Allowed band SSID Profile VLAN Forward mode ….. Value ----Enabled all bridge8021x 1 bridge (vrd-rap-local) #show ap system-profile default AP system profile "default" --------------------------Parameter --------LMS IP Backup LMS IP LMS Preemption LMS Hold-down Period Master controller IP address LED operating mode (AP-12x only) RF Band Double Encrypt Native VLAN ID … Aruba Networks, Inc. Value ----N/A N/A Disabled 600 sec N/A normal g Disabled 1 Troubleshooting Remote Access Points | 233
  • 234. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Troubleshooting Remote Access Points | 234
  • 235. 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
  • 236. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Forwarding Mode Feature Matrix | 236
  • 237. 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 Device Product & Vendor ID Provisioning Parametersa ISP Model 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# 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) 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 Sprint Verizon Aruba Networks, Inc. Provisioning Parameters for Verified USB Modems | 237
  • 238. Virtual Branch Networks Table 17 Validated Reference Design 3G Modem Configuration Settings by Carrier (Continued) ISP Model Device Product & Vendor ID 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# Provisioning Parametersa a. Console equivalents in brackets. Use the numbers if you are directly provisioning from console. Aruba Networks, Inc. Provisioning Parameters for Verified USB Modems | 238
  • 239. Virtual Branch Networks Validated Reference Design Appendix C: Requirements Worksheets Table 18 Facility Inventory Worksheet Example Usage Requirements WLAN Link Requirements Provisioni ng Facility Type Site Count Max Devices Per Site Guests Family Existing or New Link Type Speed Latency Provisioning Method Fixed Telecommuters Remote Call Center Agents Small Branch Offices Medium Branch Offices Aruba Networks, Inc. Requirements Worksheets | 239
  • 240. Virtual Branch Networks Table 19 Validated Reference Design Site Template—Medium Branch Office Example Forecast Description Max Devices (Today) Max Devices (5 Years) Logical & Security Design Connection Method Wireless Wired Interface 2.4 GHz 5 GHz Auth Mode Forwarding Operating Mode Mode DHCP Source Enterprise Devices Guest Devices Total Devices Aruba Networks, Inc. Requirements Worksheets | 240
  • 241. Virtual Branch Networks Table 20 Validated Reference Design Site Template—Fixed Telecommuter Example Forecast Description Max Devices (Today) Max Devices (5 Years) Logical & Security Design Connection Method Wireless Wired Interface 2.4 GHz 5 GHz Auth Mode Forwarding Operating Mode Mode DHCP Source Enterprise Devices Family Devices Total Devices Aruba Networks, Inc. Requirements Worksheets | 241
  • 242. Virtual Branch Networks Table 21 Validated Reference Design Remote Access Point (RAP) Requirement Worksheet Example Facility Type Local Wired Ports USB Required Wireless Required Radio Regulator y 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
  • 243. 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 Summary The 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-theair 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
  • 244. Virtual Branch Networks Validated Reference Design Annotation Conventions The configuration files shown on the following pages in this appendix include annotations that use the following conventions: 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. NOTE Aruba Networks, Inc. Configuration statements on the local controller may not appear in the same order as the configuration statements on the master controller. Sample Configuration Files for Fixed Telecommuter Example | 244
  • 245. version 3.3 enable secret "ab179448018755fe8d4c65ce725f0dc909af01de4cea59619d" hostname "RN_Local_1" clock summer-time PDT recurring 2 sunday march 02:00 first sunday november 02:00 -7 clock timezone PST -8 location "Building1.floor1" mms config 0 controller config 159 clock timezone PST -8 masterip 172.21.98.251 ipsec 2bf269fb88b3cfc7bfcbe0917a73e8220c12fea36ce56c51 location "Building1.floor1" mms config 0 Step 1C: Specify Basic controller config 159 Controller Information on ip access-list eth validuserethacl page 143 in Complete the permit any Base Configuration of the ! Local Controller (Chapter 9) netservice svc-snmp-trap udp 162 netservice svc-dhcp udp 67 68 netservice svc-smb-tcp tcp 445 netservice svc-https tcp 443 Step 1F: Configure netservice svc-ike udp 500 Connectivity to netservice svc-l2tp udp 1701 Local Controllers on netservice svc-syslog udp 514 netservice svc-pptp tcp 1723 page 122 in Complete the netservice svc-telnet tcp 23 Base Configuration of the netservice svc-sccp tcp 2000 Local Controller (Chapter 9) netservice svc-tftp udp 69 netservice svc-sip-tcp tcp 5060 netservice svc-kerberos udp 88 netservice svc-pop3 tcp 110 netservice svc-adp udp 8200 netservice svc-cfgm-tcp tcp 8211 netservice svc-noe udp 32512 netservice svc-http-proxy3 tcp 8888 netservice svc-dns udp 53 netservice svc-msrpc-tcp tcp 135 139 netservice svc-rtsp tcp 554 netservice svc-http tcp 80 netservice svc-vocera udp 5002 netservice svc-h323-tcp tcp 1720 netservice svc-h323-udp udp 1718 1719 netservice svc-nterm tcp 1026 1028 netservice svc-sip-udp udp 5060 netservice svc-http-proxy2 tcp 8080 netservice svc-papi udp 8211 netservice svc-noe-oxo udp 5000 alg noe netservice svc-ftp tcp 21 netservice svc-natt udp 4500 netservice svc-svp 119 netservice svc-gre 47 netservice svc-smtp tcp 25 netservice svc-smb-udp udp 445 netservice svc-sips tcp 5061 netservice svc-esp 50 netservice svc-bootp udp 67 69 netservice svc-snmp udp 161 netservice svc-v6-dhcp udp 546 547 netservice svc-icmp 1 ip access-list eth validuserethacl permit any ! netservice svc-snmp-trap udp 162 netservice svc-syslog udp 514 netservice svc-l2tp udp 1701 netservice svc-ike udp 500 netservice svc-https tcp 443 netservice svc-smb-tcp tcp 445 netservice svc-dhcp udp 67 68 netservice svc-pptp tcp 1723 netservice svc-sccp tcp 2000 netservice svc-telnet tcp 23 netservice svc-sip-tcp tcp 5060 netservice svc-tftp udp 69 netservice svc-kerberos udp 88 netservice svc-http-proxy3 tcp 8888 netservice svc-noe udp 32512 netservice svc-cfgm-tcp tcp 8211 netservice svc-adp udp 8200 netservice svc-pop3 tcp 110 netservice svc-rtsp tcp 554 netservice svc-msrpc-tcp tcp 135 139 netservice svc-dns udp 53 netservice svc-h323-udp udp 1718 1719 netservice svc-h323-tcp tcp 1720 netservice svc-vocera udp 5002 netservice svc-http tcp 80 netservice svc-http-proxy2 tcp 8080 netservice svc-sip-udp udp 5060 netservice svc-nterm tcp 1026 1028 netservice svc-noe-oxo udp 5000 alg noe netservice svc-papi udp 8211 netservice svc-natt udp 4500 netservice svc-ftp tcp 21 netservice svc-svp 119 netservice svc-smtp tcp 25 netservice svc-gre 47 netservice svc-sips tcp 5061 netservice svc-smb-udp udp 445 netservice svc-esp 50 netservice svc-v6-dhcp udp 546 547 netservice svc-snmp udp 161 netservice svc-bootp udp 67 69 netservice svc-msrpc-udp udp 135 139 netservice svc-ntp udp 123 netservice svc-icmp 1 Step 1C: Specify Basic Controller Information on page 119 in Complete the Base Configuration of the Master Controller (Chapter 9) Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 245 Active-Local Configuration version 3.3 enable secret "a2f880da01f5b8f25832437b2a6e58b327f085c49b8c456231" hostname "RN_Master" clock summer-time PDT recurring 2 sunday march 02:00 first sunday november 02:00 -7 Virtual Branch Networks Aruba Networks, Inc. Active-Master Configuration
  • 246. svc-ntp udp 123 svc-msrpc-udp udp 135 139 svc-ssh tcp 22 svc-http-proxy1 tcp 3128 svc-v6-icmp 58 netdestination family_network network 192.168.177.0 255.255.255.0 ! netdestination ent_network Step 3A: Configure Network network 10.0.0.0 255.0.0.0 Destination Aliases on ! page 130 (Chapter 9) 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 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 Step 3F: Configure the user any svc-https dst-nat 8081 user any svc-http-proxy1 dst-nat 8088 Enterprise Voice Firewall user any svc-http-proxy2 dst-nat 8088 Policy on page 132 user any svc-http-proxy3 dst-nat 8088 (Chapter 9) ! ip access-list session allowall any any any permit ! netdestination family_network network 192.168.177.0 255.255.255.0 ! netdestination ent_network network 10.0.0.0 255.0.0.0 ! Pushed from master 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 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 Pushed from master 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 ! Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 246 netservice netservice netservice netservice netservice Virtual Branch Networks Aruba Networks, Inc. netservice svc-ssh tcp 22 netservice svc-v6-icmp 58 netservice svc-http-proxy1 tcp 3128
  • 247. Pushed from master Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 247 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 sip-acl any any svc-sip-udp permit queue high any any svc-sip-tcp permit queue high ! 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 ! 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 dst-nat 8081 ! ip access-list session dhcp-acl any any svc-dhcp permit ! ip access-list session http-acl any any svc-http permit ! Virtual Branch Networks Aruba Networks, Inc. ip access-list session RemoteAP_acl any any svc-papi permit any any svc-tftp permit Step 3B: Configure RAP Firewall any any svc-ftp permit Policy on page 130 (Chapter 9) 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 Step 3D: Configure any any svc-dhcp permit Remote Enterprise user alias ent_network any permit Firewall Policy on alias ent_network user any permit page 131 user network 224.0.0.0 255.0.0.0 any permit (Chapter 9) 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 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 !
  • 248. Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 248 ip access-list session denyall_acl Pushed from master 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 Pushed from master ! ipv6 access-list session v6-dhcp-acl any any svc-v6-dhcp permit ! ipv6 access-list session v6-dns-acl 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 81f23b325c68183224ee6c69dcfdfa3bdd120d6115b6097c ! Virtual Branch Networks Aruba Networks, Inc. ip access-list session denyall_acl Step 3J: Configure the Block All any any any deny Firewall Policy on page 133 ! (Chapter 9) 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 ! Step 3H: Configure the Family ipv6 access-list session v6-https-acl Firewall Policy on page 132 any any svc-https permit (Chapter 9) ! ipv6 access-list session v6-dhcp-acl any any svc-v6-dhcp permit ! ipv6 access-list session v6-dns-acl 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 !
  • 249. Step 3C: Configure the RAP User Role on page 131 (Chapter 9) 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) Pushed from master Pushed from master Pushed from master Pushed from master Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 249 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 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 Virtual Branch Networks Aruba Networks, Inc. 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 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
  • 250. Step 1E: Configure the VLAN and IP Interfaces on page 120 in Complete the Base Configuration of the Master Controller (Chapter 9) Step 1F: Configure Connectivity to Local Controllers on page 122 in Complete the Base Configuration of the Master 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-caching no crypto-local isakmp permit-invalid-cert crypto ipsec transform-set default-aes esp-aes256 esp-sha-hmac crypto dynamic-map default-dynamicmap 10000 set transform-set default-transform default-aes ! user-role Enterprise_voice_user_role session-acl Enterprise_voice_acl ! aaa pubcookie-authentication ! no spanning-tree interface mgmt shutdown ! vlan 99 vlan 128 vlan 160 vlan 214 Pushed from master interface gigabitethernet 1/0 description "GE1/0" trusted ! interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 214 ! interface gigabitethernet 1/2 description "GE1/2" trusted switchport mode trunk switchport 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.255.0 description "ControllerNet" ! interface vlan 128 ip address 10.168.115.129 255.255.255.224 description "EnterpriseNet" ! interface vlan 160 ip address 10.168.115.161 255.255.255.224 description "VoiceNet" ! interface vlan 214 ip address 99.99.99.14 255.255.255.224 description "PublicNet" ! ip default-gateway 99.99.99.1 ip route 172.21.98.0 255.255.255.0 172.21.99.1 wms general poll-interval 60000 general poll-retries 3 general ap-ageout-interval 30 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) Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 250 interface gigabitethernet 1/0 description "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" trusted switchport mode trunk switchport trunk allowed vlan 98 ! interface vlan 1 ! interface vlan 98 ip address 172.21.98.251 255.255.255.0 description "ControllerNet" ! ip default-gateway 172.21.98.1 Step 3G: Configure the Enterprise Voice User Role on page 132 (Chapter 9) Virtual Branch Networks Aruba Networks, Inc. ! user-role Enterprise_voice_user_role session-acl Enterprise_voice_acl ! aaa pubcookie-authentication ! no spanning-tree interface mgmt shutdown ! vlan 98
  • 251. localip 0.0.0.0 ipsec 5c7e58d5d3946dfe00e88daf8c98cf2225dd5fdb8c41b8a2 crypto isakmp groupname changeme crypto-local isakmp dpd idle-timeout 22 retry-timeout 2 retry-attempts 3 crypto-local isakmp xauth crypto-local isakmp sa-cleanup crypto-local ipsec sa-cleanup vpdn group l2tp ppp authentication PAP ! vpdn group pptp ppp authentication MSCHAPv2 ! mux-address 0.0.0.0 adp discovery enable adp igmp-join enable adp igmp-vlan 0 ssh mgmt-auth username/password mgmt-user admin root e2e4e10901f4041bd8e2b8875f192b4943352b29ee45088088 sta-ageout-interval 30 learn-ap disable persistent-known-interfering enable propagate-wired-macs enable stat-update enable collect-stats disable ! crypto isakmp policy 20 encryption aes256 ! no crypto isakmp psk-caching no crypto-local isakmp permit-invalid-cert crypto ipsec transform-set default-aes esp-aes256 esp-sha-hmac crypto dynamic-map default-dynamicmap 10000 set transform-set default-transform default-aes ! crypto isakmp groupname changeme crypto-local isakmp dpd idle-timeout 22 retry-timeout 2 retry-attempts 3 crypto-local isakmp xauth crypto-local isakmp sa-cleanup crypto-local ipsec sa-cleanup ip local pool "RAP_Pool_1" 10.168.115.225 10.168.115.239 vpdn group l2tp ppp authentication PAP ! Step 1H: Configure the IP vpdn group pptp Address Pools on page 148 in ppp authentication MSCHAPv2 ! Complete the Base Configuration of the Local mux-address 0.0.0.0 Controller (Chapter 9) ip mobile domain default ! ssh mgmt-auth username/password mgmt-user admin root 3c309af301820a67bfb615260fb209b44b097557051f947d23 ip igmp ! no database synchronize database synchronize rf-plan-data packet-capture-defaults tcp disable udp disable sysmsg disable other disable ! Step 4C: Create the Wired Voice MAC ip domain lookup Authentication Profile on page 134 ! (Chapter 9) mac "default" mac "Wired_Voice_mac" dot1x "default" dot1x "Remote_Enterprise_dot1x" Step 4B: Create the Shared 802.1X Authentication Profile on page 134 (Chapter 9) ip mobile domain default ! ip igmp ! packet-capture-defaults tcp disable udp disable sysmsg disable other disable ! ip domain lookup ! country US Pushed from master aaa authentication mac "default" ! aaa authentication mac "Wired_Voice_mac" ! aaa authentication dot1x "default" ! aaa authentication dot1x "Remote_Enterprise_dot1x" ! Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 251 adp discovery enable adp igmp-join enable adp igmp-vlan 0 no database synchronize database synchronize rf-plan-data country US aaa authentication ! aaa authentication ! aaa authentication ! aaa authentication ! general general general general general general Virtual Branch Networks Aruba Networks, Inc. !
  • 252. Pushed from master Pushed from master Pushed from master Pushed from master Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 252 aaa authentication-server radius "dot1x_server1" host 10.168.115.130 key daa65ef2d5ec725ee054ecc09fc6a0d58b721e5d2631163f ! 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 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" ! Virtual Branch Networks Aruba Networks, Inc. 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 ! Step 4A: Create a Server for 802.1X aaa server-group "RADIUS_Servers" Authentication on page 133 (Chapter 9) auth-server dot1x_server1 ! aaa profile "default" ! aaa profile "Family_aaa_profile" Step 4G: Create the Family AAA initial-role "Family_user_role" Profile on page 136 (Chapter 9) authentication-dot1x "default-psk" ! aaa profile "Remote_Ent_aaa_profile" Step 4D: Create initial-role "denyall_user_role" the Enterprise authentication-dot1x "Remote_Enterprise_dot1x" AAA Profile on dot1x-default-role "Remote_Enterprise_user_role" page 134 dot1x-server-group "RADIUS_Servers" (Chapter 9) ! aaa profile "Voice_aaa_profile" authentication-dot1x "Remote_Enterprise_dot1x" dot1x-default-role "Enterprise_voice_user_role" Step 4F: Create dot1x-server-group "RADIUS_Servers" the Wired and ! Wireless Voice aaa profile "Wired_Voice_aaa_profile" authentication-mac "Wired_Voice_mac" AAA Profiles on mac-default-role "Enterprise_voice_user_role" page 135 mac-server-group "internal" (Chapter 9) 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 mgmt ! aaa authentication stateful-dot1x Step 4E: Create the Global Wired ! aaa authentication wired Authentication Profile on page 135 profile "Remote_Ent_aaa_profile" (Chapter 9) ! web-server ! ap system-profile "APGroup1_sys_profile" lms-ip 99.99.99.1 Step 7A: Create the AP rap-dhcp-server-vlan 177 System Profile on page 140 rap-dhcp-server-id 192.168.177.1 (Chapter 9) rap-dhcp-default-router 192.168.177.1 rap-dhcp-pool-start 192.168.177.100 rap-dhcp-pool-end 192.168.177.254 Step 7B: DNS Proxy for Split-Tunnel dns-domain "arubanetworks.com" SSID (Optional) on page 140 dns-domain "airwave.com" ! (Chapter 9)
  • 253. ! ap wired-port-profile "Wired_Voice_port_profile" wired-ap-profile "Wired_Voice_ap_profile" aaa-profile "Wired_Voice_aaa_profile" Step 6B: Create the Voice Wired AP and Port Profiles (Port 2) on page 139 (Chapter 9) Pushed from master Pushed from master Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 253 wired-ap-profile "Wired_Family_ap_profile" aaa-profile "Family_aaa_profile" 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 5valid-11g-40mhz-channel-pair 7+ valid-11g-40mhz-channel-pair 11valid-11a-40mhz-channel-pair 36+ valid-11a-40mhz-channel-pair 40valid-11a-40mhz-channel-pair 44+ valid-11a-40mhz-channel-pair 48valid-11a-40mhz-channel-pair 149+ valid-11a-40mhz-channel-pair 153valid-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 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" Virtual Branch Networks Aruba Networks, Inc. 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 5valid-11g-40mhz-channel-pair 7+ valid-11g-40mhz-channel-pair 11valid-11a-40mhz-channel-pair 36+ valid-11a-40mhz-channel-pair 40valid-11a-40mhz-channel-pair 44+ valid-11a-40mhz-channel-pair 48Step 6A: Create the valid-11a-40mhz-channel-pair 149+ valid-11a-40mhz-channel-pair 153Enterprise Wired AP and valid-11a-40mhz-channel-pair 157+ Port Profiles (Port 1) on valid-11a-40mhz-channel-pair 161page 138 (Chapter 9) ! ap wired-ap-profile "default" ! ap wired-ap-profile "Wired_Ent_ap_profile" wired-ap-enable Step 6C: Create the forward-mode split-tunnel Family Wired AP and Port switchport access vlan 128 Profiles (Ports 3 and 4) on ! page 139 (Chapter 9) ap wired-ap-profile "Wired_Family_ap_profile" wired-ap-enable forward-mode bridge switchport access vlan 177 Step 6B: Create the ! Voice Wired AP and Port ap wired-ap-profile "Wired_Voice_ap_profile" Profiles (Port 2) on wired-ap-enable page 139 (Chapter 9) switchport access vlan 160 ! Step 6A: Create the Enterprise Wired AP and ap enet-link-profile "default" Port Profiles (Port 1) on page 138 (Chapter 9) ! ap wired-port-profile "default" ! Step 6C: Create the ap wired-port-profile "Wired_Ent_port_profile" Family Wired AP and wired-ap-profile "Wired_Ent_ap_profile" Port Profiles (Ports 3 aaa-profile "Remote_Ent_aaa_profile" and 4) on page 139 ! (Chapter 9) ap wired-port-profile "Wired_Family_port_profile"
  • 254. Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 254 ! 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" Pushed from master opmode wpa2-aes ! wlan ssid-profile "Family_ssid_profile" essid "Family" opmode wpa2-psk-aes wpa-passphrase bf747cd922d85ee46499192edb974c98956025fd72d3dbd9 ! wlan ssid-profile "Voice_ssid_profile" essid "Voice" Pushed from master opmode wpa2-aes ! wlan virtual-ap "default" ! wlan virtual-ap "Enterprise_vap_profile" ssid-profile "Enterprise_ssid_profile" vlan 128 Pushed from master 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 Virtual Branch Networks Aruba Networks, Inc. ! 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" ! Step 5A: Create the Enterprise rf dot11g-radio-profile "default" SSID and Virtual AP Profiles on ! page 136 (Chapter 9) wlan ht-ssid-profile "default" ! Step 5C: Create the wlan ssid-profile "default" Family SSID and Virtual ! AP Profiles on page 137 wlan ssid-profile "Enterprise_ssid_profile" (Chapter 9) essid "Enterprise" opmode wpa2-aes ! wlan ssid-profile "Family_ssid_profile" essid "Family" opmode wpa2-psk-aes wpa-passphrase cc5e10b47af17603090b6e9159ab082a71fb574ffeec28ab ! wlan ssid-profile "Voice_ssid_profile" essid "Voice" Step 5B: Create the Voice opmode wpa2-aes SSID and Virtual AP Profiles ! on page 137 (Chapter 9) wlan virtual-ap "default" ! wlan virtual-ap "Enterprise_vap_profile" ssid-profile "Enterprise_ssid_profile" vlan 128 Step 5A: Create the forward-mode split-tunnel Enterprise SSID and Virtual aaa-profile "Remote_Ent_aaa_profile" AP Profiles on page 136 ! (Chapter 9) wlan virtual-ap "Family_vap_profile" ssid-profile "Family_ssid_profile" vlan 177 Step 5C: Create the Family forward-mode bridge SSID and Virtual AP Profiles aaa-profile "Family_aaa_profile" on page 137 (Chapter 9) rap-operation always
  • 255. end Virtual Branch Networks ! wlan virtual-ap "Voice_vap_profile" Pushed from master 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" Pushed from master 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 Aruba Networks, Inc. ! wlan virtual-ap "Voice_vap_profile" Step 5B: Create the Voice ssid-profile "Voice_ssid_profile" SSID and Virtual AP Profiles vlan 160 on page 137 (Chapter 9) 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" Task 8: Configure the enet1-port-profile "Wired_Ent_port_profile" AP Group on enet2-port-profile "Wired_Voice_port_profile" page 141 (Chapter 9) enet3-port-profile "Wired_Family_port_profile" enet4-port-profile "Wired_Family_port_profile" ap-system-profile "APGroup1_sys_profile" ! Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 255
  • 256. Virtual Branch Networks Aruba Networks, Inc. Validated Reference Design Sample Configuration Files for Fixed Telecommuter Example | 256
  • 257. 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 Incident Response Team (WSIRT) http://www.arubanetworks.com/support/wsirt.php Support Emails Americas and APAC support@arubanetworks.com EMEA emea_support@arubanetworks.com WSIRT Email Please email details of any security problem 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 9434526 1 650 3856589  Canada 1 800 9434526 1 650 3856589  United Kingdom BT: 0 825 494 34526 MCL: 0 825 494 34526 Aruba Networks, Inc. Aruba Contact Information | 257
  • 258. Virtual Branch Networks Validated Reference Design Telephone Support  Universal Free Phone Service Numbers (UIFN):  Japan IDC: 10 810 494 34526 * Select fixed phones IDC: 0061 010 812 494 34526 * Any fixed, mobile & payphone KDD: 10 813 494 34526 * Select fixed phones JT: 10 815 494 34526 * Select fixed phones JT: 0041 010 816 494 34526 * Any fixed, mobile & payphone  Korea DACOM: 2 819 494 34526 KT: 1 820 494 34526 ONSE: 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 34526 Barack 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 34526 China Netcom Group: 0 802 494 34526  Saudi Arabia 800 8445708  UAE 800 04416077  Egypt 2510-0200 8885177267 * within Cairo 02-2510-0200 8885177267 * outside Cairo  India 91 044 66768150 Aruba Networks, Inc. Aruba Contact Information | 258

×