Interface – Aruba OS Equivalent for Default Interface

The way you connected the Controller is technically correct. By using DOT1Q VLAN tags you allow traffic within VLAN 1,2,3,4 to be sent from and to your Controller.

Keep in mind that it might not be necessary to allow all VLANs on the port to the controller (e.g. UserLAN, DevLAN) because you might only need Guest and UserWIFI for WLAN.

Only allowing certain VLANs on a Trunk is called VLAN pruning which can enhance network security and stability.

If this is a large Wi-Fi deployment, you probably want to look at a system based on a wireless controller and LWAPs. The only real experience I have with such a combination is with Cisco. Cisco has a large product line of controllers, LWAPs, and WAPs.

Fortunately, the Cisco devices seem to perform well. There are occasional updates which we thoroughly test if the added features interest us. The wireless controller-based system allows the LWAP updates to be fairly painless since the LWAPs get their software and configurations from the controller.

Using Local mode means that both the management and data traffic are tunneled back to the controller, which can be remote from the LWAP. This has both advantages and disadvantages. The newer Cisco switches (3850, 45xx Supervisor 8, etc.) provide some wireless controller functionality built in to the switch to allow data traffic to be dropped locally. This mode allows for seamless roaming between LWAPs, regardless of subnet/VLAN, without re-authentication.

You could also use FlexConnect mode which only uses a tunnel back to the wireless controller for management traffic, but it will drop data traffic locally. Cisco called this a kludge, because roaming can only happen on the same subnet/VLAN with re-authentication. The switches with built-in controller functions can do something similar to this, on Local mode, without the kludge of FlexConnect mode.