802.1x rejected then being approved via MAC auth

[Anonymous]

Hi All,

I’m sure this one is easy and is starring me in the face or missing something.

The screenshot below shows a 802.1x client being rejected as intended. The authentication is being proxied to an external RADIUS server.

What then seems to be happening is the end-system is getting on the network via MAC auth, and then hitting a rule as designed. But what is really meant to happen is the reject is meant to mean a reject when authenticating the first time around until the port state changes, thereby stopping access based on the failed 802.1x authentication.

Apologies I don’t have the exact versions of firmware to hand, but can get if required, but XMC running version 8.3 and EOS on the switches

The port is configured to do 802.1x / MAC / Web authentication.

My understanding here might not be completely right, but I’m expecting EAPOL traffic between the client and the switch, and on a RADIUS reject from the Authentication Server to the Authenticator (switch) the port should be denied access, and this looks like what seems to be happening from the screenshot and wireshark captures taken from NAC. 

So I don’t understand if the supplicant is configured for 802.1x then only EAPOL traffic should be sent between it and the switch, how is able to pass traffic for the switch to be able to do MAC auth - does that mean this is a client issue, if so, being a Windows machine, what setting might correct it?

Many thanks in advance

[Anonymous]

Thanks Ryan, and Zdenek,

Will try and give these a go a report back if the suggestions helped.

Cheers,

Martin

[Ryan_Yacobucci]

Hello Martin and Zdenek,

I want to say that we should have a setting on the EOS to get the desired behavior without rules engine creativity, but I can’t say that I’m 100% confident.

A couple things you may be able to try: 

1. EoS defaults with “auth-optional”, meaning that if authentication is not successful it has no bearing on the port. Potentially “auth-required” may change the port behavior to not pass traffic if a reject is received.
    
2. Multi-auth mode set to “strict”. 
   I think that in this setting we will not attempt multiple types of authentication. If there is an 802.1x supplicant and we see EAP on the port we won’t attempt MAC auth. That way when EAP fails (Maybe add auth-required here) we’ll not attempt MAC authentication and not pass traffic.
   
    

Just throwing some ideas you can try to get the behavior you’d like, can’t say for sure if either of these will do the trick.

Thanks

-Ryan

[Zdeněk_Pala]

HI Martin.

you are correct. if the upstream radius does reject then AccessControl Engine does pass reject to the radius client (switch/AP/VPN).

I would handle MAC authentications locally => you can fully control it by ExtremeControl configuration.

We can create workflow/script that will automatically reject MACauth if the dot1X reject is received by upstream radius server, but I am sure the customer will not like this solution as it may have consequences (guest access, the wrong password entered, expired certificate...). How would the customer want to recover from such a situation? like one reject will stop MAC-auth but when it will start again?

[Anonymous]

Hi Zdenek,

Thanks for the info.

Think the customer was trying to be a little more blunt with the configuration, because they are using RADIUS proxy they wanted a reject from their RADIUS server to be a reject and stop there. As the reject is coming back at the authentication stage it doesn’t then pass to the NAC rule engine to do what you mentioned above.

Suggested a couple of things i.e.

• Put in an authentication rule to allow local authentication and then pass directly onto the rule engine.
• Have the External RADIUS server return an accept with a ‘Filter-ID’ that matches a deny rule.
• Disable MAC auth on the port (believe this isn’t an option in their case)

Maybe there is a couple more ideas?

So I can hopefully contributing something helpful back too, what you describe is typically how I would configure things, a separate rule for each MAC auth device. With MAC auth being a weaker authentication I will apply an explicit ‘deny all’ and then just allow only what its trying to do.

I add whitelists in to bypass the deployed rules, just in case something doesn’t work because of a missed rule restriction. Also roll out piecemeal by just added switches to the ‘Production Switches’ as and when each area is moved. If they didn’t hit that they would just hit the catch all rule.

Once all migrated I either changed the catch all rule to deny traffic, or put them onto a guest network.

Would that be a similar’ish approach to what you would take?

Thanks