Ah so you are having issues pinging out?  Any difference if you ping the IP directly vs name to make sure it isn't a DNS issue? ... View more

Security Appliance > Firewall   When you setup the Public IP to LAN IP NAT you have to set the allowed inbound connections rule to: Protocol: ICMP Remote IPs: Any or a subnet if you want to be more specific on who can ping.  ... View more

Run a cable test, also bouncing the port usually brings it back.  But probably still a cable issue.   ... View more

Try setting ip igmp query-interval 25 to see if it helps.  ... View more

I'm not fully understanding your request but the MS425 should have 2 or 4 10G SFP+ Fiber ports according to the data sheet. https://meraki.cisco.com/lib/pdf/meraki_datasheet_ms400-series.pdf   I typically only purchase Meraki Fiber SFP's to ensure compatibility and supportability. https://meraki.cisco.com/lib/pdf/meraki_datasheet_sfp.pdf ... View more

Sorry I'm having trouble fully understanding your topology and goal in this request.   Are you using the Meraki DHCP for this public SSID?  And do you have Wireless>Firewall & Traffic Shaping rule for that SSID set to Deny Any Local LAN?  If those above two options are set then it shouldn't really matter what Vlan you are on unless you are trying to do any kind of special routing to send it out a different path.   ... View more

I haven't tested this, but under Wireless>Access Control.  Then select your SSID.  There is a section for Content Filtering that may give you the settings you need?  I think you can opt out of Content Filtering or use Custom DNS.   ... View more

How many devices do you guys have impacted by this? I have 3 MX84's and one MS350 which happens to be at our core (most important switch in our network).  Blah.  ... View more

We don't but that is certainly interesting to know and I'm sure other members here could benefit from that fact.  ... View more

I've done 12.26 on two of our MX100's and no reboot issue so far (been a few days). ... View more

Philip is right.  One to Many NAT is just for incoming on your internet ports.  An example of where you'd use it is if you wanted to have incoming traffic on different ports going to different servers.     For example 1:Many NAT Public IP 8.8.8.8 (this would be one of your public IPs) TCP 8000 to LAN IP 10.0.0.1 TCP 61500 to LAN IP 10.0.0.2   So if someone goes to 8.8.8.8:8000 they land at your 10.0.0.1 server port 8000 or whatever you map it to if someone goes to 8.8.8.8:61500 they land at your 10.0.0.2 server port 61500 or whatever you map it to.   ... View more

We had a similar issue to this and went round and round.  Replaced the AP.  Moved it to other ports on the switch.  Had the cable tested and was told repeatedly that it was good.  I even bought a cable tester and tested the cable myself and the pinouts were good.  But inevitably the AP would go down.  Intermittently.   Did and RMA and the new AP did the same thing.  Finally I plugged the AP directly to the same port on the switch using a small patch cable in the rack and was able verify if it was the run going to the AP.  I had the installer pull a new cable and the AP has been rock solid ever since.  May not be your issue but POE stuff can be finicky.  Could be a small nick in the cable or running over florescent lights.  Lots of factors that are all worth considering.  ... View more

A big differentiating factor is licensing.  Licenses type is applied at the Organization level.  In our case we have one building that needed an MX without Advanced Security so we had to put it in a different organization.  Otherwise we just use networks the same as everyone above.  Mostly one network per physical building or site.  All live in our company Organization.   ... View more

It would be nice to see this as a column for all devices.  We had an issue where a switch was regularly rebooting.  The switch would come back online before our 5 minute downtime alert would trigger so we had no idea the issue was happening until users reported it.   ... View more

This article has some helpful details that we used when doing a similar configuration to you.   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Recommended_Configuration_for_Trunk_Link_to_Non-Meraki_Switches ... View more

Thanks I'll put in a ticket to ask.  ... View more

Any way to see the uptime on an MX? ... View more

