With distributed layer 3 mode of IAP VPN deployment, the subnet pool is configured on the VPNC. This overall subnet pool is then divided and automatically assigned to each of the APs by the VPNC using the number of devices expected at each branch as an input. The IAP-VPN solution guide available at the link below provides additional details on this.
Helper address for layer 3 tunnels is currently not supported, but is being evaluated as part of the roadmap.
Central On Prem (COP) supports IAP deployment and management. Central/COP provides management but no client traffic goes through it. Instead, client traffic is tunneled from the IAP to the VPNC. The management plane between IAP and Central goes over HTTPS and need not be tunneled. You are correct in your understanding – Central provides configuration and monitoring of the deployments, but the user traffic does not reach Central. Aruba already offers Central in AWS and Azure, you just need to subscribe to the service available through the public instance in the cloud.
IAP certainly does support more than 20 user roles, several SSIDs and a large number of ACLs. However, in the distributed architecture of IAP without a dedicated hardware controller, some of the scale parameters are somewhat limited when compared to AOS/controller based solution. One of the advantage of IAP's distributed architecture is that the IAPs are more self-reliant individually and perform much of the processing and policy enforcement at each of the APs. Consequently, some of the issues you may have experienced in the RAP architecture may not be a concern in IAP VPN architecture.
I am sure your account team will be happy to assist you in confirming that your existing configuration and scale can be supported with IAP-VPN solution. We would also want to work with you to understand the bootstrap issues you mentioned and their applicability to IAP VPN architecture.
(deleting duplicate post)
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.