Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Become a member of the Cisco Meraki Community today
Get answers from our community of experts in record time.
Join nowAbout NordOps
NordOps
Getting noticed
Member since Jan 29, 2018
2 weeks ago
Community Record
28
Posts
33
Kudos
0
Solutions
Badges
Feb 6 2025
11:25 AM
I agree on the partner documentation and or the presentations I've been on, with the focus on co-term. I haven't really seen any official guidance from Cisco on how to move customers from PDL to subscription.
... View more
Jan 26 2023
1:12 PM
Thank you @PhilipDAth, really appreciate the response. I thought so too but it's always good to see if others are seeing the same thing!
... View more
Jan 26 2023
12:55 PM
I am sorry if this has been posted before, we're seeing this error on multiple Azure vMX's, multiple regions. I've checked and there are no outbound firewall rules applied. I am not sure 100% how these tests are performed but is anyone else seeing the same issue? I'd like to make sure the vMX's we manage aren't going to be impacted by back end changes but I am not sure what else to try on the Azure side if it is as Cisco says a Azure issue. This is the error on the dash: Our automated tests show that you have one or more Meraki devices unable to reach our platform on IP address ranges 216.157.128.0/20 and 158.115.128.0/19. After January 28, 2023 our platform may begin using these address ranges for connectivity. Some of your devices will have a degraded experience after this time, unless upstream firewall rules are changed. You can view devices that are failing connectivity tests in the “Firewall Test Failures” section on the Firewall info page. For more information, please review our documentation. Last update on a Support case says that , "Upon further investigation, I have pushed the case over to our development team as the vMX is displaying unexpected behavior. However, production should not be hindered by the issue at hand. Functionality should remain consistent and unbothered. As of now, we have an internal case between me and our development team. Once we have a solution, this will be pushed and you will be alerted. If you have any further questions please reach out!" The Case number is 09135628 I am not sure if that means the testing won't impact the vMX but there are still issues or if it's just a false positive (this test and alert) so would like to check with the community if others are seeing that on their Azure vMX's?
... View more
Jul 26 2022
2:06 PM
Thanks for the feedback. Some of the webroot documentation seems to point to that URL so I think it's just an AMP update that flagged the files disposition as malicious or maybe it didn't like that the computers were trying to run executables from a website.
... View more
Jul 26 2022
1:39 PM
2 Kudos
Any Webroot users out there seeing issues with AMP? We've received new information from the Advanced Malware Protection (AMP) cloud about 1 file downloaded on your The following files were determined to be malicious in retrospect: File Hash: 54fd619d136646c014ca6e270e4a483dce033894c918a462b5a0352290ce95db (link) Download Info: The AMP alert shows a wsasme.exe file on webroot's site. I opened a case to see if its a false positive but we've had a few customers that got flagged around the same time.
... View more
Mar 11 2022
12:57 PM
We just had a couple customers that called in having problems to specbooks.com Nslookup reveals Non-authoritative answer: Name: specbooks.com Address: 74.208.210.187 Aliases: www.specbooks.com This tool classifies that IP block as Russian https://www.maxmind.com/en/geoip-demo Other tools do not NetRange: 74.208.0.0 - 74.208.255.255
CIDR: 74.208.0.0/16
NetName: 1AN1-NETWORK
NetHandle: NET-74-208-0-0-1
Parent: NET74 (NET-74-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS8560
Organization: IONOS Inc. (11INT)
RegDate: 2006-11-22
Updated: 2017-08-09 Anyone experience false positives with the geo filtering? Would be nice to have the Content Filtering take priority over the Geo-Filtering but wondering if anyone else is having problems with it today. This seems to have just started today.
... View more
Sep 24 2021
10:10 AM
7 Kudos
Just adding feedback based on some of the comments from other users here about how to improve things so they could be identified easier in terms of using the geo filtering. Allow geo blocking with the ability to add a site or IP to the "allow" even though the rest of a country is denied. That way it's not all or nothing if there is legitimate traffic in a country you want to block. geo blocking dumps should dump to the event log like content filtering and malware so it can easily be identified. The ability to sync geo rules / firewall rules throughout the organization with Configuration sync would be nice. Maybe 3 can be done through the API's but I haven't played with that yet.
... View more
Sep 24 2021
6:56 AM
4 Kudos
Just a suggestion or "making a wish". If we could add something to the whitelist that overrides the geo filtering that would be a super useful feature. Block a country but allow this website would be a huge enhancement for security too.
... View more
Aug 6 2021
5:59 AM
2 Kudos
One other suggestion. This isn't the first time there has been a backend cloud issue and when you call in and wait on hold forever it doesn't help anyone's patience. It might go a long way to announce an issue like this before putting the call into the support que. Being able to call Meraki support easily is one of the best features, but being on hold for 45 minutes waiting to talk to someone while back end issues are being worked on by engineers is extremely frustrating.
... View more
Dec 17 2018
6:20 PM
11 Kudos
We've found it useful to just allow certain countries rather than deny a huge list.
... View more
Jul 23 2018
7:35 PM
Thanks for this info, I noticed you referenced your case below. I gave that to support since they haven't been of much help. What I've noticed (Site to Site to vShield VMware firewall) with third party VPN - Internet on both sides up - Third party firewall is in a private cloud with multiple carriers - Meraki Auto-VPN's don't drop - I can kick the tunnel off by booting the Meraki - It recovers on its own after about 8 minutes - Event logs always have "Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed due to time up" but nothing really useful. Thanks for referencing your case I hope that helps and they dig something up
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 11 | 36533 | |
| 7 | 49438 | |
| 4 | 51799 | |
| 2 | 3758 | |
| 2 | 47277 |
© 2025 Cisco Systems, Inc.
