Yes, you are correct about the MX in VPN concentrator/one-arm mode - single connection, single IP address.   Internet Tunnel: Yep, that how it works, the MX contacts the Meraki VPN registry and registers its private IP address and public IP address, along with the port its going to use for the VPN.   MPLS Tunnel: The MPLS network has to have a path to the internet, whether this from the MPLS network (e.g. provided by a firewall hosted by the service provider) or whether its via the hub site. When any MX contacts the VPN registry via this path the public IP address will be the same for all devices, and thus the MXs are instructed to create the VPN using the private IP address.   1 - You have to have internet access from the MPLS network, this could be directly from the cloud by the service provider, or by a default route being injected into the MPLS routing from the hub site where the VPN concentrators are. The MX management traffic is never encrypted into the VPN tunnel, it is always sent natively on the WAN port, and contact with the VPN registry is required on both WAN ports.   2 - The VPN registration is performed from each WAN port, not from the MX as a whole, and for each WAN port it will use the gateway configured for that interface. Management traffic is not impacted by the MX configuration (load-balancing, etc.) it always uses either the configured primary interface or a specific interface (i.e. for VPN registration).   MX spoke limitations: You've got the gist of it, and if you want to call it a limitation, then that's okay. But if you have one device at each end of a path, and each device has only one IP address, then traffic between the two is always going to take the exact same path since routing is based on the IP addresses. Running in NAT/routed mode provides two IP addresses to a device, which is what then allows SD-WAN, or two different paths. ... View more

I’m not entirely sure what you are asking, but it seems to be made up of two parts. First, static routes can only point to LAN ports, but these will always override Auto-VPN routes, thus they will create a ‘breakout’. Routing precedence on the MX can be found here, https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior.   If you’re looking for Full-Tunnel Exclusion (Breakout), which appears to cover your MPLS question, then that is covered in this document, https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout). My assumption would be that if traffic hits the exclusion it would then be routed as normal internet traffic. So if you had a direct internet connection configured as your primary link, no load-balancing (or other internet flow preferences) then it should use that.   Hope this helps with your scenario. ... View more

What model switches are you using? And have you connected anything into the ports on the back of the switches? Normally you only get ‘potential stack’ messages if you have cables in the stack ports on the back of the switches. ... View more

That depends on the WAN circuits you are using. Really the only requirement is for each WAN port that you are using on the hub to be able to access the Meraki registry (essentially the internet) - so if you have direct internet connections then you will be fine, or if you're using an MPLS network that provides NATed internet access then you will be fine, for both these or a combination of them you should be able to run the MX in routed mode.   Generally one arm concentrator is only a necessity if you want to do dynamic routing, have multiple DCs providing access to the same subnets, or if you need to provide the internet access from an MPLS network - although that's not a prescriptive list. ... View more

As @PhilipDAth states the switch assigns the VLAN based on the information received back from the RADIUS (NPS) server. These are the attributes that need to be returned:   Dynamic VLAN Assignment In lieu of CoA, MS switches can still dynamically assign a VLAN to a device by assigned the VLAN passed in the Tunnel-Pvt-Group-ID attribute. It may be necessary to perform dynamic VLAN assignment on a per computer or per user basis. This can be done on your wired network via 802.1x authentication (RADIUS). In order to do so, the following RADIUS attributes must be configured and passed in the RADIUS Access-Accept message from the RADIUS server. Tunnel-Medium-Type: Choose 802 (Includes all 802 media plus Ethernet canonical format) for the Attribute value Commonly used for 802.1X.  Tunnel-Private-Group-ID: Choose String and enter the VLAN desired (ex. "500"). This string will specify the VLAN ID 500. Tunnel-Type: Choose Attribute value Commonly used for 802.1X and select Virtual LANs (VLANs). Once these attributes are configured on the RADIUS server, client devices can receive their VLAN assignment dynamically.   Reference: https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X)  ... View more

