| Solution |
Refer to this link to learn about Aruba IAP_FNAC integration:
Wireless 802.1x Authentication Workflow:
- When a wireless client connects, depending on the supplicant configuration, the device will use either EAP-PEAP or EAP-TLS for authentication.
- During the authentication process, the wireless client (supplicant) and the authenticator (Aruba IAP) exchange packets using EAPOL protocols over the air.
- The Master IAP in the cluster forwards all EAPOL packets encapsulated within the RADIUS protocol, along with necessary RADIUS attributes, to the FortiNAC server.
- Once authentication is successful, the client is initially placed in the ISOLATE user group.
- The FortiNAC derives the necessary NAC policies and, to place the client in the appropriate VLAN, triggers a COA (Change of Authorization) disconnect to the Aruba IAP.
- The Aruba IAP sends a COA-disconnect acknowledgement, disconnects the wireless client, and stops RADIUS accounting for that client.
- The client reconnects, completes the 802.1x process again, and this time is pushed into the production VLAN with the appropriate Aruba user role, passed as RADIUS attributes.
Root Cause of the Issue:
- If the Calling-Station-ID is set to use the IP address on the Aruba IAP, the AP will send the MAC address of the client during the initial 802.1x authentication.
- The client is pushed to the ISOLATE user role and receives an IP address from the isolation scope.
- When FortiNAC triggers the COA, the Aruba IAP sends another RADIUS access request, but this time it specifies the client’s IP address in the Calling-Station-ID attribute.
- The FortiNAC relies on the client’s MAC address for tracking. Since the MAC address is not present in the RADIUS access request, FortiNAC logs an error, such as 'GetClient: Client NOT found for MAC [xx:xx:xx:xx:xx:xx]', and pushes the client back into the ISOLATION VLAN in the RADIUS access accept message.
Logs:
yams.RadiusAccess.A4:B5:CF:57:28:21 CONFIG :: 2024-06-25 14:14:19:537 :: #543 :: -- User-Name = [Fortinet\test4] (RadAttr Type=string)
yams.RadiusAccess.A4:B5:CF:57:28:21 CONFIG :: 2024-06-25 14:14:19:537 :: #543 :: -- Virtual-Server = [Proxy] (RadAttr Type=Virtual-Server)
yams.RadiusAccess.A4:B5:CF:57:28:21 FINE :: 2024-06-25 14:14:19:537 :: #543 :: [Post-Auth] Preprocess Started - Parsing request endpoint context data (Proxy)
yams.RadiusAccess.A4:B5:CF:57:28:21 FINE :: 2024-06-25 14:14:19:537 :: #543 :: GetClient: Client NOT found for MAC [A4:B5:CF:57:28:21]
yams.RadiusAccess.A4:B5:CF:57:28:21 FINE :: 2024-06-25 14:14:19:538 :: #543 :: Create Rogue for MAC [A4:B5:CF:57:28:21] on device ManagedElem: A-LH-BX-AP05-VIP (10.11.40.5) [ID=70]
yams.RadiusAccess.A4:B5:CF:57:28:21 FINE :: 2024-06-25 14:14:19:541 :: #543 :: PersistRoamingClient: Updating client 5449
yams.RadiusAccess.A4:B5:CF:57:28:21 FINE :: 2024-06-25 14:14:19:541 :: #543 :: 802.1x Auto Registration: true
Solution:
Ensure that the Aruba IAP's are configured to use the client mac address as the Calling-Station-ID to avoid this issue.
For instructions on how to do this, see the Aruba documentation.
|
