Our organization license is good for 3 more years.  Bought a new device & license.  The device got claimed, but the license wasn't applied some how.   SAML org admin's don't get email notifications for non compliance licenses. We were on with tech support the week before for an hour with no mention that there was a device out of compliance. This is an absolutely terrible business practice and I doubt it will change based on what any of the customers say.  ... View more

They kill your network across the board in the middle of the day.  Your devices become paper weights. ... View more

beyond the 30, you will be cut off in the middle of the day.  That's what happened because the org was licensed through 2027, but the one device license was purchased but not applied.  Why you can claim a device and not the license bought together is beyond the understanding of the meraki licensing support engineer. ... View more

Also note on orgs that use saml logins - you need to leave yourself as a regular organization admin with an alias email address in order to get notifications about licenses.  Meraki just turned off our organization that is licensed till 2027 because a device was added to the dashboard but the purchased license was applied.  The only notice that is sent is to the non saml org admins. ... View more

I'm aware of that - but the lack of the ability to allow global services like Office365, CloudFlare, etc, while still blocking other countries is a problem.  It was the main reason we looked at other platforms before renewing our Meraki subscription.  The pain of troubleshooting blocked countries (singapore, netherlands, australia) interfering with Office 365 and Microsoft services is less headaches than the configuration of a competitor's product.   ... View more

I'm glad you figured out a work around.  From what I had been told, there is no allow layer 7 rule in the underlying fw engine.  We have faced this challenge since adopting Meraki in 2016.  I tried to block everything outside of 2 countries, in the process I broke the internet - as most of the CDN's including cloudflare stopped working.   ... View more

I agree.  If we had required faster uplinks, we would have replaced the Meraki's with another firewall.  Fortunately we don't need the extra bandwidth, so it doesn't matter for our use case.  But the companies that make their own chips are able to offload some CPU intensive things to ASIC chips.  That is the way that all manufacturers should be headed and hopefully Cisco will instead of trying to cram everything into an intel system on a chip.  Hardware $ for $ Meraki is far from competitive.  But the software is what makes us stick around.  Too bad the software stack can't run on another large brand's hardware, then we could FortiMeraki or MerakiGate.... UnifiMeraki....  ... View more

@StosSpiro wrote: Also, based off of my case with Meraki that I worked with them last night, when you whitelist a client (Allow List), the SaaS based app is able to load the sign on screen.   This and packet captures from the client is how we troubleshoot things like these as well.  Just remember to move the client back to Normal and not leave them on Whitelist. ... View more

@MarcAEC wrote: I use https://www.iplocation.net/ to compare.  It shows the results from 5 different Geo IP databases.  When MaxMind has been wrong, I've used the results from iplocation.net to support my case.   For example, the two sites RickA @putt4show  is having trouble with, http://ontargetrange.com/ (192.124.249.67) and https://officesolutions.com/log-in/ (192.124.249.110), are showing as Singapore in MaxMind, but iplocation.net is showing them in the United States in all 5 databases. The SUCURI.net service resolves to 192.124.249.22 - so it seems like maxmind just misclassified that whole block 192.124.249.0/24   Sucuri seems to be a large player in the WAF / website security space - so not as bad as blocking CloudFlare or Akamai - but still big enough to make a dent.   We typically block hong kong and Singapore - and will add them back after this MaxMind issue is resolved. ... View more

@StosSpiro wrote: @Warren - This exactly what is occurring in my network. This wasn't an issue prior to the GEO IP issue.      That is what we found as well - even though it's in the USA according to another source   Or tracert it.   49 ms 33 ms 15 ms ae12.cr2-was1.ip4.gtt.net [89.149.130.157] 20 ms 20 ms 20 ms ip4.gtt.net [173.205.46.86] 20 ms 20 ms 21 ms cloudproxy10022.sucuri.net [192.124.249.22]   MaxMind thinks 173.205.46.86 is in Austin TX and 89.149.130.157 is in Germany - so clearly they are wrong. BrightCloud (WebRoot) says 89.149.130.157  is in Washington State, which lines up with the was1 in the url.   All in all though it's been a long time since we have seen major services interrupted by the GeoIP filter.       ... View more