Probably not a best practice but we keep ours at "Always use 100% power" for the Radio Power settings. We had similar issues to you in the past. One other issue we observed due to our overlap in our wifi is if someone walks with their laptop from one part of the building to another. Sometimes their computer will try to hold on to its connection to the farther AP since it still has some signal, albeit weak, rather than switching to the closer AP. Usually they just have to turn off wireless and then turn it back on and it'll connect to the stronger/closer AP. But it doesn't sound like this is your CEO isn't moving. ... View more

We use MX64's at most of our branch offices.  They have been solid for up to around 40-50 users.   ... View more

May also be worth going to Wireless>Radio Settings to check the transmit power.  If set to auto it could be lower if it detects stronger AP's nearby.   ... View more

Are you running the Network Policy and Access services from your Domain Controllers or from a standalone server?  Have you considered making a dedicated Radius server to decouple your Network Policy Auth from your AD servers?  That way you can update your DC's to 2016 while you troubleshoot the Auth issue? ... View more

Would be nice if we could manually push firmware to individual switches starting with the ones the furthest into our network and working back up to the core to avoid this.   ... View more

Isn't upgrade windows under Network Wide>General?  And I think it is just used for automatically scheduled firmware upgrades (ones scheduled by Meraki).  I spot checked a few of mine and it seemed accurate.  Obviously you'll want to check your network timezones as well since that could have an impact.  And also factor in lag time for the devices to download the firmware and actually apply it.  So many devices reboot after the scheduled time depending on how many there is.  Here is the description of the upgrade window from the dashboard.   "Meraki releases new firmware approximately once a quarter. When new firmware is released, your network will be scheduled for an upgrade, and you will be notified 2 weeks in advance via email. Once scheduled, you have the option to reschedule. While installing a firmware update, Cisco Meraki devices continue to operate normally until they reboot as the final step in the upgrade process. The reboot takes 1-2 minutes, so it is best to pick an upgrade time with minimal expected network usage."    ... View more

