Michael Nancarrow's Blog
Aruba Central, and Groups
2019-08-26 (Last Update: Mon, 26 Aug 2019) Michael Nancarrow 1 Uncategorized
Aruba Central Implementation
This post simply describes the process I will undertake to implement an Aruba Central instance for my company. It will be ever-updated and modified as I go. It is important to remember the settings enabled are best to suit my requirements, and are not necessarily what you need to enable for your instance.
For more documents on the Aruba Central product, you may find the following of use:
- Aruba Instant Training - a series of videos created by Aruba to help document the installation and configuration of a network.
- Aruba Support Portal - the official Aruba portal for knowledge base articles and assistance.
- Aruba Central Documentation - the support documentation pertaining to Aruba Central.
At the moment, I am going down the route of implementing Aruba Central to replace the Cisco WLC in my environment. Why? Because the management component of the Aruba stack, to me, is much more transparent and the support around the product trumping others. But you didn't come here to listen to an idiot's personal beliefs, did you? Either way, in this series of posts I'll be documenting what (and perhaps even why) I do things in Aruba Central to perhaps help you understand the product, even post purchase and implementation.
For the most part, Central was opted for purely based on it's Wireless support as opposed to other vendors (never use Extreme, if you want to save yourself heart-ache). The switching environment in my company is fairly static, so for the most part that will the very last part we focus on in our Central installation.
Access Point Groups, and what they are used for.
On of the core selling points of any management solution is Zero-Touch Deploy and 1-Touch Deploy - this being especially true when it comes down to Access Points. This is one of the best functions (in my opinion) for controlling deployment options, and the first setting on my agenda to configure.
A group in Aruba Central acts like a primary configuration container for devices. You can combine devices with common configuration requirements into a single group and apply the same configuration settings to all the devices in the group.
In Aruba Central, under the Global Settings you will locate an option for Groups. There are a few options here for the Template Group for selection, but as we're doing WiFi we will opt for iiAP and Gateway as required. I create a random password for security measures, to prevent accidental misuse of a group:
date +%s | sha256sum | base64 | head -c 23 ; echo
For now, I'd recommend making as minimal as possible template groups until you get the flow of how Central operates. For me, I created 2 basic template groups for deployment. Once done here, head over to Wireless Management to begin making use of groups.
Wireless Management - Menu
Once in Wireless Management, you will see a filter at the top for the group you just made. You can either ingest a configured iAP, or create the group here before adding members. If you click on the group you just made, you can create templates and variables to define the settings you wish to push to an iAP - I'll cover that in another post once I've defined my settings. For now, opt for "Default" on a Virtual Controller and let's begin our magic.
Menu Entry: Wireless SSIDs
Each company will have multiple SSIDs pertinent to their requirements. Remembering how to calculate 4 way handshakes, I'd recommend keeping it to 3 or 4 at most. For me, I'll create an internal secure SSID as follows:
- Name (SSID): MyCompanyName
- Band: 5Ghz
Under Advanced, I create a few more options for my usage: * Zone: Secure * Miscellaneous\Content Filtering: Enabled * Miscellaneous\Inactivity Timeout: 900 Seconds * Time Range Profiles: 05:00am to 07:00pm
I do not de-authenticate inactive clients to minimize airtime utilization - however I do plan on returning to this and applying DSCP mapping for usage at a later stage. Moving through the stages, I am then presented with DHCP and VLAN assignment options. For my usage, I opt to utilize an eternal DHCP server for IP Allocation, but opt to perform "a VLAN Assignement Rule", which helps me dynamically name the VLAN a client connects to.
This gives me flexibility for allocating a VLAN to a client based on a factor. For me, I opt to use the end name of an iAP to denote the VLAN it should use to carry data for clients.
This section is so broad, that I'd really not do it justice trying to define it. For myself, I will be implementing 802.1X with an external RADIUS server for user access - so I opt for Enterprise. Then (again, for me) I edit some advanced settings for security as follows:
- Advanced Settings - Reauth Interval: 3 Hours
- Blacklisting: Enabled
- Enforce DHCP: Enabled
- Max Authentication Fails: 10
Once done here, we get to my favorite part: Access Rules. Here we can really break down on what devices can and cannot do on your Wireless LAN. For example, rules I like to create are as follows:
- Allow SSH to Network (Internal Range) + Log + Blacklist - I don't want any old user to SSH externally unless we know what they're doing
- Deny Web Results - Pornography, Keyloggers etc. - Using an online reputation we block sites believed to be malicious.
- Allow HTTP, HTTPS, DNS to all locations + Using Specific Time Based Profiles - we allow traffic at specific times, and then deny after
This can get very targeted, and you can spend hours doing this (which, I will) but for now, you've created a SSID.
Now we need to create the Wired Port for the iAP uplinks. Atypically in the beginning I just name it the
RF Profile-Wired and continue with enabling
STP. Leaving the VLANS as default to allow the iAP to dictate it is my preferred mode of operation, as well.
Smash through the settings and change the defaults to match the Wired Port Profile you created, and we're set. Jump down to
RF and set the Client Access to be Fair and you should be ready to join an iAP to the group to test the magic you've made.
I mean you should have 802.1X on LAN and RF, along with an enterprise firewall, but we can also lock down RF. Under the
Wireless IDS/IPS I tend to hit things to Medium to go on the offensive for protection for clients on my wireless. Moving onto the actual Security Configuration we denote our RADIUS server, and roles (which can here be re-used across a number of RF profiles to enforce standardization). Some other settings I'd enable are as follows:
- Blacklisting\Dynamic Blacklisting\Auth Failure Blacklist Time: 5 Minutes - this will later be fine-tuned to meet your requirements.
- Custom Blocked Page URL: Default to a public page denoting the web page is restricted and cannot be accessed.
Questions and Answers
- How do you configure the syslog options within Central? - Configuring SysLog and TFTP Dumps on iAPs within Central
- How do we configure all iAPS to use the onsite DHCP helper for clients to ascertain a DHCP address? - Configuring centralized DHCP Scopes.
- How do you configure RADIUS and other authentication services for Aruba Central? - Configuring RADIUS in Aruba Central.
- How do you configure Firewall ACLs? - Configuring Firewall Policies and ACLs.
- How do you configure your switches to carry the correct VLAN? - Using configuration templates and edit the VLANs allocated.
- Cloud managed by Aruba Central - Add device to Central & Template Group
- Cloud managed by Aruba Central - Why & What are Template Groups
- Cloud managed by Aruba Central - Template condition statement madness