Question: Why are RAP 2 or RAP 5 unable to use zero touch provisioning to connect to A3000 and M3 controllers that run RN-3.1.5 to RN-3.1.12?
Product and Software: This article applies to RAP 2 or RAP 5 in A3000 and M3 controllers that run RN-3.1.5 and later.
Problem
Sometimes the RAP2/5 cannot be provisioned using zero touch provisioning against A3000 and M3 controllers that run RN-3.1.5 to RN-3.1.12.
Affected Setup
- A3000/M3 controllers that run RN-3.1.5 to RN-3.1.12
- RAP2/RAP5 that run ArubaOS 5.0 as the factory-loaded image using zero touch provisioning
- Remote AP VPN user role configured as per the ArubaOS/RN code user guide
Remote AP VPN User Role Example
ip access-list session rap_acl
any any svc-papi permit
any any svc-gre permit
any alias controller svc-tftp permit
any alias controller svc-ftp permit
!
user-role <role>
session-acl rap_acl
!
aaa authentication vpn
default-role rap_role
!
Solution / Workaround
Add a rule to the the example rap_acl to permit udp 8209.
netservice svc-sec-papi udp 8209
ip access-list session rap_acl
any any svc-papi permit
any any svc-gre permit
any alias controller svc-tftp permit
any alias controller svc-ftp permit
any any svc-ntp permit
any any svc-syslog permit
any any svc-sec-papi permit
!
Root Cause
A RAP2/RAP5 that has booted up with ArubaOS 5.0 can set up its IPsec to the RN controller and get an inner IP. However, it communicates with the controller using secure PAPI (udp 8209). If such a port is blocked by the VPN user role, the RAP5/2 continues to fail. Allow the RAP to communicate on this port so that the RAP can downgrade its code.
Notes:
- This problem does not happen if the default VPN role (default-vpn-role) is used. By default, the default VPN role has an "allow all" session ACL that permits all traffic on all ports.
- The symptom is easily observed by checking the datapath session table for a deny flag:
Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags
5.5.5.2 10.163.160.89 17 8209 8209 0 0 0 0 tunnel 9 2 FDYC