Hello Sinfo,
On Freeradius you have to configure RFC3580-related attributes for relevant resources, have a look here: https://stuff.purdon.ca/?page_id=279
Regarding wireless, please also consider increasing minimum basic rate to get rid of 11b support if possible, this will reduce the impact of beacons from too many SSIDs: http://www.revolutionwifi.net/revolutionwifi/p/ssid-overhead-calculator.html
Also remember to use WPA2 CCMP, as weaker options do not work with 11n and 11ac rates - but with WPA2-ENT I believe you'll definitely have it in place.
😉
So if you configure AAA Policy on your WiNG controller (and it can specify whether the controller or AP acts as a RADIUS Client - with FreeRADIUS and NPS it is rather easy as you can specify entire subnet for authenticators in one line, so if it is needed there's no problem to have APs acting as NASes).
Authentication handling has nothing to do with WLAN bridging mode (local/tunnel) as it comes before any traffic being allowed. Bridging mode is set per WLAN.
If you want to achieve RBAC with RADIUS-based VLANs, remember to tick the "Allow RADIUS Override" box in basic part of WLAN configuration in GUI (or see CLI example below).
code:wlan TMELABS-DOT1X
ssid TMELABS-DOT1X
vlan 23
bridging-mode tunnel (or local)
encryption-type ccmp
authentication-type eap
radius vlan-assignment <<<<<<
use aaa-policy freeradius-aaa
Wherever you are going to bridge the wireless traffic, make sure to go to the device (APs' or controller's) profile and modify ge1 interface settings so it will have intended VLAN IDs in the list of allowed VLANs. Via CLI it would be:
code:enable
configure
profile ...
interface ge1
switchport trunk allowed vlan [and a list]
commit write
This way (or GUI way) your devices will understand that they can bridge dot11 traffic of a certain user (or certain WLAN at all - no matter if RADIUS is used or not for this prerequisite) and they can accept q-tagged traffic on the wired to possibly pass it to the wireless users that are bound to the VLAN ID.
You don't have to specify SVIs (CLI: interface vlanX) for any VLANs unless it is needed for some purpose (WiNG device acting as a captive portal, DHCP server, default gateway and so on).
Let us know if anything needs further clarification.
🙂
Hope that helps,
Tomasz