Hi Kingoftheday,   In the Meraki Dashboard, "Policy Objects" are used to simply apply a user-friendly label to a specific IP address, subnet, or FQDN. These convenient labels then can be used to help you build out your firewall rules more easily. For example "Deny Any Traffic To/From 'Guest Network' and 'Internal Network'" could be a set of L3 firewall rules on the MX as opposed to needing to remember and type out the exact IP addressing (CIDR notation) for each of the subnets every time.   To start configuring these "Policy Objects" head to Organization > Policy objects from within your Meraki Dashboard portal. Do note that because this is under the "Organization" section, this will require that your Dashboard admin account has Organization-level admin privileges. ... View more

Hi Kingoftheday,   I just wanted to chime-in here and state that we (Meraki) do not have any official tools or solutions for a configuration migration like this and as a result you are using these third-party tools and utilities at your own risk.   That being said, we try to make the configuration of the MX platform to be quite simple and straightforward. As long as you have a high-level understanding of the ASA's current configuration, you should be able to adapt this to the Meraki MX platform fairly quickly and easily.   If you haven't done so already, be sure to read through our "MX Firewall Settings" knowledge-base article to get a full understanding of the configuration options available on the MX platform. You may also find the use of "Policy/Network Objects" to help streamline the configuration of your firewall rules. Additionally, since you mentioned DHCP services being enabled on some VLANs/subnets, I'll also share our "DHCP Services" KB. ... View more

Hi PirateRo,   It is important to note that the MS120 is a simple layer 2 switch and does not support full layer 3 routing, DHCP services, static routes, or anything like that.   By default, DHCP services are going to be contained to their own broadcast domain. Additionally, the use of VLANs would segment your layer 2 network further. Your wired client will not receive an address from DHCP if there are no DHCP services being offered on that VLAN.   Hope that helps! ... View more

Hi GIdenJoe,   This could potentially be an interesting feature request. If you haven't done so already, you can go ahead and submit this by using the "Give your feedback" button located in the bottom-right-hand corner of any Meraki Dashboard portal page. These requests go directly to our product and development teams for consideration.   That being said, a Network Support Engineer should be able to access additional logging that would help in the troubleshooting process. ... View more

Thanks for pointing out some DHCP-specifics here, GIdenJoe.   NoviceInMeraki and GIdenJoe, I would recommend opening up a ticket with our Support team if you feel that you are seeing unexpected behavior with regards to the Dynamic ARP Inspection feature/functionality.   You can view the options for contacting our Support team at the following Meraki resource:   https://documentation.meraki.com/General_Administration/Support/Contacting_Support ... View more

Hi Rohan575,   1. If you don't already have the Systems Manager network created, you can do so by navigating to Organization > Create network from your Meraki Dashboard portal (note: you will need to be an Organization-level administrator with write permissions to perform this task) and selecting "EMM (Systems manager)" as the Network type.   Once created or if your EMM network is already created, you can then combine this Systems Manager network into an existing Combined hardware network by navigating to Organization > Overview, checking the box for both the Systems Manager network as well as the Combined hardware network in which you wish to combine with, followed clicking on the "Combine" button located towards the top of the table. You can read more about combining and/or splitting Dashboard networks at the following Meraki resource: Combining Dashboard Networks (Meraki KB).     2. It is a little unclear to me exactly what you are asking here but if you are simply looking to add a new Meraki hardware device into an existing Combined hardware Dashboard Network, the easiest way to do this would be to navigate to the Inventory page (Organization > Inventory), Claiming the new Meraki hardware device into your Inventory using the "Claim" button if it is not already present within your Meraki Inventory, and lastly, checking the box for the new Meraki hardware device, followed by clicking on the "Add to..." located towards the top of the table where you will then be presented with a drop-down menu where you can select the Dashboard Network that you'd like to add the new Meraki hardware device to.   If instead you are interested in how to add devices to a Systems Manager network, my recommendation would be to start with the following Meraki resource: Systems Manager Quick-Start.     3. For your question around the Meraki Dashboard API offerings, I would recommend taking a look at the Meraki Dashboard API documentation located on Cisco's Developer Hub as there you can find all of the specifics around the exact syntax required, including the available parameters for each API endpoint, examples when used with various programming languages/protocols, etc.   For example, if you'd like to query a specific Dashboard Network in order to see specific clients that are active on that network, the following "Get Network Clients" API endpoint would probably be most appropriate here.   If instead, you are curious about a device that is enrolled/managed within your Systems Manager network, the "Get Network SM Devices" API endpoint would make more sense.     I hope that information helps a bit. Be sure to let us know if I misinterpreted any of your questions. Additionally, we do have an API-specific group here on the Meraki Community which might be able to assist with more technical API inquires. ... View more

