ā01-09-2020 07:18 AM
Hi all.
Iām wondering how āAP awareā feature is supposed to work. Is anybody using it and could share how it should be configured and intended to be used?
Thanks,
Flavio.
ā01-10-2020 01:52 PM
Hi Brian - thanks for your reply. Are you the Brian Anderson who is involved in a FortiNAC setup in Switzerland?
F.
ā01-09-2020 09:56 PM
When you configure the policy with the āAP Awareā setting and you look at the CLI configuration on the switch youāll see an āAuth-Overrideā flag on the end of the policy configuration.
A policy with āAuth-Overrideā flag will result in a termination of all existing policies on the switch port, and no additional clients will have a session established or be authenticated on that switch port. All traffic will essentially pass through that existing policy session that was created with the auth-override flag, so as already explained the policy with āAP-Awareā enabled must allow all necessary traffic (802.1q VLANs) to clients behind the AP.
Double auth causes issues with residual policy sessions (If two policy end points are configured to āUnregisteredā for captive portal when NAC re-authenticates it canāt change both policies at once so one will stick around and cause a portal loop), re-authentication storms, and confusing end system events. Youāll see stuff like iphones on a wired port. As Brain indicates, generally not a pleasant experience.
ERS/VSP has a similar technology called āMHSAā Multi-Host Single Authentication that is similar.
ā01-09-2020 08:20 PM
Flavio, yes you are on the right track. You can authenticate your APs with mac auth, if you utilize NAC, then this is done with an end system group. Setup the role the APs to use with AP-Aware, setup your vlans you want tagged on your tagged egress list on your role and when an AP is plugged in, it authenticates and the AP-Aware setting only allows one device to auth, which would be your ap. If you didnāt use AP-Aware, clients in a bridged at AP topology would also try to authenticate and it would be a battle of authentication between wireless controller and wired switches, not a pleasant experience for the end user.
AP-Aware also works with 3rd party APs, doesnāt have to be Extreme APs.
ā01-09-2020 02:36 PM
Hi Flavio,
if you use 802.1X on your switch port and you have an Bridge@AP topology, then you can see all wireless clients MAC addresses on the switchport, too. Meaning: if you have your AP connected to port 1 on your switch you will see the MAC address of the AP as well as several MAC addresses of all WiFi clients connected to that AP.
The switch now ātriesā to authenticate all wireless clients, too - even though they are already authenticated by the AP. Meaning: your clients would be authenticated twice - once on the AP and a second time on the switch. This (of course) is quite stupid and just introduces more issues.
Therefore you enable the āAP awareā feature in NAC. If āAP awareā is enabled only your AP gets authenticated via 802.1X on the switch port and not the wireless clients. AP aware (sort of) turns off 802.1X once your AP has been authenticated on the switch.
Kind regards
Christian
ā01-09-2020 09:40 AM
Hi Ron, thanks for explaining.
I do dot1x in fact on all my switch ports, and until today I did exclude the ports where an AP is connected from dot1x authentication. I configured statically the untagged VLAN for the control/management traffic of the AP and added the tagged VLANs for the SSIDs (Bridge@AP topology used).
The WLAN clients actually authenticate via dot1x on the WLAN, but I also do have some PSK SSIDs. I know donāt really understand how I would apply the āAP awareā feature in my scenario: what should the role do, besides āAP awareā enabling? And if Iād like to be able to connect an AP wherever I want, I would authenticate all APs with MAC address and assign the correct untagged and tagged VLANs to that port with a role specific to APs? Am I on the correct path?
Thanks,
Flavio.