Thanks for the tip.   However, every time Meraki breaks something on the Stable channel, I'm told to upgrade to the Stable Release Channel or Beta channel for a fix.  Does anyone else see a problem with this?    I do realize that there are few options other than downgrade or upgrade or workaround, but please stop breaking "Stable".  That's what the other release channels are for.  ... View more

l7_firewall, not content filtering...   syslog...   May 11 11:13:08 72.198.16.239-1 logger <134>1 1652285588.003245509 appliance l7_firewall src=192.168.40.37 dst=208.67.222.222 protocol=udp sport=53082 dport=53 decision=blocked   Meraki Support Engineer...   "The Layer 7 blocks for OpenDNS (208.67.220.220) appear to be due to the fact it is being classified as advertising. Unfortunately, the workaround for misidentified traffic is to remove the corresponding rule which you have done. Alternatively, Meraki Support can roll the network back to 15.44 which uses a different method for identifying traffic." ... View more

@HealthPrime wrote: L7 has broken lot of stuff it blocks 8.8.8.8 but category is blank , i have a ticket open but no time frame  for resolution for L7 NBAR issues reason its managed by Cisco and not meraki Cisco owns Meraki, but this will never be an acceptable excuse, regardless.  I'm on "stable" firmware.  It should be "stable"...meaning it doesn't break things that used to work.  ... View more

Context...   Subject: RE: Cisco Meraki Case 08036081: layer 7 FW completely broken and [ ref:_00D606uBw._5006Q1pmBUt:ref ]   Hello Craig, Thank you for reaching out to Meraki Technical Support. I have added the information from this case to an internal tracker so our engineering team is aware of this issue. The Layer 7 blocks for OpenDNS (208.67.220.220) appear to be due to the fact it is being classified as advertising. Unfortunately, the workaround for misidentified traffic is to remove the corresponding rule which you have done. Alternatively, Meraki Support can roll the network back to 15.44 which uses a different method for identifying traffic. If you would like to proceed with the rollback, it would require a call to Meraki Support during the maintenance window. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Network-Based_Application_Recognition_(NBAR)_integration Kind Regards, Austin Conley Network Support Engineer .:l:.:l:. Cisco Meraki     ... View more

See my reply to CptnCrnch.  I don't expect anyone that doesn't work for Meraki to be able to help.  I'm ranting (or complaining), yes, but also warning, and hopefully shaming.  Or should I just through all my complaints in the "make-a-wish" well?  ... View more

Clearly, I'm ranting.  I'm not sure what more context you would need, but there is no help anyone that doesn't work in Meraki engineering can provide. Support already provided some work-arounds (not to be confused with a solution). Roll-back firmware or disable the rule. BTW, I'm on a "Stable" release. Some might also refer to it as a "customer complaint"....you know...since this really, really expensive product simply stopped working as advertised.  I now suspect it's due to a botched rollout of NBAR in version 16.x of the firmware.  So, basically poor quality control, testing, etc. Someone was just so excited to roll it out, they didn't bother to test it properly, I guess.  I'm also warning any would be customers that are smart enough to read forum posts before a purchase.  The Layer 7 firewall does not work as advertised and is clearly broken.   I'm also, hopefully, shaming someone at Meraki, but those are high hopes, I realize.  ... View more

Yes, it's the L7 Advertising rule classifying OpenDNS as "Advertising".  I'm not using Umbrella.  ... View more

You're right, I meant Destination...but you're focusing on the wrong part of my Fun Fact. 🙂  ... View more

To be fair to the tech, he did offer me 2 work-arounds (which also could have been communicated in a notification vs. making me waste an hour of my life).  I can downgrade the firmware or allow Encrypted P2P traffic.  Neither of these seem appealing to me.  ... View more