Hi Charlie_C,   My apologies for not including those details. I was in fact leveraging the "Default Group Policy" feature/functionality during my testing. I'll post a screenshot of my AnyConnect test configuration below:   ... View more

Hi Charlie_C,   I was able to do some testing with a similar configuration and found an interesting discovery. When initially creating a restrictive "RDP-only" Group Policy within the Meraki Dashboard, I too was having issues with RDP disconnects within minutes of the connection being established.   After further investigation, it appeared that the AnyConnect tunnel was still in tact and didn't seem to have been affected (confirmed from the AnyConnect end-client stats as well as performing auxiliary ICMP tests over the tunnel to the destination subnet).   After doing some Googling, I stumbled upon the following Reddit thread where a user was running into the same issue using an OpenVPN client and a poster responded with suggesting to disable UDP 3389 communication and once I modified my "RDP-only" Group Policy within Dashboard to only allow TCP 3389, the issues appear to have gone away (successfully tested over a three-hour period without any RDP disconnects). It seems as if the Microsoft UDP 3389 RDP bug might be more susceptible over client VPN connections? The poster on the Reddit thread did suggest disabling this through GPO but in my case, simply denying this traffic through the Group Policy in Dashboard seemed to do the trick.   Reddit Thread: https://www.reddit.com/r/sysadmin/comments/e2bhn1/rdp_disconnects_every_5min1hour_over_vpn/   Also, here is what my resulting test Group Policy looks like:     The AnyConnect configuration is set up as split-tunnel, with only the RDP subnet (...30.0/24) as an included route.   I am also thinking that this explains why we saw the AnyConnect client as show up as grey/inactive after a little while since given the highly specific nature of the AnyConnect connection (split-tunnel + only rules allowing RDP, which stopped working) the MX was marking the clients as offline as a result of not seeing any traffic pass through for several minutes. I'll post a blurb from our "Clients Usage Page Overview" KB below:   "Clients appearing on the Clients usage page will display their current status to indicate if they are currently active, as seen below in Figure 1. The activity threshold for a client is one minute. If a client does not pass traffic for longer than one minute, then the client will no longer be considered active. The status icon for an inactive client will appear grey."     I hope that this helps a bit! ... View more

Hi Charlie_C,   I think it would probably make most sense to reach out to our Meraki Support team in order to assist with this configuration and any possible troubleshooting that may be done here. If you haven't engaged our Meraki Support team before you can navigate to Help > Get help from the upper-right-hand corner of your Meraki Dashboard portal, followed by clicking on the "Still need help?" link, and choosing either to submit an email case or to call the Meraki Support team.   Thanks! ... View more

Hi MAUB,   Take a look at the AnyConnect Client VPN options available on the Meraki MX platform. AnyConnect on the MX leverages TLS and DTLS for tunneling and also allows for configurations options such as certificate-based authentication.   AnyConnect on the MX Appliance ... View more

Hi @Kenn_Val18   Based on the error that you provided, my best guess is that the Internet connection that the client is connecting to is blocking UDP traffic 500 and/or 4500.   My recommendation would be to reach out to our Enterprise Support team in order to troubleshoot further with a client/device who is currently experiencing this issue. You can view the Support options by navigating to Help > Get help, followed by clicking on the "Still need help?" link. ... View more

Hi EamonnT,   My apologies for the delay as I was out on holiday.   You did not mention if you are leveraging our Meraki MR product line of wireless APs but if you are, be sure to check and confirm that we are not blocking layer 3 traffic destined for the "Local LAN" by navigating to Wireless > Firewall & traffic shaping from your Meraki Dashboard portal. Then be sure to select the SSID(s) in question from the SSID drop-down menu and see if the first rule in the "Outbound rules" section is set to "Allow" (Destination: Local LAN).   You can read more about how this rule is intended to work at the following Meraki resource:   https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/'Deny_Local_LAN'_settings_in_Cisco_Meraki_MR_firewall   If this is already set to "Allow" for the Local LAN destination, my recommendation here would be to contact our 24/7 Enterprise Support for further troubleshooting. You can view these options by navigating to Help / (Question Mark icon) > Get help from your Meraki Dashboard portal, selecting the "Still need help?" link, and then calling the Meraki Support Team or submitting an email case. ... View more

