Hi,
Yes it can work! But with additional cost.
In my case, the customer didn't want the DHCP to be centralized on the controller for all remote users (who must onboard their devices) , but it is the only way for captive portal to work and only in split-tunnel mode.
The following is workaround that I came up with which allowed me to overcome this obstacle:
Assuming the your RAP Ethernet port is in trunk mode and you can assign different VLANs by your AAA server, also, the switch to which the RAP is connected to supports switch port trunk mode.
1- Create a VLAN (which is not used anywhere in your network) on the switch to which the RAP is connected, and assign it as access mode to some port. Let's say VLAN963 is assigned on port 20.
2- In your AAA server, make a rule to assign VLAN963 to the users who meet your onboarding (or any other captive portal) conditions.
3- In Aruba controller, create AAA profile (with the proper initial captive-portal-enabled user role) to be used for onboarding, and assign this AAA profile as Wired Access AAA Profile.
4- Create an AP group which has no VAP, and enable wired-AP on the second port assigning VLAN963.
then bring a dedicated dual Ethernet port AP (here is the additional cost), configure it as remote and assign it to this group.
5- Connect the second port of the dedicated RAP to switch port 20.
Now the user who connects to the <bridged-ssid> and their device must be onboarded, AAA server shall enforce the VLAN963. The traffic of this VLAN will come from the controller in a tunnel to the dedicated RAP, then to the switch, then to the RAP and finally to the user who will be treated as wired user.
Note: Don't try to use the same dedicated RAP for broadcasting the same <bridged-ssid> because captive portal will not work; that's why it is dedicated and that's why I said: additional cost.