This is the first post regarding the Aruba Remote Access Points. There are several scenarios for this kind of AP and this first post is for a basic RAP setup. This basic RAP setup is about connecting the RAP to Aruba Controllers and the configuration on the Controller.
Basic RAP Setup: What is a Remote AP
A Remote AP is a normal AP, from a hardware point of view, which means, any Aruba AP can be a RAP. It is just a different mode of operation. The main difference to a Campus AP (CAP) is the IPSec tunnel, which is used to tunnel all traffic, including the wireless traffic, to the controller. This enables the RAP to be used outside of a secure network, like home offices or small branches.
The RAP uses the provisioned domain name or IP to build the IPSec tunnel to the controller and only needs access to the internet. After a successful connection to the controller, the RAP can extend the WLAN to the home office, small branch or whatever location the RAP is installed. If the AP has additional LAN ports, they can be tunneled to the controller as well and extend the wired network as well.
Before I have moved to central and IAP for my own setup, I was using a RAP to connect from customers and hotels to my home lab. I only needed to boot the RAP and wait for my own SSID to become available. Very easy and convenient.
Basic RAP Setup with a Standalone Controller
Even if the setup is almost the same, there are some differences when deploying
On the controller, there is not much to configure. I use two standalone controllers, running ArubaOS 126.96.36.199 in a Master/Standby deployment.
The first step is to create a IP pool for the inner IP. The inner IP is the IP in the IPSec tunnel. There is no need to route this IP pool in the network. It is just to handle communication between the Controller and the RAP through the IPSec tunnel.
To create this IP pool go to “Configuration–>Services–>VPN” and select “General VPN”. just click the “+” sign in the “Address Pool” table to create a new address pool:
Simply add the IP address pool. Just use a name, which is meaningful and enter the IP range. If you think, some of your RAP’s will be behind a NAT device, like in most home deployments, enable the “NAT-T” option for NAT Traversal.
My test AP is already connected to the controller as a Campus AP. I need to provision this AP to become a Remote AP:
The important part is the “Deployment”, where you need to select “Remote”. If you are using virtual controllers, use the “self-signed” certificate as the “Trust anchor”. For a hardware-based controller, you do not need a trust anchor, as they will use the internal certificates on the TPM chip to authenticate each other.
The “Controller IP/DNS name” is the VRRP IP of the two controllers.
If you are reading carefully, you should have seen, that I used the wrong AP group in the picture above. So I needed to provision the RAP a second time. So always keep your eyes open before pressing submit 😊
To allow the connection from the RAP to the controller, you need to add the RAP to the Remote AP whitelist as well:
It is the same procedure as with the “Campus AP Whitelist”. You can also use an external server like ClearPass or even with Aruba Activate.
After the RAP is connected to the Controller it will be shown as online:
The IP is the inner IP from the IP pool created above and the “Operating mode” is “Remote”.
If your Controller did not have an official IP and is behind a NAT device, you just need to make sure, that you forward the following ports:
- UDP 69 (TFTP for image transfer)
- UDP 500 (IPSec)
- UDP 4500 (IPSec Nat-T)
Basic RAP Setup with a Controller Cluster
There is a limitation, as of today. You can only have 4 controllers in a Cluster when connecting
With the Controller Cluster, most of the steps from above are the same. There is only one exception, the IP pool. Instead of creating an IP pool directly on the cluster in the VPN settings, you configure the IP pool on the Mobility Master.
You find this option on the MM hierarchy under “Configuration–>Services–>Cluster” and just hit the “+” sign to create a new pool:
Save the changes and you are done. If you configured the rest of the options from above as well, the RAP should come up and will have a connection to all cluster members:
(mobility-master-haan) *[mynode] #show ap database AP Database ----------- Name Group AP Type IP Address Status Flags Switch IP Standby IP ---- ----- ------- ---------- ------ ----- --------- ---------- RAP205 RAP-Group 205 10.0.0.12 Up 6m:7s Rc2 10.201.201.11 10.201.201.12 Flags: 1 = 802.1x authenticated AP use EAP-PEAP; 1+ = 802.1x use EST; 1- = 802.1x use factory cert; 2 = Using IKE version 2 B = Built-in AP; C = Cellular RAP; D = Dirty or no config E = Regulatory Domain Mismatch; F = AP failed 802.1x authentication G = No such group; I = Inactive; J = USB cert at AP; L = Unlicensed M = Mesh node N = Duplicate name; P = PPPoe AP; R = Remote AP; R- = Remote AP requires Auth; S = Standby-mode AP; U = Unprovisioned; X = Maintenance Mode Y = Mesh Recovery c = CERT-based RAP; e = Custom EST cert; f = No Spectrum FFT support i = Indoor; o = Outdoor; s = LACP striping; u = Custom-Cert RAP; z = Datazone AP p = In deep-sleep status
If your Controllers do not have a public IP address, there are more steps required than just enable the forwarding on the NAT device.
To use a RAP with a Controller Cluster behind a NAT device, the Cluster should be aware of the external IP. You configure the external IP of a Cluster member during the setup of a Controller Cluster.
Go to the hierarchy level, where you configured the Cluster. Unfortunately, it is not possible to add the external IP’s to an existing Cluster Config. You need to remove all
While adding them, make sure to set the “Rap public IP” to the Configuration:
This makes sure, that the RAP will get the external IP of the Cluster Member, instead of the internal one and the RAP will use the external one to connect to the Cluster Member:
(mobility-master-haan) *[mynode] #show ap database AP Database ----------- Name Group AP Type IP Address Status Flags Switch IP Standby IP ---- ----- ------- ---------- ------ ----- --------- ---------- RAP205 RAP-Group 205 10.0.0.12 Up 5m:55s Rc2 10.201.201.11 10.201.201.12
You still see the internal IP’s instead of the external IP’s. To get the external IP’s visible, use this command:
(Cluster-Member-1) #show ap remote debug sapd cluster-nodestate ap-name RAP205 Cluster Node Table ------------------ IP Address Switch IP Address Flags State ---------- ----------------- ----- ----- 10.203.203.11 10.201.201.11 A2 Up 10.203.203.12 10.201.201.12 S2 Up Flags: A = Active AAC; S = Standby AAC; U = UAC; 2 = Using IKE version 2
As you see in the post above, the setup is really easy.
If you find this post useful, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and tell me what you don’t like. But whatever you do, leave me a comment.
50 thoughts on “Basic RAP Setup with ArubaOS 8”
Thank you for this.
I have 1 question.
In the “Basic RAP Setup with a Controller Cluster” is it the Controllers VRRP or the MM´s VRRP that the Raps is pointed to?
Thanks for the comment.
The MM cannot terminate any AP so you need the VRRP if the controller and or controller cluster.
Thanks a lot for the topic, especially RAP with cluster, Aruba never made a good how-to on that.
That just saved me a lot of troubleshooting and research!
thanks for the feedback.
Thanks for your sharing,
in your lab environment are used standalone MC deployment right?
My question is, when i have two MD for terminate the RAP APs.
is possible to create cluster and joint both MD to the cluster? are the AP connect to the VRRP ip address?
Hi Atum Jasa,
Yes, you can use the MD’s in a cluster and connect your RAP’s to that cluster. I describe this in the post above. To my knowledge, you cannot use the Cluster VIP, but I haven’t tested this in the lab. I have used one of the external member IP’s.
Really nice guide, thank you.
I have a couple of questions.
We have a cluster with two MD 7210 at work.
We haven’t set the “RAP PUBLIC IP” when adding the device to the cluster unfortunately.
Do we need to have a unique Public address for each controller or can it be the same? The traffic will traverse through a Palo Alto firewall so we can NAT this using “One-to-Many”-mapping if needed so all controllers share the same public IP, but that may be overkill.
We will soon receive a third controller that we can add with a RAP Public IP. Will it work if we only have one of three controllers with this setting, but loose redundancy for the RAP?
thanks for your comment. Really appreciated the time you spend on the page and read the post.
To your questions, you need a unique public IP address for each of your controllers. It is not possible to share the same IP between all controllers. The reason is the following. When the RAP connects to the cluster he will receive the list of all controllers in the cluster. If you do not specify the RAP public IP, the RAP will receive the controller IP of each of the controllers in the cluster, which would not be available as they are behind your firewall.
So each controller needs to have a unique RAP Public IP configured.
Hope this helps.
How can we configure a static IP to RAP , so that it can be monitored by tools, each time we connects RAP it gets IP dyanamically from RAP Pool,
Actually, you can’t. The inner IP would always be a new one. But actually, it wouldn’t make any sense to have a static IP, as the RAP would never respond to any monitoring, except ping. All the information about the RAP status can be found on the controller he is connected to. Tools like AirWave only query the controller, to get the information about all connected AP’s, including RAP’s.
What is your goal in monitoring the RAP?
I have one controller 7005 and three AP-305 deploy in my network. I have one problem which I can’t remote to the AP directly via https from my PC.
actually, I do not really get the point. You have a controller running in your network. you also have 3xAP305 in your network. What is the reason, that you want to reach the AP’s via https? They are fully managed by the controller.
Great post Much appreciated!
A quick question – we have an MM cluster that manages a cluster of controllers ( Active/Active). The RAP and VPN pools are defined at the MM level and we’re using certificate based authentication.
We’re Natting one of our public IPs to the VIP of the RAP SVI we defined on the controllers. This scenario worked in the past but we deleted the RAPs out of the controller many months ago and now we’re trying to re-provision them “out-of-the box”
The RAPs are whitelisted on the controller already – do we need to provison them internally and as CAPs first ?
Phase 1 & phase 2 came up but the RAP never showed up in the AP database.
Wondering if your theory about having a public IP on each controller is what’s troubling us right now? It just doesn’t make sense that it used to work in the past…. The reason why we never configured a public IP on the controllers is because they aren’t in the DMZ. We essentailly multihomed our controllers with this approach.
If you use a Cluster of MD’s and would like to terminate RAP’s on this cluster every cluster member needs an official IP. Or at least it needs an official IP which is NATted to the cluster member. And this official IP needs to be configured in the cluster profile for each controller, as shown in the post above.
The reason is, that during the first connection of the RAP to the cluster, the RAP gets a list of all available cluster members. If no public IP is configured in the cluster profile for each cluster member, this list will contain the internal IP’s, which are not reachable for the RAP’s when coming from an external location.
The cluster cannot exceed 4 controllers if you need to terminate RAP’s. So if you have a cluster of 4 controllers, you would need at least 4 external IP’s which are 1:1 NATted to the cluster members and a DNS entry, which is doing some kind of round-robin for those IP’s. You can also add an additional external IP for the cluster VIP, but this is not required.
You are also talking about the whitelist. On the controller, there are two whitelist. On whitelist for CAP’s and one whitelist for RAP’s and IAP’s. If the RAP’s where used as CAP’s before, they need to be in both whitelist, the Campus AP Whitelist and the Remote AP Whitelist.
Hope this helps to get those RAP’s online.
Hi, thank you for your informative post. Can this be done i.e. converting a CAP to RAP to connect to a controller that sits in the same vlan (same L2 broadcast domain)? the reason is I am wondering if i could use the RAP functionality to broadcast ssids in bridge mode and not worry about controller being down? for resiliency in a single controller deployment.
the RAP’s are not designed to work that way. RAP’s will not find a L2 connected controller using ADP, as they do not do ADP at all. They need to know the controller IP and will connect to that IP. And yes, this IP can be in the same subnet as the RAP itself. But, the RAP is not designed to be used in such environments, as there is a limitation in how many RAP’s should be used in the same location and I think it is 4.
The reason is, that there is no RF optimization and sync between the RAP’s.
From my point of view, you have only two options for this setup, either use a second controller for redundancy, or work with IAP’s as they do not need a controller at all. If you still need some SSID’s with centralized traffic, IAP’s can build a tunnel to a controller and tunnel traffic from SSID’s to the controller using the tunnel.
great article. I was wondering if have you tried using aruba controller with a home modem? I have a 7005 controller with 5 rAPs. Controller port0 is connected to a poe switch port1 and controller’s port 3 to the poe switch on port 3 and modem to the poe uplonk switch. I follow aruba’s steps below, but controller does not get an ip from the modem. if i connect my laptop, i get the external ip from the modem.
(Aruba) (config) #interface vlan 930
(Aruba) (config-subif)# ip address dhcp-client
(Aruba) (config-subif)# exit
(Aruba) (config) # interface fastethernet 0/3
(Aruba) (config-if)# switchport access vlan 930
(Aruba) (config-if)# end
(Aruba) # write memory
actually, I was running this setup until recently (last week) here at my home. Not sure how your provider works but I also had to configure PPPoE to make it work. I now use my modem to do all the PPPoE stuff and my controller only gets’s an internal IP from the modem.
What I’m missing in your config is the trust setting. Here is my config:
interface gigabitethernet 0/0/3
trusted vlan 7
ip access-group session "wan-uplink-protection-port-forward-acl"
switchport access vlan 7
interface vlan 7
ip address dhcp-client
ip nat outside
You need to trust the port and the VLAN or all packets on the port will be dropped.
Hope my config will help you.
The official Aruba documentation is at
I have a question about configuration when use Remote AP and Guest with Captive Portal, is it correct used? If you have documentation guide or link to configure this is scenario example, because Im confuse about this is configuration.
guest with captive portal is configured the same way as with a campus AP. The traffic will be tunneled back to the controller and there you will have the redirect to the captive portal. This would be the easiest configuration. Is this what you are looking for?
Hi Florian, yes
But in my case, I need clients to connect guest SSID use local internet of remote site, on tunnel between Controller and Remote AP not use roteable ip address, the client get ip address over dhcp of isp modem local, when I activete split-tunnel, my clients not get captive portal.
Can I need configuring more options over split-tunnel or captive portal profile?
Sorry, but Im new user Aruba solutions.
to my understanding (haven’t configured of yet for myself) you need to work with split tunneling. All traffic for the captive portal will go through the Tunnel and all other traffic can use the local internet breakout.
You might look at this VRD (https://www.arubanetworks.com/vrd/RAPVRD/RAPVRD.pdf). It is a little bit old but from my point of view still valid and describes the most important parts. Chapter 14 is exactly what you are looking for.
Hope this helps.
Just wanna say thanks for this guide. Really helpful and easy to digest. Please keep up the good work! 🙂
thanks for the feedback. Really appreciated. Thanks for taking the time to read my posts.
So from my understanding of this article there is no way to cluster with mutiple ISPs (like in 6.5 LMS backup IP)
why do you think this should not work? From my understanding LMS backup LMS will still work if you run either standalone controllers or single controllers managed by a Mobility Conductor.
as always – great post. We´re facing 1st time RAP setup with a cluster next week, so i was reading around. thanks for your essentials guide.
while reading, i was wondering why TFTP should be forwarded and permitted. imho this adds unnecessary attack surface due to having no integrity protection. the ipsec encapsulation should accomplish this.
i would assume that TFTP is not mandatory needed.
TFTP is needed for the image upgrade. There is an option within the controller to disable the TFTP image upgrade, but I haven’t tested it yet.
If your concern is security, to my understanding the controller will secure the TFTP port so that no attack against the controller can be run on that port. The images, which can be downloaded through that port are more or less publicly available, so no internal content is revealed. The controller also has a BW limit for that port, which makes a DoS attack not working.
If your concern is the integrity of the transferred file, this is done by the RAP, which checks the file before it is applied.
Hope this helps.
Hi Flo, i admit to be security paranoid. saying that, i would assume that some actors could easily setup a mitm situation. recent incidents teached us not to trust any code coming from outside, even if it was signed. i was just wondering why not to use the data transfer within the “trusted channel”. LG Marko
I fully agree. Using the secure channel would enhance security. But this tunnel is protected with the same credentials (certificates) which are used within the code signing. So if someone can create software that will be trusted by our devices, it should be easy for this person to also intercept the IPSec tunnel, so there is no benefit.
Does this make sense?
yes, for sure 😉
Have a question about upgrading.
Have a single 7005 and 2 303H AP´s, soon to be 5.
It works fine. When the power goes out and then restored they re-connect.
But when i do upgrades on the controller the ap´s doesn´t get the upgrade.
I have been forced to go and get them and then do a factory reset and “install” them again.
I have searched but havn´t found how to do the upgrade on a “rap controller”.
normally, the AP (RAP?) should download the new image automatically from the controller and get updated as well. Make sure, that all ports from the page below are opened between your controller and the AP’s.
Thanks for reply.
It´s RAP´s so then it´s just:
NAT-T (UDP port 4500).
TFTP (UDP port 69)
And they are open and NATed to the 7005. Hmm, strange.
Well, the search will go on.
Thank you again.
if those ports are available it should work. do you see anything in the logs of the controller?
No, i have not looked at the logs.
I have assumed that it was a firewall problem. Either on the controller side or the RAP-side.
I´ll take a look and se if there is something left.
maybe worth a look : in AP profile, you can set a “disable rap tftp image upgrade” – we struggled over this w/ cluster upgrade. greetz
Thanks for tip.
Checked that, on several places. No checkmark in that box, sadly. 😉
If there is nothing in the logs, your RAP’s were not connecting to the controller. There should be some log entries of RAP’s connecting even if it fails. You could also do a packet capture at the controller uplink to check if you see packets from the RAP’s, but I would combine this with a support ticket a Aruba.
We have also a RAP deployment in all remote sites. I am not sure if RAP is still working with authenticated client if controller goes down as we have experience with 1 site that rap does not broadcast SSID when controller is unreachable using AP105 but other site don’t complain with AP using 300series.
Is there a limitation wit AP105? controller used was 7200 – 188.8.131.52.
Within a RAP deployment, it depends on how the SSID is configured. It could be configured, that the SSID goes down if the controller is not reachable anymore. This makes sense if the traffic of that SSID will be tunneled to the controller.
BUT, you can also configure an SSID for local bridging. Those SSID’s will not be tunneled to the controller and therefore can survive an unreachable controller situation.
Thanks for putting this together. We have a cluster with two controllers and understand we first need to remove each controller from the cluster than add them back to the cluster in order to configure the RAP PUBLIC IPs. Will this cause any impact on wireless traffic? Will the APs reboot or re-anchor to the controllers?
You should do the reconfiguration one by one, so remove the first controller and read the controller with RAP Public IP and do so with the second one, after the first is fully back online and operating. Doing so should minimize the impact on WLAN and clients.
But, I can only recommend doing this during a maintenance window. Or, if possible test within a lab to get a full understanding of the impact of your environment.
The inner IP could be anything ( ie 184.108.40.206 to 220.127.116.11) right ? We don’t need a routable subnet of our LAN.
Also, why the RAP public IP in your example, is a private IP ? Can i use a the public IP that NAT my MD ( example 199.200.4.x during my cluster setup and on the firewall, i Nat this public IP to the internal IP of my MD )?
Yes, the inner IP can be anything, but I would not use anything which is routed on the internet or within your organisation.
I used the private IP on my cluster setup to not use something which do not belong to me and is routed on the internet.
You need to enter the public IP for each controller. This IP can be configured on a firewall and NATed to the controller internal IP. You need to configure the public IP in the cluster setup, as the cluster will propagate those public IPs of the cluster members to the RAP to make the connection.
If you wouldn’t configure those public IP’s, the RAP would get the private IP’s and those will not work on the internet.
Does this make it more clear for you?
I make it work. So i use 3 public IP. One for each MD in cluster mode and one the the VRRP of the cluster. All nated on my FW. During the provision process , i use the Public IP that point to cluster VRRP. Working fine
thanks for sharing. The setup is exactly what I would recommend 🙂
I have a question.: Ive configured everything however my AP doesnt provide any ip address to users connected on it.,
What am i missing ?
Thanks, for your comment.
If the user cannot get an IP, we must look at different thinks.
1. Does the user successfully connect to the RAP and show up in the user table of controller?
2. What role is assigned to the user and does this role allow DHCP?
3. Who provide IP addresses to the client and who does play the DHCP relay if present?
Without more details about the setup, it is hard to help. Sp provide as much details as possible.