That’s correct, the state-of-the-art phone system at Cisco disconnected me after 20 mins before a person ever picked up.   I had no complaints with the person that answered.  I rarely do.  He was just doing his job the best he could.    My problem (other than torturous hold music), is that after wasting an hour of my time on hold and losing just a little more sanity, the tech tells me that “it’s a known issue with no ETA”.  Again, not the tech’s fault.  It’s the fault of his management for not notifying users about known issues. Seemingly a no-brainer, support-delivery-101 practice that would save everyone lots of time and frustration.   The dashboard and/or push notifications from the app would both be great places for this information…a-la Microsoft Message Center.   As for the call timing, I was essentially “live blogging” that experience, so you can just look at the time stamp of my first post (that’s shortly after I was disconnected).   As for the hold music, just go ahead and pick up the phone and call yourself.  It’s like the same 8 bars (if that), on a 20 – 30 second loop, over and over and over again.  It’s quite maddening.   You might as well be playing “Pop Goes the Weasel” or some other ice-cream truck classic.    I’m glad someone at Meraki is paying attention today, but forgive me if I don’t hold my breath.   I first brought this up about 3 years ago (in the forums) and was assured then by a Meraki employee that they were going to look into it.  They agreed with me that it was super annoying.  Never heard back from them.   BTW, don't even get me started on the ultra-rude, time-wasting practice of using noreply email addresses to correspond so that I have to come back out to the forum and log in vs. simply replying to your email....community-noreply@Meraki.com. Because, what I really need in my life today is yet another login.  ... View more

From now on, I think when I do get a Meraki support engineer on the phone, I'm going to play my own obnoxious repetitive loop in the background...for the entire duration of the call.  ... View more

That's not gonna be good enough for me.  🙂  I mean, my god, how much does it cost to add like a whole song...or two, instead of that obnoxious 20 second? loop?  I'm convinced it's intentionally obnoxious and repetitive with the obvious goal of getting people to hang up. Whoever's making this decision is either incredibly cheap or sadistic, maybe both.    And how hard would it be to schedule callbacks instead of forcing people to tortured on hold?  I mean, much smaller organizations with a fraction of Meraki's resources seem to be able to offer callback options, why can't Meraki be bothered to do this?    ... View more

I find that email responses tend to drag out much longer.  For the money we pay:   1. we should be able to get someone on the phone within 30 mins or less, and I'm being generous.  2. not be psychologically tortured with hold music 3. not be abruptly disconnected 4. not be told after all that, that yes, it's a known issue, no eta   Why doesn't Meraki implement some kind of notification system like Microsoft has.  It could eliminate so many calls and so much wasted time, for us and for Meraki.  Just mind boggling.   ... View more

Edmond, OK, USA ... View more

45 mins later, someone finally answers... ... View more

Including Meraki's own "Cloud Communication" traffic, apparently....sigh.  On hold for support for 20 mins and was simply disconnected.  Thought I'd come out here and take a look.  Glad we pay the big bucks for "enterprise support" vs. having to DYI on the forums.   May 04 12:39:32 98.173.248.218 logger <134>1 1651685972.152202720 FER_Office_appliance l7_firewall src=192.168.128.105 dst=209.206.63.216 protocol=udp sport=45253 dport=7351 decision=blocked May 04 12:39:32 98.173.248.218 logger <134>1 1651685972.205257006 FER_Office_appliance l7_firewall src=192.168.128.20 dst=209.206.63.216 protocol=udp sport=48040 dport=7351 decision=blocked ... View more

"Modern operating systems use a number of tracking prevention methods that can resemble the behaviour of many hosts behind a single NAT IP. Therefore NAT detection may also cause alerts for legitimate traffic that may not be related to NAT.  It is recommended to tune the alert frequency to a suitable value for your network, then investigate to determine whether further action should be taken."   So, it might be real, might be false positive...and we're supposed to go investigate them all?  I'm not sure this is very helpful.  ... View more

I think the song is called "My First Casio", composed by "some managers 4th-grade child".  ... View more

Don't hold your breath.  I asked for this several years ago.  ... View more