Also been dealing with these bogus usage spikes for weeks now on several of our MX's, where client traffic does not come close to what the GB usage shows in alert. Latest ticket response I recieved:   Greetings, Thank you for your patience while our engineering team worked to resolve this issue. Our engineering team has advised there is a fix available for this issue on firmware 19.4.1. There will also be a fix available on 19.2 but this is still being worked on at this time and not yet available.   Thank you, Meraki Technical Support ... View more

Received this feedback from support:  Thank you for your response. I believe you are running into another issue which engineering is investigating for false traffic spikes to appear on the graph. This does not truly represent actual client data seen on the network. Our engineering team is tracking this and they are working on a fix. I'll make sure to update you accordingly as I get updates from engineering. Thank you, Meraki Technical Support  ... View more

  anyone else experiencing this, clients page sorted by usage shows clients with high down, in screenshot shows 45.66GB but if you click on the client, and sort, it does not reflect the high usage...? ... View more

I am logged into n178. All of the circle charts for each network are empty. If I click on the client now I do see some traffic, but the data usage is always way off. It can show it super high data usage for download and upload, but the traffic details for the client do not reflect it.. ... View more

OK, so I’m not the only one. I have a ticket open with Meraki support. I can’t believe they don’t have anything in the Meraki Status website that mentions this.. ... View more

We were going on 8 years of running those 3 MX's we replaced. ... View more

Not sure, did not check that. How do you check an MX's utilization? ... View more

Wow, 2026, might have jumped the gun then.. My thought was just since firmware updates had reached EOL that I did not want any lapse in security to be our downfall. And again, odd that after I upgraded all those rogue IP's showing allowed, now show blocked, maybe a coincidence.. ... View more

MX64, MX64W, MX84 could not go past 18.200.  Now using MX 67, MX67W, MX95 ... View more

I also received those IP's.  However I recently replaced 3 of my firewalls that could no longer could receive firmware updates, and now the Zyxel unauthenticated IKEv2 command injection attempt and Zyxel unauthenticated IKEv2 overflow attempts that have been plaguing our MX's since February now show blocked instead of allowed..so I guess getting these MX's up to the latest MX 18.211.2 version allowed the  Intrusion detection and prevention to block..strange.   ... View more

Our MX95 looks to be allowing VPN connections now, we were down for awhile this morning with users getting L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer. ... View more

yep, got those as well, added to my layer 7, layer 3 deny list, crazy. ... View more

I guess they are admitting marking a threat as allowed is Standard Operating Procedure if the threat contains packets that were dropped before they were dropped onto network LANS..again we as customers are not privy to how the back end works with Meraki IDS, we just know malicious IP's are attempting to hit our MX WAN's and their IDS is showing action as allowed, so as IT folks when do we know when it's an actual threat or a false positive..that should not be on us. ... View more

Yes, received that one as well. At this point we are over 6 months since I started this thread for these allowed attacks. There has been several explanations from Meraki support stating these attacks are not actually getting through to the LAN. I just think the allowed action is going to continue the concern for customers that have not seen this thread yet.   Zyxel unauthenticated IKEv2 command injection attempt Zyxel unauthenticated IKEv2 overflow attempt ... View more

New IP that hit one of our MX's with (2) WANS 185.16.39.29:500 ... View more

Thanks for the heads up on this one, I don’t get my alerts of what was blocked or allowed until the morning so I logged in and added this IP to my layer 3 & 7 deny rules. ... View more

I agree, wasn't until a recent response from someone in this thread that their Zyxel IP hits showed blocked as opposed to allowed like all of mine that I don't completely think these rogue IP's are truly being blocked. I just keep adding the IP's to our layer 3 & 7 rules as deny and hope for the best..too many other security vectors to focus on, Meraki needs to address this ASAP, it's out of my control as to how IDS works. ... View more

We had same IP's hit one of our MX 193.177.182.40:500 149.50.116.115:500 185.224.128.74:500 ... View more

The only thing is, some customers are seeing the action on these IP’s as blocked and customers like me and quite a few others are getting an allowed action, how can that be explained? ... View more

This matches my list. Since these IP's are affecting numerous customers, is there not a way Meraki can add these IP's to their own block list, since the bad actors seem to be targeting Meraki MX devices..? ... View more

We run all 4 of our MX's in prevention mode and security ruleset as well. 3 of our 4 MX's are running MX 18.107.10, the 4th one is running 18.211.2 as it is a newer MX. I have ordered MX replacements for our MX84, MX64, MX64W due to them not being able to update to firmware 18.200 and above. ... View more

Latest IP addresses that show destination to our public WAN IP's as action of Allowed for Zyxel IKEv2 overflow attempt and command injection attempt..I know in the past Meraki support has stated these attempts aren't actually being allowed to pass onto our LAN, but still concerning. I've added blocks on layer 7 and outbound layer 3 ... View more

Go back into - Threat Protection / Intrusion Detection & Prevention / click X under Actions for the rule / save changes ... View more

Response I got:   Thank you for contacting Cisco Meraki support. There is an issue with the new SNORT update and as a workaround for now, please whitelist the rule. We are working to get this fixed as soon as possible. Thank you for your patience and co-operation. ... View more