The Meraki devices only support two WAN/internet links, plus failover to either a USB cellular modem (or an inbuilt cellular modem in the case of MX67C and MX68CW).   You’ve a couple of options:   1. Use the inbuilt cellular modem instead of the MG21 - then your failover will work WAN1 -> WAN2 -> Cellular.   2. Depending on what your network design is then you maybe able to achieve something using tracked routes on the MX, but your preferred path will need to be on a LAN port. You can then go LAN1 -> WAN1 -> WAN2. You won’t be able to do SD-WAN to the LAN port. Remember the WAN1 port will need a path to the internet too. As I said, depends on your design as to whether this is practical or not. ... View more

You’re over thinking it, if you want to block those two domains then just add them to the block list that should block them.   The documentation you read about whitelist, blocklist and why you can do it one way and not the other is to do with how rules are processed, in your case it’s not relevant if all you’re trying to do is block those two domains. Whitelists are processed first, and if there is a hit then the domain is allowed. If the domain isn’t listed in the whitelist then the blocklist is tested. When a domain is tested the subdomains are iteratively removed, thus if you whitelist a parent domain it will always hit the parent during testing, and never get tested against the child in the blocklist. Hope this makes a bit more sense now. ... View more

Yes, the per-port VLAN settings are the settings on each port on the MX105. As you can see all the MX ports are set as trunks (so they carry multiple VLANs), with a Native VLAN of 1, and all VLANs allowed. To get you up and running these are the same settings that you should use on all the connections between MX and MS, MS and MS, and MS and MR. ... View more

You need trunk ports between all the devices, and to allow the VLANs on the trunk ports - which it sounds as if you’ve already done. Then every VLAN needs a gateway (Layer 3 interface - I.e. an IP address). On the MX, where you created your first VLAN, you’ll also need to create the new one, and that will walk you through creating the Layer 3 interface. The Layer 3 interfaces will then pass the traffic between the VLANs. ... View more

Ahhh, the magic smoke has escaped. ... View more

I can't help with the issue, but just as a note the STP change is a consequence of the port flap, not the other way around. You see the port go from 1Gbps Full Duplex to down, and STP responds by moving the port from designated to disabled. If you can fix the port flap the STP change will likely go away.   What is causing the flap is just a case of eliminating the variables. Check the cables, reboot the WAP, if you've got a spare port on the switch try that, and if all that fails, as Meraki support said, reset the WAP.   Did anything change when this started happening? MS firmware upgrade, MR firmware upgrade? Adding a new MR to the switch? (maybe taking it over the PoE budget). ... View more

Just to echo what @KarstenI said, even if it does work I’d keep things separate just from a troubleshooting standpoint, and if you need to connect to those WAN routers.   I can see why it would mostly work - since WAN1 never needs to know about WAN2 and vice-versa - and the upstream path only exists via a default route to the WAN interface, and it’s generally all NATed. But I’d still keep them in separate subnets. ... View more

Because your public IP is listed as phishing by BrightCloud, have you done a packet capture to see if there is any unusual traffic on your WAN/LAN. Just wondering if there is something going on that is causing traffic that is overloading the MX (since the MX67 is a small box).   Also, what’s on Port 1 and Port 3 that keep flapping? (Port 1 is the WAN port) Is this dual-homed to a switch? ... View more

The messages you are seeing are a timeout request for the lookup of the DNS service record for LDAP. My guess is nothing can authenticate properly, hence the login timing out and you can only authenticate with local accounts.   You need to troubleshoot where your DNS server is and why you can’t reach it.   As an aside, .local is no longer recommended for internal domains as it’s an IETF reserved domain generally used for mDNS and link-local networking. It’s possible this is having and impact, but I doubt it (unless you’ve introduced other systems to the network at the same time as changing the switches over). ... View more

Hi @whistleblower, here’s my take on your questions based on experience. Happy for others to advise if they’ve had different outcomes.   1. Yes, local configuration overrides network-wide configuration, but I’ve never seen a warning message if the two don’t match. I’ve only seen warning messages if there is a communication issue with the Meraki cloud.   2. There is no automatic tagging for the management VLAN across the network. You have to get the traffic to/from the switch. Based on this I always find it easiest to have the management VLAN set as the native on all trunks that are uplinks.   3. Imagine the management address as an access port on the switch. It doesn’t care which VLAN it is, only if there in a path to a DHCP server on that VLAN. Since it’s an ‘access port’ it’s always untagged, whether it’s tagged or not on another port depends on that port’s configuration.   4. The definition of a safe configuration is a few paragraphs further up in that document, “Safe configuration means that ‘the device has connectivity to cloud and hasn't rebooted for 30 minutes following a configuration change.’ That is, the safe configuration is the last configuration the device received from the cloud that was not followed by a reboot within 30 minutes.” A ‘not safe configuration’ is just the reverse - I.e. one where no connectivity to the cloud has been achieved. ... View more

@DHAnderson, out of the box the cellular firewall rules only apply to a USB modem, or the inbuilt modem on one of the MX ‘C’ models. However, if you contact support you can request that they make the Cellular Firewall rules apply to WAN2 - it’s intended for the exact reason you have described, but you have to make the request through support. ... View more

@ospsms, start with checking the status of the AutoVPN, make sure it is actually up. And check the route table to make sure the subnets of the other site have been learnt by the MX. ... View more

@ToryDav, great to hear that it all went well, and that things are looking better! 15mins isn’t bad for a MS390, when they were first released it was closer to an hour - still way longer than the traditional Meraki switches (which are usually only a minute or two tops). ... View more

Those configurations look about right. Its possible that the media convertor is doing something more than just converting the media. Is it possible to test without the media convertor, maybe temporarily using the SFP that connects to the HP switch? ... View more

Have you made the link between the MS120 and MS220 a trunk? It needs to be a trunk to carry the multiple VLANs, and make sure the native VLAN is set the same at both ends (probably just keep it as the original VLAN you had). The port you connect your device to only needs to be an access port. ... View more

@thomasthomsen, I agree with you, the documentation on using the MX as a wireless concentrator isn’t great, but as @ww stated it’s ‘yes’ to both your questions. ... View more

@FelipeTeevo, thanks for the update. Glad to hear you found a way to achieve your desired outcome. That’s a relatively new feature, good to see it’s enabling people to use the Meraki kit in the way they want. ... View more

You can connect a MR36 directly to a MX64W but you’ll either need to power the AP with a power supply, or use a PoE injector (or use a PoE switch). Also note that you won’t get any roaming between the MX and MR, they’re configured separately, and you’re probably best to not have them both configured with the same SSID. ... View more