Bad destination MAC ADDRESS

Meraki-User-713
Comes here often

Bad destination MAC ADDRESS

Hi,

 

I have "Failed Authentication" with this client: da:0e:xx:yy:zz:ae

A pcap file indicated a bad AP which try to reply: e6:cb:bc:ff:gg:hh but this bad AP mac address is not in a rogue AP list.

My legitimate AP has this MAC address: e0:cb:bc:ff:gg:hh

 

How could we explainedAP-bad-mac-address.png that ?

 

Regards,

7 Replies 7
KarstenI
Kind of a big deal
Kind of a big deal

A random device tries to authenticate against a neighbor AP and fails authentication.

Inderdeep
Kind of a big deal
Kind of a big deal

Check mac address here 
https://miniwebtool.com/mac-address-lookup/ 

Seems like a random device

Regards/Inder
Cisco IT Blogs awarded in 2020 & 2021
www.thenetworkdna.com
KarstenI
Kind of a big deal
Kind of a big deal

These MAC addresses can't be looked up; they are randomized.

Meraki-User-713
Comes here often

Hi,

 

Is there a way similar to the process used to blacklist rogue AP in order to block this random device ?

Would not that be the best to make an ACL which authorize legal radius server and block all the others ?

 

About rogue APs, please find the attached file, which illustrates the fact that a MAC address asssociated to block list is still see in rogue APs ?

 

Regards,rogue-AP_not-consider.png

 

 

 

Up until now, I understood your question that neither the client nor the AP is one of yours. What exactly is the problem?

Meraki-User-713
Comes here often

Clients are mine. 

 

My problems are those ones:

- 1°) we have few rogues AP which appear (even if they are quoted as rogues APs)

- 2°) it seems that we have rogue radius server which try to authenticate users.

From the image that was shared in the previous comment, the highlighted MAC address is the BSSID MAC that matches one of your own BSSID MACs broadcast from one of your Meraki APs. Placing this BSSID MAC on a blacklist could impact a client's ability to join your legitimate SSID as well. A Spoofed AP can only be found with a boots-on-the-ground approach so to say.

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Mitigating_a_Spoofed_AP

 

If we place a MAC in the block list for containment it is not going to stop the rouge AP from being detected or broadcast it is going to send deauthentication requests when a client attempts to communicate with that BSSID MAC. 

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal#Containment

 

As for a rouge Radius server attempting to authenticate users, we'd need to further verify what radius server is observed to be rouge and compare that server's IP address to what was configured for the Radius SSID. APs will only send radius requests to the configured servers so If there was a rouge radius server observed there would also likely be a duplicate IP address attempting to impersonate a configured legitimate server. 

Meraki does not have a feature to only allow or block specific radius servers as the request is already only going to go to the specified radius serves it would not attempt to send a radius request to an address that is not configured. 

 

If you take a capture on the AP's wired interface and observe it sending raduis request to an address that is not configured on any SSID then a support case should be opened. 

Get notified when there are additional replies to this discussion.