Hi EamonnT,   You shouldn't have any issues with this desired configuration. Ensure that the SSID is set to bridge mode and is tagging its traffic with the VLAN ID for the 192.168.11.x network.   The MX84 will allow inter-VLAN communication by default but if you have stricter firewall rules in place, a simple set of layer 3 outbound rules allowing traffic between the 192.168.10.x and 192.168.11.x networks would give you the desired result. You can read more about the MX's firewall behavior and configuration options at the following Meraki resource:   https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings ... View more

Hi Pizza,   There are some tips for locating your Meraki Order number in the following Meraki resource:   https://documentation.meraki.com/General_Administration/Inventory_and_Devices/How_to_Locate_your_Meraki_Order_Number   The Meraki Order number is a 9-digit alphanumeric that will most likely begin with either "5S", "5C", "4S", or "4C". If you are still unable to locate this information, be sure to reach out to your Meraki Account Manager and/or your Meraki re-seller to see if they can re-send the order confirmation email.   Hope that helps!   Jonathan     ... View more

Hi Chris,   Thank you for supplying that additional information.   Starting with our new Wi-Fi 6 MR APs, when leveraging Layer 7 block rules for specific (NBAR) categories, you can view instances of these blocks from within the Event Log, including the specific wireless client that attempted to access a given blocked category of websites. Since the MR models that you mentioned are from our Wi-Fi 5 (Wave 2) line, we unfortunately would not be able to leverage this option at this time. It is also important to note that these Event Log entries would only trigger when blocking by website category and would not work for say a custom Layer 7 HTTP hostname definition.   If, however, you are leveraging the "Advanced Security" or "SD-WAN Plus" MX licensing tier on your MXes, you may still be able to achieve what you are after here by configuring Content Filtering rules on the MX. You would see Event Log entries when these rules are triggered, including the specific client that was attempting to access the blocked website and/or blocked category. The use of Group Policies from within your Meraki Dashboard Network would allow for granularity of these rules as needed. Finally, do note that leveraging the Content Filtering features of the MX would require that the downstream SSID(s) in question are configured in bridge mode ("External DHCP server assigned") as "NAT mode" would simply report the downstream MR AP as the client as opposed to the actual wireless end-client.   I hope this helps explain your options a bit. Feel free to call into our 24/7 Enterprise Support hotline if you need further assistance with any of these configurations.   Jonathan ... View more

Hi Chris,   Since you had mentioned an SSID, is my assumption that you are leveraging a Cisco Meraki MR wireless access point correct here? If so, which model(s) are you currently using within your Organization?   Additionally, are you leveraging any other Cisco Meraki gear within your network(s)?   Thanks! Jonathan ... View more

Hi jamesb33, I just wanted to summarize what all has been suggested here. As alemabrahao mentioned, there is no need to create a new Dashboard Network and all of your Meraki gear will check back into Dashboard and continue operating as expected once the gear has an internet connection again. Be sure to change network-specific items such as the devices' placements on the map or floor-plan if you are leveraging this functionality (https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Placing_Devices_on_the_Map_in_Dashboard). For your new building's internet connection, be sure to have all of the static IP specifics from your ISP (static IP, subnet mask, gateway, etc.) so that you are able to get your MX back online without any problems.   We most commonly see customer's leverage the "Local Status Page" of the MX in order to configure the static IP addressing on the WAN/"Internet" connection of the MX, which requires that you connect a computer directly to one of the LAN ports of your MX once you have connected at your new building. alemabrahao linked you to the correct resource for this process but I will re-post it here: https://documentation.meraki.com/MX/Other_Topics/Static_IP_Assignment#Local_IP_Assignment . You could always test accessing the MX's Local Status Page before your move to ease any concerns around this process that you may have.   Alternatively, as rbnielsen mentioned, you could pre-configure the MX's WAN 2 with your new building's static IP specifics but we still recommend having the "Local Status Page" knowledge in the event that there is an error with this pre-configuration or if further investigation is needed once you arrive at your new building.   Hope that helps, jamesb33! For more immediate assistance, be sure to call into our 24/7 Enterprise Support hotline. You can see these options by navigating to Help > Get help from the upper-right hand corner of your Meraki Dashboard portal. Good luck with the move! ... View more

In addition to the resources that alemabrahao posted above, if we are working with the Meraki MX platform here, be sure to reference the "1:1 NAT" section of the following resource to give you a better understanding of the available offerings on the MX platform and to help you achieve what you are looking to do:   https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX ... View more

Hi Ian!   I am also part of the team supporting the New to Meraki User Group and I'm looking forward to helping out those who are new to Meraki! I've been with Meraki for a couple of years now and I am currently based out of the Chicago Meraki office.   Excited to share some Meraki knowledge.   Jonathan ... View more