Hi @PhilipDAth, thanks for the comment. The Named VLANs documentation is currently private due to the private preview but we plan to open it up in the coming months.  In a nutshell - Named VLAN profiles work along with 802.1X RADIUS authentication to assign authenticated users and devices to specific VLANs according to a VLAN name rather than a integer number. This can reduce the configuration burden on the RADIUS server by allowing fewer authentication policies to be used for multiple sites which may use different VLAN ID numbers for the same functional group of users and devices. ... View more

Hello everyone, thank you all for your contributions to this open thread. We appreciate your continued feedback, and this remains our #1 priority.   While we have made steady and promising progress, our work is not complete.  We plan to have a Switch-15 Release Candidate version available within the next few months and this version will build on the improvements we made in 15.14.2 and additional fixes and enhancements. We highly recommend that MS390 users upgrade to this version as soon as it is available. It will be the highest-quality release yet for the product and we expect it will get promoted to GA soon after.   As always, should you encounter any issues with your Meraki MS390s, please reach out to Meraki support for assistance. We appreciate your patience as we work towards the Meraki standard of excellence our customers expect. ... View more

Hello everyone, the MS Product Management team wanted to provide a direct update regarding stability issues some of you have reported on the MS390 platform.    We want to start by acknowledging that a higher than usual number of customers have experienced software quality issues with their MS390 switches recently. These issues revolve around instability in the Meraki management plane that can result in sporadic or complete loss of connectivity to Dashboard, until the switch or stack is rebooted. While this typically does not impact traffic, know that  at Meraki, any product quality issue of this kind is not acceptable; we always strive to delight our customers through reliable and dependable technology.    The entire MS product and engineering organization understands the challenges customers impacted by this problem are facing, and have made it our top priority to execute on a plan that restores high quality, reliable software on this platform. While we work towards that goal, it’s important to be transparent with our customers. Our teams have been hard at work addressing issues in recent beta firmware releases (MS15). We have already seen measurable improvements in both stability and a significant reduction in case load, but not all issues have been resolved, and this remains our top priority until every customer affected by the problem is satisfied. .    Our current recommended firmware version for customers experiencing stability issues on MS390 is MS 15.14.1 and subsequent beta versions will continue to further stability improvements. We will continue to provide updates as we have them. Should you encounter any issues with your Meraki switches we recommend contacting Meraki support. We genuinely appreciate your patience, and will continue to strive for the excellence and stability that our customers have come to expect from Cisco Meraki. ... View more

Awesome project! Thanks for sharing! ... View more

Hi Kenneth, MI has changed quite drastically in the past few months with a revision of the UI, the introduction of WAN Health as well as Alerts. I would highly suggest engaging your Meraki CSE and getting a trial to see the latest and greatest it has to offer.  ... View more

@NolanHerring is correct. This document has a section explaining how to use 3G/4G as the primary uplink for a device:   https://documentation.meraki.com/MX/Cellular/3G_-_4G_Cellular_Failover   As mentioned it is highly recommended to use a WAN connection for the initial setup/configuration of the device before using Cellular as the main link.  ... View more

Take a look at the meraki.io site. This is a concentration of solutions created by both Meraki and customers that all take advantage of the APIs. This page specifically talks about Location Services and gives examples of some integrations already in use:   https://create.meraki.io/guides/location-services-solution-guide/ ... View more

I see that those 2 clients were last seen this morning. If you made that change after that I would reset the wireless network connections on those clients and give the dashboard some time to reflect those changes. ... View more

@PhilipDAth is correct, you are specifically viewing the client capabilities.    To identify what a channel width a specific client is using navigate to the Network-wide clients page and add channel width to the menu options. ... View more

This sounds like the perfect use case for Wireless Health. This should help you quickly identify the root cause Association, Authentication, DHCP, DNS, etc. It will also help you identify if certain APs are experiencing more issues than others as well as different device manufacturers. This feature should have been enabled on your dashboard within the last week or so.    Here is the document: https://documentation.meraki.com/MR/Wireless_Health   ... View more

@Mr_IT_Guy, you bring up some valid points. Unfortunately at this time, the MX does not support mapping group policies via Active Directory for users connecting through the Client VPN.   What you can do however is create a firewall rule on the MX blocking the Client VPN subnet from accessing the sensitive internal subnets and/or only allowing specific access. You could apply it at the overall FW page and it would then apply to all VPN clients. OR you could create a Group Policy and then apply it to specific devices. From my testing Group Policies assigned to Client VPN devices are persistent because this is tied to a virtual mac address that has a hash of the username that is logged in.    Really depends on the level of security you want to put in place. Having an overall FW rule blocking the Client VPN subnet requires no administrative intervention.  ... View more

Hello, just a quick point on the 2nd item you brought up. If you want to block a VPN user within the dashboard why not also deactivate their VPN access at the same time? This would prevent them from logging out and back into the VPN to bypass the policy.    That would be for a total block which is what I believe you are asking about. To apply a more granular policy then I would move to the RADIUS/NPS policy options @PhilipDAth mentioned.  ... View more

One last ditch, try reaching out to support to see if they can help glean some additional information related to the change that can help you correlate it to an admin.  ... View more

Ok, with that in mind it's tough. Reach out to your admins and ask who made a change.  ... View more

Ah, I think I understand now. You are saying someone went in and blocked your MX mac address from being a DHCP server on the switch dhcp page, correct?   If so, that modification does not appear to show up in the change log but if you caught a glimpse of a change in the event log I would correlate the time with the Login Attempts to get an understanding of who was logged in at that time.  ... View more

If the DHCP relay IP was changed it should be reflected in the Change Log: If a change was made and is not showing up in the change log I would recommend reaching out to support. ... View more

So the change shows up in the change log but without an Admin associated to that change? ... View more

The Change Log would be the spot to identify changes made to the network. You could then cross reference the time and user and look at the Organization -> Login Attempts page to identify the source IP address the user logged in from. ... View more

Hi, you can gain this information by exporting Wireless Event Logs to a Syslog Server https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration   The Even Log for a WPA failure will look similar to this: "Apr 30 22:26:22 192.168.128.1-1 logger: <134>1 1525141582.164315122 MR33 events type=disassociation radio='1' vap='1' client_mac='20:EE:28:56:AA:25' channel='36' duration='4.019999996' auth_neg_failed='1' is_wpa='1' aid='1687101691'"     ... View more

Sorry for the confusion I was not aware this was an external to internal flow. The Firewall rules dictate outbound communication while inbound is blocked by default unless part of an inside->outside session. To specify inbound access you would need to create a port-forwarding or 1:1 NAT rule and then open then specify the connections you want to access.   The port 22 and 23 rules you have in the L7 view above are blocking all 22/23 OUTBOUND. Here is a document that describes the inbound rules and how FW traffic flows:   Blocking Inbound Traffic: https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/Blocking_Inbound_Traffic_on_MX_Security_Appliances   Port Forwarding and NAT Rules: https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX     ... View more

The firewall rules have a policy section which is togglable between Deny and Allow:   ... View more

Makes sense, if that is the only client you want to allow access then you can create an Allow firewall rule specific to that client -> SFTP server. Then deny 22 from any other clients to the SFTP.  ... View more

Sounds like its internal to internal via different VLANs. You could create an Allow rule to allow a specific host or specific host subnet access on those ports to the SFTP server via a FW Rule:   Example:    And then another rule below it to block all other SFTP traffic to that particular server.  ... View more

Hi Wally, inbound connections are blocked by default unless the session was initiated by a client behind the MX. The SFTP you mentioned, can you explain the flow from the client to the server? Is that server external? ... View more