Meraki

Bruce · ‎Sep 20 2021

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?

Bruce · ‎Sep 20 2021

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).

Bruce · ‎Sep 20 2021

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.

Bruce · ‎Sep 17 2021

@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.

Bruce · ‎Sep 17 2021

@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.

Bruce · ‎Sep 17 2021

@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).

Bruce · ‎Sep 17 2021

If you’re losing internet access when the AutoVPN comes up it sounds like you’re trying to use full tunnel, which you don’t want to be. Make sure there a no Exit Hubs configured in the AutoVPN settings at each site.

Bruce · ‎Sep 17 2021

@CharlieCrackle, generally replacements with the standard warranty are Next Business Day, but the official line is they ship within one business day on a best effort basis. It’s those last 5 words which are the gotcha. If you need a more solid replacement agreement then you need to look at Meraki Now, which is somewhat equivalent to Cisco SmartNet. I believe it’s only then do these devices get factored into Cisco’s sparing model to ensure there is adequate supply in local depots.

Bruce · ‎Sep 17 2021

@ToryDav, I believe everything you’ve described there can be classified as a MS390 thing. Some of those issues are noted in the firmware release notes. Not sure what version you’re running, but if you’re not on the latest MS14 code then it might be worth the upgrade, it should solve some of the Dashboard issues - just give yourself plenty of time for the upgrade.

Bruce · ‎Sep 16 2021

Not much - literally. The RF charts indicate that there is very little RF on those channels, that’s all you are seeing. So long as you aren’t having problems there is nothing to worry about.

Bruce · ‎Sep 15 2021

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?

Bruce · ‎Sep 15 2021

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.

Bruce · ‎Sep 15 2021

@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.

Bruce · ‎Sep 15 2021

@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.

Bruce · ‎Sep 14 2021

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.

Bruce · ‎Sep 13 2021

@Aneeshram, yes the firewall and traffic shaping rules apply to the traffic on the SSID no matter which client IP assignment mode (e.g. NAT mode, bridge mode, or Layer 3 roaming with a concentrator) is chosen for the SSID. The traffic shaping rules are applied to the traffic as it ingresses/egresses the access point.

Bruce · ‎Sep 13 2021

As has been said, use access ports, 3 in one VLAN, three in another VLAN on the switch. Keep in mind you will also need the ISP to provide you a /29 subnet (6 IP addresses) on the links to make the HA work - one is the ISP gateway, one for each MX and the virtual IP. The other two IP addresses can be used for anything (e.g. NATs on the MX).

Bruce · ‎Sep 11 2021

@ArielA, the MX doesn’t support any dynamic routing protocol on the WAN interfaces when set up in routed/NAT mode, so you first need to address that. You’ll need to speak with the MPLS VPN provider to see if they can set up a default route for the customer within the MPLS VPN. You then configure static addressing and default gateway on the MX WAN port and the MPLS network takes care of the routing. Once the default route is in place on the MPLS VPN, establishing the SD-WAN on top of this is then pretty much the same outcome as the GRE tunnel you have at the moment except that it uses IPsec and it’s a lot more auto-magic, but you need the routing in the MPLS network to support it. If the MPLS provider can’t provide a default route directly within the MPLS VPN then the MX probably isn’t the solution (yes, you could do GRE tunnels to a Cisco router, then put the MX on the end of it, but you’ll be doing an IPsec tunnel in a GRE tunnel). Personally if the MPLS provider can’t provide the default route I’d kick the MPLS provider and either find another one or do SD-WAN over internet links.

Bruce · ‎Sep 10 2021

@ArielA, here is a document that explains how to set it up, https://documentation.meraki.com/MX/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS. You use a MX in concentrator mode at HQ, so that the traffic from the MPLS network can also get directly to the internet. Since HQ is the point where the MPLS network accesses the internet this is also where you inject the default route into the MPLS network. This allows all the MX devices access to the internet.

Bruce · ‎Sep 9 2021

Good to hear you got it working. If you’re authenticating enterprise users then you are better off using 802.1x and a RADIUS server as you have discovered - it’s more seamless for the users. You can also use the same RADIUS server to secure your switch ports using Access Policies too. That way you can be sure that only authorised users are connecting via the switches too.

Bruce · ‎Sep 8 2021

@ArielA, what others have posted about No-NAT is correct, but if you are planning on doing SD-WAN then its not required. Traffic that enters an AutoVPN tunnel (such as in a SD-WAN environment) isn't NATed anyway, so when it pops-out the SD-WAN head-end it has exactly the same source IP address as when it entered. Unless you really have to use No-NAT, and have a really clear reason for it, I'd avoid it as it adds other considerations to the deployment too - such as inbound firewalls. Just remember if you are doing SD-WAN over MPLS private IP networks you need to have a default route to the internet from that network so each WAN port of the MX can register to the Meraki Dashboard and VPN registry.

Bruce · ‎Sep 8 2021

I may not know the answer, but to try and assist, are you trying to use Enterprise Authentication with Local Auth (with AD being the LDAP server), or a Splash Page with Active Directory?

Bruce · ‎Sep 8 2021

This one, https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation, highlights the MS390 limitation on the VLAN field about halfway down. For the other limitations it’s best to look at the firmware release notes, the latest ones have been posted here, https://community.meraki.com/t5/Switching/New-MS-14-29-stable-release-candidate-firmware-released-a-few/m-p/128281

Bruce · ‎Sep 7 2021

When you apply an ACL under Switch -> Configure -> ACL its defined directly for all switches within the network. Since you stated you had different subnets assigned to VLAN30, I assumed that you had Layer 3 interfaces defined on each stack of MS390 each with a different subnet specific to that "hub". That's where the MS390 will be problematic as you can't defined a rule based on a VLAN for the MS390s, they'll ignore it (one of the many MS390 caveats). And that rule wouldn't work on the MS425 stack as by the time the traffic reached there it would no-longer be VLAN30. Looking back through your posts though, if you only have devices connected to the MS125, and nothing directly to the MS390, then you could create the ACLs, apply them to VLAN30, and they'll get implemented on the MS125. Your source will be 'any' so that it apply to any traffic sourced in VLAN30 and the destination the various IP addresses and ports of the devices you want to deny (or permit) access to. There's more on the switch ACLs here https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs. If you flip the rules and apply them to return traffic then yes, you're not stopping traffic getting to the device, but for TCP traffic you wouldn't be able to establish a connection as the handshake wouldn't complete. And for UDP traffic if there was an expectation of a response it would never come - so whatever is trying to connect to it is 'flying blind'. Yes, I know its not ideal, but just trying to think of other ways around the issue.

Bruce · ‎Sep 4 2021

Go to Network-wide -> General on the Meraki Dashboard. About halfway down you will find the ‘Device Configuration’ section, under that section are the local credentials. The username is ‘admin’ and you can set the password there. If the device is connecting to the Meraki cloud it will use the username and password configured here. If the device has never connected to the Meraki cloud (or if you do a factory reset and keep is disconnected) then it will use the serial number as the username, with a blank password. Hope this helps.

About Bruce

Bruce

Community Record

Badges