1 - The MXs register to the Meraki VPN registry with their given IP addresses (whether this is private or public) from all the WAN ports and the VPN registry also learns the public IP address that the registration is coming from. From this it will instruct the MXs between which IP addresses to form the VPN tunnels. Its through this 'magic' that the VPN concentrator gets to learn about the two paths to the remote MX. (There was a good Meraki document on the the operation of the VPN registry, I just can't find it at the moment).   2  - They need connectivity to the Meraki VPN registry over both the paths, that's how it learns about the two paths. Yes, the majority of the management traffic will go over the primary uplink, but there needs to be a path to the Meraki cloud on the secondary link too.   3 - I wouldn't say there are limitations with deploying the MXs as spokes, its about getting your design right so that all the devices in the network function as they are meant to. I've mostly seen the spoke MXs deployed as both the edge of the network (i.e. the firewall) and the SD-WAN device. You could for instance connect your internet circuit to the firewall, then connect that back to one WAN port on the MX; the other WAN port on the MX can be connected to the MPLS circuit, the outcome is the same.   With regards to no-NAT, its definitely a feature, whether its Beta or not I don't know. You'll need to get support to enable it for you, and they can answer that question too. You need to consider how you would use the no-NAT feature too. It wouldn't be needed for the traffic being tunneled to the hub as the IP addresses are maintained inside the tunnel anyway, and in general the NAT on the MX and the outer firewall won't impact traffic. Where I could see you may want to do it is between the MX and the firewall on the internet if you are using some form of user to IP address mapping to influence the firewall rules; but then you could also be doing that on the MX if you wanted to. It all comes down to what you are trying to achieve, and how you want to achieve it. ... View more

What threat protection/firewall rules do you have configured?   Advanced Malware Protection (AMP)? IDS/IPS? Content Filtering? Geo IP Blocking? Any of these could be impacting it. What happens if for the device you are using you change the Policy to the ‘Allow List’ does that then provide access? ... View more

You can’t use MX in a DMVPN solution or vice-versa, the ways they establish their secure tunnels (the key exchange) is different. What you’d need to do is have the MX hub connected to a Cisco router using DMVPN at the hub - so you essentially have a MX network and a separate DMVPN network with a LAN connecting them at the head-end, that’s about the best you can do.   If you’re doing a migration consider using BGP on the MXs so that routes dynamically move from one system to the other as you migrate sites/spokes. ... View more

Have a look at this document, https://documentation.meraki.com/MS/Monitoring_and_Reporting/Network_Topology. The topology uses LLDP (and CDP when available), but I believe it also uses other factors too, for instance, the port it’s using to reach the Meraki Dashboard and STP.   Based on the reference you may be better off with just using LLDP in the environment. If your network is only a couple of Meraki devices and a lot of third party devices then it may not accurately show the topology due to LLDP not being passed across multiple hops (and thus the Dashboard never really learning how things are truely connected). ... View more

Does the Summary Report provide what you need? Organization -> Summary Report, then adjust the network to the ‘appliance’ network for the site, and adjust the time fram from up the top next to the title. You should then see usage stats on the MX for the period. ... View more

1 - Yes, the MXs will be able to form multiple tunnels, each tunnel uses a different UDP port. Depending on the firewall you may need some ‘fine-tuning’, but fundamentally it will work. You will need to ensure there is a path from the MPLS network via the firewalls to the Meraki cloud (specifically the VPN registry, as well as others).   2 - Yes, the MXs in routed mode, with two WAN connections (one MPLS, one internet) is fine, you just need access to the Meraki cloud from the MPLS network; see the mention around internet access via the firewalls above.   3 - If you do single arm in the branch you’ll only get one VPN tunnel via one path - so no SD-WAN and no load balancing/performance routing of traffic, and no security features, so you lose most of the benefit of the MX solution. Probably not a great idea. ... View more

Yes, but it may not be easy depending on your requirements.   It all comes down to the capabilities of your client and RADIUS server (for the 802.1x authentication). Every RADIUS servers will support a single authentication method as part of the EAP process - this might be a username/password combination with PEAP-MSCHAPv2, or a certificate with EAP-TLS. And that authentication could be a user username/password, or a device username/password (for a AD registered device), or the certificate of a user or device.   It may be that to meet your requirements it’s sufficient to authenticate your device to the network (with a certificate or username/password depending on what is available) and then rely on the authentication of the user to access the server resources as the ‘secondary’ authentication.   If you want to actually authenticate both the device and the user with 802.1x (WPA2 Enterprise) then you need to use EAP chaining. The problem is there are very few clients and RADIUS servers that support it. Windows 10 does support TEAP for EAP chaining, or you could use a different supplicant installed on the client (e.g. Cisco AnyConnect) to support it. For a RADIUS server, Cisco ISE supports TEAP for EAP chaining, but I’m not aware of much support outside of this.   I’d tend to look just at the device authentication. If you’ve got the infrastructure and ability to do certificate-based authentication then have a look at that for everything. Otherwise I’d look at two SSIDs, one for the Meraki MDM managed devices, and one for the Windows devices which you can authenticate with computer username/password (assuming their domain joined) with NPS to provide the RADIUS service - and use GPOs to push the Wifi SSID details. ... View more

I believe the advantage of the pre-defined Umbrella rules, other than the way that Umbrella works (if you call that an advantage - I know it’s debatable), is the speed that updates (especially for malware) are pushed into the Umbrella DNS servers. The Umbrella based classifications are managed by the Cisco Talos team and are continuously feeding into the Umbrella system, as is their finding regarding malware. Along with Umbrella’s machine learning for things like DGA’s it provides a great level of protection.   The inbuilt content filtering in both the MR and MX is fed by BrightCloud and relies upon inspection of URLs. The update process is not as quick - generally BrightCloud has to update the listings, and then the device needs to download the listings - and you could argue that URL inspection itself is more CPU intensive than the DNS based approach of Umbrella.   I would say that the full version of Umbrella integrated with Meraki MR or MX is a great solution (it’s far more granular, and can provide protection for off-net clients), but I do tend to agree that with the pre-built bundles its less clear cut, although the added malware protection alone may make it valuable.   Hope this goes some way to providing some guidance.   Note: the predefined Umbrella policies are only available on the MR with the Advanced License. I don’t believe the predefined bundles have made it to the MX yet, you have to do an integration with a full Umbrella license. ... View more

I’ve just spotted that one of your Dashboard’s appears to be in China (.cn), I betting this is the issue. The is a certain amount of separation between the Meraki organisations hosted in China and those hosted elsewhere in the world... for Dashboard 2, the China hosted organisations you need to use api.meraki.cn for the API endpoints. ... View more

Really scratching for ideas here. The API key is associated with a user, make sure that the user has the appropriate permissions to the organisations.   ... View more

Basic I know, but is the API access enabled under the Organization Settings? ... View more

Devices shouldn’t need a reboot to get them to come back online. As soon as they re-establish connectivity to the Meraki Dashboard they should show as online - and they’ll continue to try at regular intervals. It’s worth checking your configuration on the Cisco vEdge devices (and the Viptela SD-WAN solution in general) to make sure you’re not accidentally blocking the Meraki devices access to the Dashboard. ... View more

Great job all, and well done @oldroo  ... View more

I believe there’s some improvements been made in MR 27.6, so you may want to upgrade your firmware. Not saying this will fix it, but it’s a good start. ... View more

Depends how your network is setup... if you’ve used templates then you could just add it to the template. But assuming you’ve not then the easiest way is probably using the API to push the configuration to each site.   You can use Python, as an example, to script it, and use the network SSID API endpoint, https://developer.cisco.com/meraki/api-v1/#!get-network-wireless-ssids, there is also a ‘put’ version. If you haven’t any experience with scripting or APIs the you might want to find a partner in NZ who can assist you (@PhilipDAth is a good option). ... View more

@CarlosCoquecan you get yourself set up as you did for your outside capture which provided results, check that it still provides results again, and then change the packet capture interface to LAN (rather than Internet 1) to see if the traffic is making it to the LAN-side of the MX ... View more

Hi @ErickArteaga234, if the client is on the co-termination license model then there will only be one expiration date given on the licensing page, and this will be the date that the entire organisation licensing expires. The client is getting a warning because they are within three months of their license expiring.   You need to look at the term of each license that has been applied in the license history (bottom of the licensing page), to understand what has occurred.   My guess is the following, but you’d need to validate: License acquired for 1 switch + 5 AP in 2017, for 3 year term Before license expires in 2020, another license is added for 10 AP, with a three year term As it’s the co-term model, the new license ‘tokens’ flow across all the devices, pushing the co-term date out by 12-18 months (depending on the switch model) and so you end up with a co-termination date of April 2021 There’s more detail on how this licensing model works here, https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview. Your client won’t have lost out on anything, the dates just haven’t occurred as they were expecting.   If they want to have different dates for different devices then they can move to the per device licensing (PDL) model, but it’s a one-way change, you can’t then go back to co-term. And as @DarrenOC said, they’ll still need new licenses as all devices will have an initial end date of the current co-term date. It may just mean that if they add devices in the future, the dates that the device licenses expire will be the full term from when they were applied. ... View more