Wireless Access

I have a 7030 Controller running 6.5.4.8. The controller is setup for supporting the RAP network. I setup the rap pool on the controller. I confirmed that port 4500 and 500 are allowed through firewall to the controller external IP. I removed both LMS and BK-LMS IPs from the controller. I read that LMS IPs cause issues for RAPs. And I added the RAP MAC Address to the whitelist.

When I execute the conversion process, after entering the controller external ip into the 'Hostname or ip address of the mobility controller' field, the RAP successfully establishes a tunnel to the controller and starts the conversion process. About 2 to 3 minutes later, an dialog box appears 'Retrieve image failed, please save the log in the popup window".

I am using the controller's external VRRP IP address for the conversion.

During the conversion process, I see that the RAP has formed a tunnel with the controller(show crypto isakmp sa) and is assigned a Private IP address from the rap-pool. Under the IPSEC SA V2 Active Session Information, the only flags present are UT2.

I factory-reset the RAP109 several times and tried manually upgrading the RAP to match the controller version. Still no go. 

Here is the show log upgrade from the RAP

Executing '/aruba/bin/download_image_swarm ac-ftp://x.x.x.x/mips21.ari'

fetching ('/usr/sbin/wget -T 120 -t ftp://sap:x@x.x.x.x/mips32,ari')

Error: failed to retrieve image

cleaning up

done

The x.x.x.x is the master controller internal ip address.

Is there a firewall between the AP And the VRRP address?  Try the static NAT to the actual ip address of the controller.  

There is a firewall between the RAP and the Controller. I added the controller external IP address to the ACL. Both ports 4500 and 500 are allowed.

When I create the static nat to the actual controller mgmt ip address, should I select the option 'Used by VPN'? 

Also, I read that the user-role default-vpn-role is required for the RAP conversion process. On my existing 3400 RAP Controller, the role appears under user-roles. On the new RAP Contoller, the role is not there. When I try to manually add it, error message appears indicating role is already present, even though, it's not visible. 

Question:

Has this ever worked?  Have you ever brought up a RAP with the current setup?

Under the existing 3400 RAP Controller(6.4.4.16), the process works without an issue. The conversion process works and RAP109 connects to the controller, downloads its firmware and reboots. 

On the new RAP Controller(6.5.4.8), the RAP connects to the controller, forms a tunnel to the controller, gets an internal ip from the rap_pool and tries to download the firmware from the controller internal ip before crashing out. 

One side note, I did have a loopback interface configured on the non-working RAP Controller, which was on a different subnet than the controller mgmt ip segment. On the working controller, the loopback interface is configured with an ip from the controller mgmt ip segment. Is the loopback interface required for this process?  

loopback is not required, but a loopback should share a subnet with one of the routable VLANs on the controller.  You should try to make the non-working as close to the working controller as possible.

Thanks for the recommendation. On the non-working rap controller, I matched 99% of the settings. the IPSEC Address pool is the same. The external default-gateway are the same. The IP routes setup on the new controller match that of the working controller. The VRRP settings match, along with the Master-redundancy settings. I removed the HA Group Configuration from the non-working controller, along with the LMS/BK-LMS IPs. The AP System Profiles on the non-working controller matches the working controller. The AP Provisioning profile is set to N/A, which matches the working controller too. 

The only difference I see is that the Loopback Interface on the working controller, is assigned an IP from the Controller Mgmt IP segment. On the non-working controller, the field is empty. 

TheController IP on both controllers is using the Internal Mgmt VLAN, not the Controller External VLAN.

Do you have a network diagram along with the firewall and VRRP?  A loopback address is not necessary for this to work.

Question: under the Stateful Firewall/Network Services, I see that ALG protocol is not selected on the working rap controller. On the non-working controller, ALG protocol is set to tftp. Is that a factor?

It is not.

Okay. There is one other difference between working RAP Controller and Non-working. On the working controller, for the switchport trunk, I have both the native vlan and allowed vlans set. Mgmt VLAN is set as the native and it's included in the allowed. On the non-working controller, I have the Mgmt VLAN listed in the allowed list only. Native VLAN is not set. 

Checked the datapath session. I see the tunnel up between controller and RAP. However, the controller doesn't appear to be sending traffic on ports PAPI or TFTP/FTP back to the RAP. 

I downloaded non-controller to match version of working controller and reboot. No change. The RAP successfully forms VPN tunnel 4500 back to controller and obtains an inner ip address. If I console into the RAP, I can reach the controller mgmt ip address via icmp. Still unable to get RAP to download it's firmware. 

I manually tried to upgrade the RAP to match the non-working controller OS. Still no change.  

I want to ask you to open a TAC case, because there is some detail that we are missing here.

Thanks. I raised a case with Aruba TAC. Troubleshooting issue now.

One last question about default user-roles. If a default user-role, like default-via-role or default-vpn-role do not appear in the list of user-roles  webUI view, is there a process to re-add them back into the webui? 

When I manually try to re-add them, the system errors out stating that the role already exists, even though it doesn't appear either at the CLI or Web UI.

Resolved issue. After speaking with the Aruba TAC Engr, we re-created the default user-role default-vpn-role on the master controller. Not exactly sure how the default user-role got removed.

After role was re-added, I was able to successfully provision the RAP and establish connectivity. 

What I have seen a few times in the past, is that the RAP should be in a different subnet than the controller. This was specifically for the conversion process started from the Instant Web UI or CLI. After I moved the RAP to another subnet, the conversion worked like normal.