@MarcAEC wrote: I've sent this "wish" in multiple times over the last few years.  It feels like "Make a Wish" just goes direct to /dev/null.  😞 While Account Reps and Support claim that "Make a Wish" has an impact on what is developed, there are tons that we have put in that we haven't seen any progress on in 5 years and pretty much don't expect it.  If it's a small UI tweak then I think it's likely.  If it's a functionality request - don't hold your breath.  AnyConnect support (Ikev2) had been wished for years before there was any progress.   ... View more

We are also seeing a security solution - SUCURI - show up as Singapore from MaxMind - but USA based on trace routes and ipaddress.com -- when SUCURI is blocked, this messed with the certificates on numerous services.  Not sure how they play a role in cert verification.     ... View more

@DBlum wrote: Can you let us know who your geolocation vendor is and see if they have a lookup tool? URL/IP Lookup | Webroot BrightCloud This is what it was before - so I presume it still is. ... View more

If I am blocking an entire TLD it is typically after seeing IOC's from a phishing campaign or seeing something similar in the environment.  For example if I know our company doesn't need any websites that are .xyz I would block *.xyz proactively.  I don't know if the Meraki MX would have blocked some things, I block them anyway.  I have a block first approach instead of an allow first approach.     So if I see a phishing campaign using a lot of .bbb domains I will just block *.bbb instead of just the ones the bad actor is using.  Sure if eventually a user has a customer that uses .bbb and we need to allow it, then we allow that one.  This does add some detective work when a site won't load. ... View more

We use a different DNS filter solution to handle some things at the dns level.  Then use URL and category filtering as the second layer. When you see threats emerge you can block them at DNS before they ever get to the Meraki Content filter.  Umbrella is one option for DNS filtering - but there are others on the market.  It depends on how much time, money and complexity you want in your environment.  If you are looking to keep things under one roof, then look at Umbrella.   ... View more

I would block those tld's in your DNS filter or the Meraki Content Filter Content Filtering - Cisco Meraki ... View more

Other common Office 365 urls can be found here - https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges   They have this as a web service as well - but Meraki hasn't bothered to add it as something to easily allow.  ... View more

Better now than never... right?   We will be replacing the mx 84 with the mx 95.  The Mx 105 looks nicer but the jump in license cost isn't worth it for us. ... View more

the tunnel has to be connected, and the cmd prompt run as admin.  It has always persisted for us. ... View more

We just use the netsh command  - replace ConnectionName with whatever you named the connection and 127.0.0.1 with whatever subnet you want to go out over the vpn. netsh interface ipv4 add route 127.1.0.0/24 "CONNECTIONNAME"   For split tunnel vpn client config we have also found that changing the metric on the vpn connection to 1 or 2, you can usually get DNS queries to still go over the VPN (if that is desired) - assuming the dns server is on the subnet you are adding the route for. ... View more

I just looked at the RV340 - it wouldn't work for our situation. But it can use Any Connect - which Meraki can't. ... View more

Sure - upon reading it again though - the packet by packet solution works only when you have a device at both ends (i.e. site to site), doubtful it works on the internet. It works by sending the traffic on one link and forward error correction packets on the second. Then it puts the stream back together in the right order. They claim they can use the forward error correction packets as well on a single link. I've not tried it. ... View more

@GreenMan wrote: Yes - it could be up to 300 secs  https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover Other SD-WAN solutions failover on a packet by packet basis for comparison. ... View more

We have an MX84 and a 300/300 connection.  We have thought of going to Gigabit, as it's $20/month more.   The MX84 will be the impediment and we have looked at other brands.  There are other brands offering similar feature sets for similar price ranges that can do a gigabit connection.   I'm probably going to buy the gig connection anyway, as it's trivial in increased expense.  It will help with cloud backups but that's about it. ... View more