In my experience, configuring some parameters via the Aruba Networks GUI is a bit of a pain. I have found that doing certain parts of the deployment via the CLI is a lot faster. Below is an example of such a deployment. The example below was for a multi-site, retail-type of environment. Rather than deploying wireless controllers at each site, I deployed all APs as remote APs in bridge mode behind Juniper Networks SRX Series Firewalls. This deployment method leverages the benefits of Aruba Networks' Remote AP technology. Basically, the configuration is stored in the flash of the AP so that there is no need to deploy a wireless controller at each site, keeping hardware costs as low as possible. This also makes it so that there is no need for the APs to remain connected to the wireless controller in order to provide wireless access for end users. They are essentially leveraging local switching rather than tunneling back to the controller and then out to the Internet.
NOTE: I am not going to review configuration details for the SRX side of the deployment. You can find that information here. Please also note that these steps have been validated on ArubaOS 5. I imagine it will work for newer builds, but don't quote me on that.
When working with ArubaOS, it is important to go from most granular to least granular. Here is the general method I follow (which varies based on use case):
- Define services
- Apply services to access lists
- Apply access lists to user roles
- Define ap system profile, aaa profiles, wlan ssid profiles
- Apply user roles to aaa profiles
- Define wlan virtual ap and apply aaa profiles, wlan ssid profiles
- Define ap groups and apply wlan virtual ap and ap system profile
I know it seems confusing, but after doing it a couple of times and following this method you will save a ton of time. Here it is explained:
Define the services that you would like to use.
netservice svc-http-acl tcp 80
netservice svc-dhcp udp 67 68 alg dhcp
netservice svc-dns udp 53 alg dns
netservice svc-mgcp-5004 udp 5004
netservice svc-rtp-udp udp 3000 3005
netservice svc-mgcp-2427 udp 2427
netservice svc-mgcp-2727 udp 2727
netservice svc-sip-udp udp 5060
netservice svc-mgcp-5440-5446 udp 5440 5446
netservice svc-ftp tcp 21 alg ftp
netservice svc-ntp udp 123
Define the access control lists that you would like to use.
ip access-list session dns-acl
any any svc-dns permit
!
ip access-list session http-acl
any any svc-http permit
!
ip access-list session dhcp-acl
any any svc-dhcp permit
!
These ACLs are basically stating that from any network to any network, allow DNS/DHCP/HTTP traffic. The same format applies to the rest of the ACLs below.
ip access-list session allowall
any any any permit
!
ip access-list session srcnat
any any any route src-nat
user any any src-nat
!
The srcnat ACL is important when deploying APs as Remote APs in Bridge Mode. You will see why shortly.
Create user roles and apply access control lists to them.
user-role test-corporate-role
session-acl allowall
session-acl srcnat
!
user-role test-guest-role
session-acl dhcp-acl
session-acl srcnat
!
One role applies to guest users, and the other applies to corporate users. It is important to note that although we are leveraging local switching and firewall rules on the Juniper SRX Series Firewall, ACLs applied to user roles can still allow/deny traffic. This is due to the fact that the AP configuration is stored in the flash of the AP itself in this type of deployment. By applying the allowall ACL at the beginning of the user role, we are essentially telling the AP to follow the rules applied on the SRX. The srcnat rule tells the AP that if traffic does not match rules on the SRX, then dump all traffic out the local untrust interface. There is always an implicit deny at the end of every Aruba Networks firewall policy.
Create aaa profiles and apply roles to them.
aaa profile "test-corporate-profile"
initial-role "test-corporate-role"
authentication-dot1x "default"
dot1x-default-role "test-corporate-role"
!
aaa profile "test-guest-profile"
initial-role "test-guest-role"
authentication-dot1x "default"
dot1x-default-role "test-guest-role"
!
Create an ap system profile.
ap system-profile "test-ap-profile"
native-vlan-id 6
!
Based on this example and our integration with the Juniper SRX Series Firewall, the native VLAN ID is the same VLAN that the AP and the corporate wireless users with reside on (192.168.6.0/24). You have to use this command when the AP is plugged into a trunked interface. You can find additional information on the SRX configuration here.
Create WLAN SSID Profiles.
wlan ssid-profile "test-coporate-ssid"
essid "corporate"
wpa-passphrase test123
opmode wpa2-psk-aes
!
wlan ssid-profile "test-guest-ssid"
essid "guest"
wpa-passphrase test123
opmode wpa2-psk-aes
!
In this example, both SSIDs are configured for AES-CCMP encryption with a pre-shared key.
Create WLAN Virtual AP Profiles, and apply the AAA and SSID Profiles.
wlan virtual-ap "test-corporate-vap"
aaa-profile "test-corporate-profile"
ssid-profile "test-corporate-ssid"
vlan 6
forward-mode bridge
rap-operation always
!
wlan virtual-ap "test-guest-vap"
aaa-profile "test-guest-profile"
ssid-profile "test-guest-ssid"
vlan 7
forward-mode bridge
rap-operation always
!
The wlan virtual-ap profile is exactly what it describes, a "virtual" access point. By creating multiple virtual APs, you can have multiple SSIDs exist on one physical access point. Please also note that these VLANs only reside at the branch network and not where the controller lives, thus it is not necessary to add these VLANs to the controller itself.
Create an AP Group, and apply the Virtual AP Profiles.
ap-group "test-ap-group"
virtual-ap "test-corporate-vap"
virtual-ap "test-guest-vap"
ap-system-profile "test-ap-profile"
!
Provision the AP.
provision-ap copy-provisioning-params ap-name 00:00:00:00:00:00
provision-ap installation default
provision-ap dns-server-ip 1.1.1.1
provision-ap domain-name test.local
provision-ap no external-antenna
provision-ap server-name aruba-master
provision-ap ap-group "test-ap-group"
provision-ap ap-name "Test_AP"
provision-ap no syslocation
provision-ap mesh-role none
provision-ap no fqln
provision-ap reprovision ap-name 00:00:00:00:00:00
