- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 explained that ?
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A random device tries to authenticate against a neighbor AP and fails authentication.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check mac address here
https://miniwebtool.com/mac-address-lookup/
Seems like a random device
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These MAC addresses can't be looked up; they are randomized.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Up until now, I understood your question that neither the client nor the AP is one of yours. What exactly is the problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
