ExtremeControl - Issue - Unexpected NEAP ReAuth

[Guilhem_Lejeune]

Hi,

Devices involved :

• ExtremeCloud IQ Site Engine version 24.2.15.5
• ExtremeControl version 24.2.15.5
• Fabric-Engine 5420F-48P-4XE version 8.10.5
• Windows PC

Windows PC first authentication is OK (we use 802.1x PEAP MSCHAPv2).

After 10 minutes, ExtremeControl sends RADIUS CoA Disconnect message to reauthenticate the PC.
The problem is, ExtremeControl receive NEAP Access-Request and the PC is placed in quarantine.

Of course, I expect EAP Reauth.

Troubleshoot actions done :

• Deactivate NEAP auth on acces port (on the switch) : OK but we want to keep the port configuration as generic as possible.
• Force Windows supplicant to do 802.1x EAP only : OK but there are some side effects when the PC is back on a non-NACed network.

Maybe CoA message sent from the NAC is malformed ?

Here the reauth parameters for the switch :

Do I have to fix something ?

Regards

[Ryan_Yacobucci]

Hello,

By default there is a 10 minute session timeout for quarantined devices. 

Right click the NAC --> Engine Settings --> Reauthentication

There is also an "Accept Session Timeout" that can be enabled, has this been enabled? 

I agree with Robert here, it would be a good idea to get a tcpdump of the reauthentication as well as enabling debug for "Reauthentication" and we can take a look at why the initial reauth was issued.

Thanks
-Ryan

[Robert_Haynes]

Unclear why CoA is triggered after 10m from initial 802.1x authentication; however yes confirm that Control and switch time are synchronized.

The default for the model you reported is RFC 3576 - Generic CoA Colon Delimited so unclear why it is manually set in override.

This said if the authenticator supports CoA and triggers a re-authentication of the session it should result in a EAPOL Start or ResponseIdentity upstream to the supplicant to trigger 802.1x. Is this happening? Is the client responding to that request? If the client is not then the traffic from the client will be enough to trigger NEAP. Do not know if there is some holddown timer or priority on VOSS to wait for dot1x before moving forward with NEAP.

I always recommend tracing these type of issues if they are reproducible. Client (supplicant) <-> authenticator trace and authenticator <-> Control trace to see the interactions afoot.

[Zdeněk_Pala]

Check the time (NTP) on switch and Access Control Engine.
Check the shared secret for your CoA.

Or use default SNMP instead of RFC3576
I know switch supports both, but SNMP works better in some scenarios.