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

[Zdeněk_Pala]

Hi,

if you do not want the “Guest” feature then you can:

• configure NAC to answer for all phones (end-system group or OUI) with VoIP policy/vlan
• combine the above OUI and device type (have in mind that the device type is detected after the first successful authentication )
• configure NAC to answer for all other MAC auth requests to reject

It is very flexible = you can define what behavior you want and where...

[Anonymous]

Hi Zdenek,

Thanks for replying.

Wow, right, not obviously ever occurred to me, but makes sense.

In addition (as you allude too) we could turn off MAC auth on the port altogether, but think they use phones for that, unless we can get them to do some kind of 802.1x also?

I’ve used CEP authentication with phones before in EXOS, maybe use IDM to get data into NAC…..clutching at straws now…..

Be good to have an EXOS command that simply overrides the ‘Guest’ feature, with a reject staying as a reject until link state - maybe a feature request?

Now I know the reason its easier to think of ways to overcome it.

Much appreciated.

Cheers

[Zdeněk_Pala · Accepted solution]

Hi Martin.

IMHO it is FAD for many platforms. E.g. on EXOS you have both MACauth and Dot1x running at the same time. On Cisco you have MAB following the Dot1x fails

The reason for this behavior:

• imagine guest will connect to your network and the guest does have a supplicant configure for his network. Authentication will be rejected (your network does not have credentials for that guest). You still want to provide the guest with the captive portal.

If you want different behavior then you should configure the NAC to reject MAC authentication based on some criteria

I hope it helps.