Mainly now getting this source to one of our endpoints - a23-210-14-48.deploy.static.akamaitechnologies.com ... View more

Email response from Meraki support this morning:  After taking a further look into the IDS/IPS alert seen, we do not believe it to be a false positive as the reason it was flagged is because it matched a signature. If you believe this traffic to be safe, you can feel free to whitelist it by clicking the signature and turning whitelist to ON.  ... View more

Just got response from support - Absolutely, we can take a look to see if these events you are seeing are false positives. I will investigate further from my end and let you know my findings. ... View more

I had opened a case with Meraki support - here are their 2 responses so far. I replied to them that others are having same issue and to escalate case with support..I'll report back what they say.   What you are seeing here are the reported security events by IDS/IPS and AMP. The events that you referenced have been blocked by IPS from the network. Please read here for more information about the security center events: https://documentation.meraki.com/MX/Monitoring_and_Reporting/Security_Center   The IDS/IPS SNORT algorithms takes care of identifying if a traffic pattern is potentially malicious, and it seems that it labeled that traffic as such. If you believe it is safe, you can feel free to whitelist them and they will then be allowed.  ... View more

6-14-2023 - 1,008 alerts - 6-15-2023 - 1,017 alerts.   The MX having this issue just updated a few days ago to firmware MX 18.107. Before that update this issue did not exist.   So far this morning, no new alerts, however the 2 destination endpoints that were affected are not online yet..so we'll see. ... View more

Also seeing a lot of these - a23-210-14-33.deploy.static.akamaitechnologies.com ... View more

No, these alerts are mainly coming from our Columbia, Missouri office MX ... View more

Seeing a lot of these too -    vip0x008.map2.ssl.hwcdn.net   209.197.3.8:80 ... View more

Having same issue with all (4) of my MX's - View failed to load. ... View more

So an update, I sometimes add IOC IP addresses that are C2 to our Meraki Content Filtering / URL Filtering list.   I was testing VPN connection from home last night and got an error from http://wired.meraki.com:8090 blockng IP address - 13.107.4.52   I checked my URL list and saw that IP had been added by me earlier in the day, I removed it and bingo VPN connection stayed connected. Virus Total has mixed reviews on this IP, see below. Cisco Umbrella Investigate shows safe as well.   https://www.virustotal.com/gui/url/20991264dd712bc59c82126e951fb8f22a9cec3021a4f08f62da4e925db29f86 ... View more

So an update, I sometimes add IOC IP addresses that are C2 to our Meraki Content Filtering  / URL Filtering block list.   I was testing VPN connection from home last night and got an error from http://wired.meraki.com:8090 blockng IP address - 13.107.4.52   I checked my URL list and saw that IP had been added by me earlier in the day, I removed it and bingo VPN connection stayed connected. Virus Total has mixed reviews on this IP, see below. Cisco Umbrella Investigate shows safe as well.   https://www.virustotal.com/gui/url/20991264dd712bc59c82126e951fb8f22a9cec3021a4f08f62da4e925db29f86 ... View more

This describe your issue as well?   So getting feedback from my users, anyone that did not do fresh VPN connection attempt in last 2 hours or so is still connected to VPN fine and can access the shared drive on our network. Any new connections get connected very briefly then dropped. Some get an error, some don't. Has to be an ongoing issue with Meraki MX firewalls since issue just started in last few hours. ... View more

No, not reached maximum addresses. Don't think client IP range is applicable here. Issue is this afternoon users can't make new connections to VPN, we use radius server for authentication. ... View more

so getting feedback from my users, anyone that did not do fresh VPN connection attempt in last 2 hours or so is still connected to VPN fine and can access the shared drive on our network. Any new connections get connected very briefly then dropped. Some get an error, some don't. Has to be an ongoing issue with Meraki MX firewalls since issue just started in last few hours. ... View more

We are having similar issues, users connect to VPN but can't access shared drive back on HQ network..never been an issue before..user having issue is running windows 11, looking to see if windows 10 users are having same issue.. ... View more

My notes show it was late July this year the exact same thing happened. ... View more

So at this point with my MX84 threat protection set back to prevention and Meraki removing the Snort rule, should we remove the whitelist rule for 1:60381 in our Intrusion detection and prevention? ... View more

After adding whitelist for Rule ID 1-60381 it's showing null not sure if that means it's working.. however I turned IDS back to prevention just as a precaution, did not want to leave on detection, so far desktop Outlook staying connected, VPN connections not dropped. ... View more

I added whitelist for Rule ID1-60381, can anyone confirm if then putting threat protection back to prevention from detection (a temp fix this morning) will not break connections again..?  thanks ... View more

I had our MX84 set to detection temporarily from prevention, are you saying I could put back to prevention then turn on whitelist for Rule ID1-60381 ?  thanks ... View more

Same issues here only our MX84 is affected by these IDS Microsoft Windows IIS denial-of-service attempt Blocked Outlook on desktops, blocked RDGateway server access, VPN.   Setting the MX84 to detection from prevention is a temporary fix. Actions are now being logged as allowed, most destinations are Google Maps, Amazon CDN's, etc. ... View more

We had same alert on our MX firewalls wsasme.exe SHA25654fd619d136646c014ca6e270e4a483dce033894c918a462b5a0352290ce95db   Disposition - Malicious | Type - MS_EXE | Size - 5657272 bytes   Ticket I had open with Meraki, response this morning:   Thanks for your response. Yes, I can confirm that you can trust Webroot and wsasme.exe is not a malicious file. Please ignore the alert, and I will close the ticket at this time. Thank you, Kunal Konduru Cisco Meraki Technical Support   Webroot Support response yesterday:   The reason that Joe Sandbox lists for their "Suspicious" file determination (hooking functions) is normal for an Antivirus program. Cisco appears to be marking wsasme.exe as a threat for the same reason, however only Cisco support would be able to confirm this. If you have any further questions about this false positive, we recommend reaching out to Cisco support.   Regards, The Webroot Advanced Malware Removal Team     This is a legitimate Webroot file. Please reach out to Cisco support for further assistance with this false positive.   Regards, The Webroot Advanced Malware Removal Team ... View more