Basic RAP Setup with ArubaOS 8

Reading Time: 6 minutes

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 RAP’s with a Cluster, compared to deployment with standalone controllers. I will start with the standalone deployment. This deployment works with all deployment types, except for a Cluster.

On the controller, there is not much to configure. I use two standalone controllers, running ArubaOS 8.4.0.1 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:

Basic RAP Setup - Add IP Address Pool
Basic RAP Setup – Add IP 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:

Basic RAP Setup - Provision AP
Basic RAP Setup – Provision 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:

Basic RAP Setup - Add RAP to Remote AP Whitelist
Basic RAP Setup – Add RAP to Remote AP Whitelist

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:

Basic RAP Setup - Online RAP
Basic RAP Setup – Online RAP

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 RAP’s.

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:

Basic RAP Setup - Add Cluster IP Address Pool
Basic RAP Setup – Add Cluster IP Address 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 members and add them again. Remember you cannot have more than 4 if you would like to terminate RAP’s

While adding them, make sure to set the “Rap public IP” to the Configuration:

Basic RAP Setup - Add RAP Public IP to Cluster Config
Basic RAP Setup – Add RAP Public IP to Cluster Config

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.

17 thoughts on “Basic RAP Setup with ArubaOS 8”

  1. 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?

    Reply
    • Hi Matthias,
      Thanks for the comment.
      The MM cannot terminate any AP so you need the VRRP if the controller and or controller cluster.
      Br
      Florian

      Reply
  2. 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!

    Reply
  3. Hi Florian,

    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?

    Reply
    • 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.

      BR
      Florian

      Reply
  4. 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?

    Reply
    • Hi Anton,

      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.

      Many thanks,
      Florian

      Reply
  5. HI Florian,

    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,

    Reply
    • Hi Raghvendra,

      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?

      BR
      Florian

      Reply
  6. Hello,

    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.

    Reply
    • Hallo Visarl,

      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.

      BR
      Florian

      Reply
  7. 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.

    Reply
    • Hi NickDs,

      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.

      BR
      Florian

      Reply
  8. 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.

    Reply
    • Hi TC,

      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.

      BR
      Florian

      Reply
  9. 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

    Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: