apart from no longer being able to use the combined dashboard.. so everything needs to be configured in 3 places instead of 1... we also noted that since switching to IP the host name of devices are less likely to be identified... and there is no way to add your internal DNS server to Meraki to be able to look it up. we have not seen any "technical" issues... but its just frustrating UI issues ... View more

Why sniff them? why cant we just add our internal DNS server and have the meraki do a revers IP lookup ? what we do manually when trying to identify an IP good old "Ping -a <IP>" ... View more

You are in the same position as we where, except our L3 device was our VPN. Had to split the network and set it to Track by IP Immediately resolved the issue.. but now the dashboard is a PITA to use... we are planning on going global so this is FAR from ideal. An Meraki built in client VPN is trash..no certificate support cannot do Device VPN or always on VPN.. so that even less of an option... Meraki do seem to be pushing "features" rather than stability...  ... View more

apologies it was v18.107 that we tried and had to roll back from... Were your clients behind a L3 device ?? and what tracking method are you using ? ... View more

OK, So We are still experiencing slow website lookup and external service connection timeouts on v18.106 and had to roll back AGAIN!  I have been informed by Meraki support that in our case, we have clients behind a non Meraki L3 device (our VPN)  and are using content filtering, and out client tracking is set to MAC address. (we use combined network dashboards.. like most users) Meraki support has provided us a "solution" (that I don't agree with but get to that later) which is to split the network dashboard and set client tracking to IP address.   If you want to give this a go you can do this by going to Organisation -> Overview  select the network where your clients are behind a non Meraki L3 device then select "Split network"  This reduces manageability so please research this before trying it!   So why is this not really acceptable.. well we have been operating with content filtering enabled with our non Meraki L3 VPN for many many years... no issues... so why all of a sudden do we have to loose all this functionality due to a "Upgraded" content filter???  ... View more

@Jason1 I know its a long time closed post but where you able to resolve this?? ... View more

OK so they think they may have possibly found a bug... needs confirming BUT this is what it looks like from a flow caputre.  We attempted to access a website not in the cache (my local gym of all things) The category look up completed in 27ms (great nice a n quick) however the MX seems to.... ignore the result... waits about 1 second and tries again... it loops like this for about 10 seconds until it finally accepts the category response and allows the connection.   so it does not look like a cloud response time issue.. and more of a MX firmware bug... ill keep you posted when I get an update ... View more

Hey Fucomyoo, I have a case open with Meraki regarding this.. It is the exact same experience we had with version 15 and 16 of firmware when you enabled the "Full list" option in content filtering.   In version 17 there is no option to select "Top list" or "Full List" since they moved from "Bright cloud" to "Cisco Talos Intelligence" so my first thought is that they are now using the process for "Full list" as standard. This heavily leans on the MX cache to speed things up (we are running MX 250) I'm not sure how long the cache TTL is (how long a record stays in the cache) or how large the cache is (how many records are kept until they are cycled in for newer results)   regardless of this though.. its the initial lookup of the site that is slow.. so cache wont make a difference until after the first lookup. As we speak the Meraki support agent just captured a "slow" site lookup... ill keep you posted. ... View more

Also to top it off.. if you use MX250 and IDS IPS set to prevent... do NOT go anywhere near the 16.15 stable RC firmware... it no longer abides by the whitelist for snort rules... so everything gets blocked!! an with no way to unblock it...we experianced this on multiple MX250 recently when moving the Stable RC as advised by Meraki due to ANOTHER issue with their firmware on on the current stable fork... (memory overload causing MX to panic and reboot)  nightmare. ... View more

Its not the Pen Testers that hate it.. its the customers.. as we have to turn off a key security feature to let pen testers do their job... We also have issues with 2 diffrent pairs of endpoints talking across SDWAN... i have MANY time woken up to our reporting system blaring alarms stating Replication of VM has failed... or that Emails are queued up because the mailbox server cannot talk to each other....  It has become a complete joke! literally any issue with have that is remotely related to 2 devices communicating that goes via an MX appliance you can place a pretty firm bet that its IDS and IPS messing stuff up again! ... View more