Not formally announced but looks like we have a 12.26 now.     Bug fixes Fixed a case where WMI login events were not updated Corrected an issue where active FTP flows would fail when routed through the MX Security fixes CVE-2015-3138 CVE-2017-11108 CVE-2017-11541 CVE-2017-11542 CVE-2017-11543 CVE-2017-12893 CVE-2017-12894 CVE-2017-12895 CVE-2017-12896 CVE-2017-12897 CVE-2017-12898 CVE-2017-12899 CVE-2017-12900 CVE-2017-12901 CVE-2017-12902 CVE-2017-12985 CVE-2017-12986 CVE-2017-12987 CVE-2017-12988 CVE-2017-12989 CVE-2017-12990 CVE-2017-12991 CVE-2017-12992 CVE-2017-12993 CVE-2017-12994 CVE-2017-12995 CVE-2017-12996 CVE-2017-12997 CVE-2017-12998 CVE-2017-12999 CVE-2017-13000 CVE-2017-13001 CVE-2017-13002 CVE-2017-13003 CVE-2017-13004 CVE-2017-13005 CVE-2017-13006 CVE-2017-13007 CVE-2017-13008 CVE-2017-13009 CVE-2017-13010 CVE-2017-13011 CVE-2017-13012 CVE-2017-13013 CVE-2017-13014 CVE-2017-13015 CVE-2017-13016 CVE-2017-13017 CVE-2017-13018 CVE-2017-13019 CVE-2017-13020 CVE-2017-13021 CVE-2017-13022 CVE-2017-13023 CVE-2017-13024 CVE-2017-13025 CVE-2017-13026 CVE-2017-13027 CVE-2017-13028 CVE-2017-13029 CVE-2017-13030 CVE-2017-13031 CVE-2017-13032 CVE-2017-13033 CVE-2017-13034 CVE-2017-13035 CVE-2017-13036 CVE-2017-13037 CVE-2017-13038 CVE-2017-13039 CVE-2017-13040 CVE-2017-13041 CVE-2017-13042 CVE-2017-13043 CVE-2017-13044 CVE-2017-13045 CVE-2017-13046 CVE-2017-13047 CVE-2017-13048 CVE-2017-13049 CVE-2017-13050 CVE-2017-13051 CVE-2017-13052 CVE-2017-13053 CVE-2017-13054 CVE-2017-13055 CVE-2017-13687 CVE-2017-13688 CVE-2017-13689 CVE-2017-13690 CVE-2017-13725 CVE-2016-9840 CVE-2016-9841 CVE-2016-9842 CVE-2016-9843 CVE-2016-5131 CVE-2017-3135 CVE-2017-3136 CVE-2017-3137 CVE-2017-3138 CVE-2016-10087 CVE-2016-2217 CVE-2016-8864 CVE-2016-2776 CVE-2016-2775 CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8618 CVE-2016-8619 CVE-2016-8620 CVE-2016-8621 CVE-2016-8622 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 CVE-2016-6304 CVE-2016-6306 CVE-2016-6303 CVE-2016-6302 CVE-2016-2179 CVE-2016-2181 CVE-2016-2182 CVE-2016-2180 CVE-2016-2178 CVE-2016-2177 CVE-2015-8899 CVE-2017-3731 CVE-2017-3732 CVE-2016-7055 CVE-2016-10002 CVE-2016-10003 CVE-2016-9131 CVE-2016-9147 CVE-2016-9444 CVE-2016-7922 CVE-2016-7923 CVE-2016-7924 CVE-2016-7925 CVE-2016-7926 CVE-2016-7927 CVE-2016-7928 CVE-2016-7929 CVE-2016-7930 CVE-2016-7931 CVE-2016-7932 CVE-2016-7933 CVE-2016-7934 CVE-2016-7935 CVE-2016-7936 CVE-2016-7937 CVE-2016-7938 CVE-2016-7939 CVE-2016-7940 CVE-2016-7973 CVE-2016-7974 CVE-2016-7975 CVE-2016-7983 CVE-2016-7984 CVE-2016-7985 CVE-2016-7986 CVE-2016-7992 CVE-2016-7993 CVE-2016-8574 CVE-2016-8575 CVE-2017-5202 CVE-2017-5203 CVE-2017-5204 CVE-2017-5205 CVE-2017-5341 CVE-2017-5342 CVE-2017-5482 CVE-2017-5483 CVE-2017-5484 CVE-2017-5485 CVE-2017-5486 CVE-2016-10229 Known issues When content filtering is enabled, in some cases websites may be erroneously blocked if the IP address they are hosted on has been previously associated with malicious behavior. This is an issue for CDNs and server farms that host many web resources from a single IP address. This is resolved in MX 13.3. Networks with many flows may experience increased latency every 60 second seconds. This is resolved in MX 13.3. In a rare case, MX64W and MX65W platforms may induce notable delay to network traffic. This is resolved in MX 13.4. Google Safesearch and Restricted YouTube content are only available using a deprecated implementation. This is resolved in MX 13.6. During device boot up, an MX operating as a one-armed VPN concentrator may map received AutoVPN and Teleworker VPN flows to an incorrect flow state. This will prevent tunnels from being established using that flow. This issue does not occur after the one-armed concentrator has fully booted. This is resolved in MX 13.8. HTTP file downloads that have the content_encoding flag set will allow subsequent downloads on the same HTTP connection to bypass Advanced Malware Protection (AMP) inspection. This is resolved in MX 13.9. In some cases, MX84 appliances will not forward BPDU messages appropriately during device boot. This can result in an incorrect downstream spanning tree topology. This is resolved in MX 13.9. MX appliances with AMP enabled may become unexpectedly unable to communicate with the AMP cloud. When this occurs, the MX will drop files that a disposition cannot be obtained for. The majority of these occurrences are resolved in MX 13.12. In very rare cases MX65 and MX65W platforms stop forwarding inter-VLAN, WAN, and VPN destined traffic until a device reboot is performed. This is partially resolved in MX 13.9 and fully resolved in MX 13.12. In rare cases, whitelisted URL patterns can still be blocked by content filtering. This is resolved in MX 13.18. On networks with a very large number of flows, MX appliances may induce packet loss in 15-minute intervals. This is resolved in MX 13.19. ... View more