In your Layer 7 Firewall Rules make sure the following is not present: Deny # Peer-to-peer # All peer-to-peer Deny # Peer-to-peer # Encrypted P2P   I've also had to remove: Deny # Peer-to-peer # Encrypted P2P # eDonkey Deny # Peer-to-peer # Encrypted P2P # eDonkey Static Deny # Peer-to-peer # Encrypted P2P # Encrypted eMule (dDonkey & Kademlia) ... View more

When I originally set up the Layer 7 rules, I thought it would apply to internet traffic only, not traffic between clients and servers within the local network.  Has it always been like this, or is application to internal traffic something new-ish?  IMO, this makes the lack of the ability to add layer 7 allow rules even worse. ... View more

Had Encrypted P2P / Statistical Peer-To-Peer start blocking WMI traffic between severs today.  At least we know now to check the Meraki event and security logs first when when things start randomly failing, ... View more

The latest Meraki eDonkey attack was blocking DNS forwards from spoke DNS servers to the hub DNS servers.  I had turned off eDonkey on the spoke templates, but hadn't changed the hub settings.  Now it's off at the hub as well.    Interestingly, the templates have 5 L7 Peer-to-peer options.  A non-template MX has 29 options.  I wonder if the sites attached to the template have more than eDonkey disabled since I can't select the "All peer-to-peer (P2P)" option for them. ... View more

I ended up taking out the eDonkey layer 7 rule (so now down to 4).  I doubt that eDonkey is in use much these days, but not being able to contact the email server is a big deal. ... View more

The devices are on 16.16.5.  And there are 5 separate P2P layer 7 rules (BitTorrent, DC++, eDonkey, Gnutella, Kazaa), instead of a single "All peer to peer" rule due to the MX NBAR blocking Statistical Peer-to-peer traffic  incident. ... View more

To me, it can't be stable if a known issue is the increased risk of instability.  That's a known issue of beta software. ... View more

Is this a "stable" release or not?  It can't be stable and have a known issue of "...an increased risk of encountering device stability and performance issues on all platforms and across all configurations." ... View more

It's really disappointing that Meraki didn't push out a fix when the details of this first emerged.  Instead, each customer whose email was nonfunctional was left to figure out the problem and manually add a threat protection override.  What's the point of something being in the cloud if the vendor can't act fast when there is an obvious and serious problem?   The irony is that the vulnerability allows someone to conduct a denial of service attack, and the result of Meraki protecting from it is a denial of service. ... View more

Let's not forget that this problem is really an example of a deeper problem.  The Merkai development team likes to design functionality that has broad effects without including a way for customers to implement exceptions.  The NBAR problem would be much smaller if there was a way to create ALLOW rules for confirmed mis-identifications.  Instead, it's an all or nothing choice.  This is the same problem with the geographic filtering.  Need to access one specific site in Russia?  Guess what --you need to allow all inbound and outbound traffic from the entire country.  ... View more

The list of "Current Modems" that are "...are still actively being manufactured, distributed, and sold..." is now officially empty.  ... View more

Alex, if you have access to the product team, could you find out why they are so resistant to updating L7 to support exceptions.  This has been a big problem with geo-filtering for years.  When MaxMind decides 8.8.8.8 is in Iran, we can't put in a rule that exempts 8.8.8.8 from geo-filtering.  Instead, we have to allow all traffic from Iran!   ... View more

No, but if the software vendor's fix makes a material change to the functionality, that should be documented in release notes.  The most likely fix that support is implementing is to cause "statistical P2P" to be excluded when "All P2P" is selected.  If that's what they're doing, they should disclose that versus saying "don't worry, trust us". ... View more

The disadvantage with support doing something behind-the-scenes is there's no visibility that "All P2P" is excluding the statistical P2P.  Your successor may not know that's what's going on. ... View more

The real solution (which we won't get) would be for Meraki to implement an exclusion function.  Do we know what we're losing by having Statistical P2P off?  What does it protect against when it is not blocking false positives. ... View more

Are you sure they just didn't exclude "Statistical P2P" from the internal rules when "Deny All Peer-to-Peer" is selected, the same as we could do by creating individual P2P rules for the other categories? ... View more

For years, Meraki has received feedback about the problems the lack of whitelisting for geo-blocking causes.  So, not only did they ignore that feedback, but then decided to build the same problems into the NBAR and the layer 7 rules.  😫   The best work-around I could come up with was to remove the rule to "Deny All Peer-to peer (P2P) and replace it with 5 rules to block BitTorrent, DC++, eDonkey, Gnutella, and Kazaa.  It seems the problematic rule for our legitimate applications is "Encrypted P2P". ... View more

With VOIP, if the internet circuit the call is using goes down, the call would probably drop.  If the internet circuit you have at the hub is more reliable, I'd recommend setting up the VOIP traffic to go to the hub even when the local DIA circuit is online (unless there is a large geographical distance that would cause the latency to be too high).  That way when the DIA circuit goes down, the VOIP traffic will not change how it is connected to the provider.  VOIP traffic typically has its own VLAN.  So, you'd use the source-based routing feature introduced in 15.x for that instead of the IP-based technique discussed in this thread. ... View more

I would think this would happen automatically.  If WAN1 goes down, the MX will automatically try to send the traffic over WAN2.  I've got a use case where I'd like to block that, and couldn't find a way to do it. ... View more

I've not seen that comment in the 15.x or 14.x release notes. It first showed up in 16.4.  It reads like conditions that cause instability have been identified and the development team just hasn't gotten around to fixing them.    They already put a generic disclaimer at the top of alpha and beta release notes.  That's enough.  They don't need an additional disclaimer in the Known Issues section. ... View more

So if you have two WAN uplinks, you can connect a Meraki MG to one of the free LAN ports and it will function as a cellular backup? ... View more

Actually, this is likely not possible for the OP.  Since Meraki has stopped certifying USB modems years ago, it's almost impossible to buy one that would work because all of the certified models are EOL.  Updating the firmware to allow one of the RJ45 ports to be used as a cellular fail-over port would be a decent consolation for customers who buy MX devices believing USB cellular fail-over is still a realistic feature. ... View more

In the rules I have set up using this method, the next hop IP is (normally) pingable.  So, that's not a problem.   I haven't had a chance to try source-based routing because Meraki broke netflow in 15.x and didn't fix it until 16.x.  From the documentation, it looks like source-based routing will handle some use cases nicely.  The rule applies to an entire VLAN.  So, if you want VOIP traffic to egress via a specific MX, it should work for that.  But if you want all of your internal web site traffic to egress via a specific MX so that marketing can exclude it from the visitor stats, I don't think source-based routing will work because that traffic is going to be mixed with the traffic in the normal data VLAN. ... View more

@GiacomoS,   If something sits in a queue for years, it's the same as being ignored.  All of NordOps's suggestions are good and should be moved to the top of the list.    https://community.meraki.com/t5/Security-SD-WAN/Google-com-incorrectly-Geolocated/m-p/129887/highlight/true#M32400   Many of us have requested #1 and #2 years ago.  Years = deaf ears. ... View more