Meraki

Bruce · ‎Dec 14 2020

By default the MX should allow all outbound traffic initiated from the LAN side of the network. You shouldn't have any issues getting G Suite to work unless you've introduced restrictions on the outbound traffic. If you have (i.e. you've put Layer 3 Deny rules in place, or Layer 7 rules) you will need to determine which outbound rules are blocking the traffic and modify/remove them. I believe the ports you identified are used by the G Suite /GMail SMTP service, so if you are trying to connect using SMTP from a client application then you may well need them opened. EDIT: for reference if you haven't seen the MX firewall rules document, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings

Bruce · ‎Dec 14 2020

As @DarrenOC suggested I'd look at dCloud, or if you want to use a physical device with the customer look at using your own internet connection. Another option, as opposed to a USB cellular modem, that I've used before (admittedly it was primarily for Webex Calling, but don't see why it wouldn't work with a MX, but try it first) is to tether my laptop to my cell phone, then share that internet connection using the wired port on the laptop (I have a few Cisco phones set up on a Meraki MS220-8P this way). Means you connect to the WAN port on the MX which is a bit more 'normal'.

Bruce · ‎Dec 14 2020

Yes there is an easier way. If they are currently a Wireless network and an Appliance network then you can combine them from the list of networks, see this document https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Combined_Dashboard_Networks. If they're currently both combined networks - or one of them is - then you should split that network, delete the empty networks and then combine the remaining Wireless and Appliance networks as above.

Bruce · ‎Dec 12 2020

For the cellular connection on the MX itself you’ll need a SIM and a USB modem to get going, you’ll probably get both of these from your carrier - and, yes, it’s pretty straightforward. However, the cellular USB connection doesn’t give you the same feature set as the full WAN ports (e.g. it doesn’t do SD-WAN) - it’s more to just maintain some sort of connectivity to the MX and site. If by a pair of MX84s you mean an HA pair then just be aware that the cellular connectivity doesn’t kick in until all uplinks (across both MXs) have failed, so it really is a ‘last-resort’ type of thing. There is a good document here that explains it, https://documentation.meraki.com/MX/Cellular/3G%2F%2F4G_Cellular_Failover_with_USB_Modems, and also lists the USB modems Meraki have tested, but others work too. If you’re wanting to use cellular as a more robust, second/redundant WAN link to the MX then you might actually want to look at the option of getting a MG21 and connecting it to the WAN2 of the MX. This will give you more of a ‘full-featured’ WAN link and also has the advantage that you can position the antenna away from the MX, towards the cell tower.

Bruce · ‎Dec 11 2020

I’m sure you have already seen it, but here’s the Meraki document about how the streaming works, and stating that all it needs is a route from the client to the camera to use the direct stream rather than the cloud stream, https://documentation.meraki.com/MV/Viewing_Video/Video_Streaming. As has been mentioned just make sure there’s a path and no ACLs, also be aware of the last statement in the Meraki document regarding SSL inspection. It should just work.

Bruce · ‎Dec 11 2020

Assuming that your site is configured as a spoke, then all you need to do on the AutoVPN setup is make sure that there is no check mark under the ‘Default Route’ in the hubs list. If none of the hubs are checked as ‘Default Route’ then only traffic destined for subnets behind the VPN concentrator will be sent over the VPN, anything else will be sent straight to the internet locally - I.e. split tunnel operation. If you have one of the hubs checked as ‘Default Route’ then all traffic is sent over the VPN, either to the appropriate hub, or if it’s an unknown destination to the ‘Default Route’ hub - I.e. full tunnel operation. Having said all that though, Meraki management traffic (i.e that destined for the Meraki Cloud) is actually always sent directly to the internet, and not into the AutoVPN tunnel. See ‘Full Tunnel or Split Tunnel’ section in this document, https://documentation.meraki.com/MX/Site-to-site_VPN/Meraki_Auto_VPN

Bruce · ‎Dec 11 2020

As @CptnCrnch said, I don’t think these appear in the Eventlog/Syslog, and I just checked the Local Status Page too and there is nothing there - thought there might be as without the PPPoE you might not have Dashboard connectivity. It might be that support can see this, but doesn’t appear to be anything that’s ‘user’ accessible. Maybe it’s ‘Make a Wish’ time.

Bruce · ‎Dec 11 2020

@fella5 everything that @DarrenOC and @rwiesmann have said is good advice, but how to proceed really depends on what is currently licensed. This document, https://documentation.meraki.com/General_Administration/Licensing/Meraki_Licensing_-_License_More_Devices_vs_Renewal provides a good description of what happens if you apply a license as a renewal - it essentially resets all your licensed devices to match what’s in that license. So, if you currently have the MX64 and two MS220 licensed then you could apply the new MS220 licenses as a renewal (thus resetting the licensing to just the MS220 switches), then you can add the MX68W license, and then the new MR46 license - so your licensing should finally end up with two MS220, a MX68W and a MR46 (you’ll need to remove the MX64 from all networks to prevent licensing errors). However, if you’ve already added the MX68W license you’re a little stuck, you might have to see if support can help you out in anyway, or move across to Per Device Licensing as @DarrenOC suggested.

Bruce · ‎Dec 11 2020

Hi Santi, welcome. Firstly I’m not sure the expected behaviour of the AP as a repeater with regards to the alt management interface - it’s a relatively new feature. You might have to contact support to confirm what you’re seeing is expected behaviour, it sounds like it could be. With regards to using the MX86 as a wireless concentrator, that’s unlikely to work for you as the MR has to connect to the WAN interface of the MX. Out of interest, any reason why you can’t put VLAN 3 into the VPN and the use the standard management interface? This will allow connectivity to RADIUS server (assuming this is the other side of the VPN - which is why it wouldn’t work when VLAN 3 wasn’t in he VPN), and will mean you don’t have to use the alt management interface.

Bruce · ‎Dec 9 2020

The Stacking Cables on the traditional Meraki switches (i.e. not the MS390) are QSFP-based 40Gbps Cables. The Twinax cables in your first link are 10Gbps SFP+ cables and can't be used for the stack ports.

Bruce · ‎Dec 9 2020

Check with support, but I think you’ll find this is one of the ‘known bugs’ on the MS390 switches. A lot of the power issues were corrected on the MS14 code for the MS390, but be sure to read the release notes to make sure you don’t hit other issues (e.g. stack size) if you decide to upgrade.

Bruce · ‎Dec 9 2020

If you haven’t already seen it, this document provides some detail on how a gateway is chosen, https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wireless_Mesh_Networking

Bruce · ‎Dec 9 2020

To do authentication based on two credentials passed using EAP you need EAP chaining, and to support EAP chaining you need both a supplicant (on the client) and authentication infrastructure that supports it (generally the RADIUS server). Although Windows 10 can now do EAP chaining through support of EAP-TEAP, Microsoft NPS doesn’t support it so far as I’m aware, so you only have half the solution. You could get it to work if you use a different RADIUS server that supports TEAP - Cisco ISE is one example, not sure if there are any more at the moment. (TEAP is the ‘standardised’ version of Cisco’s EAP-FAST which has been able to do EAP chaining for sometime with the Cisco AnyConnect client).

Bruce · ‎Dec 9 2020

You shouldn’t lose your connectivity just by switching from Single LAN to VLANs. The IP configuration of the MX as Single LAN gets copied across to VLAN 1. The only issue could be if the MX ports are not configured as Access Ports on VLAN 1 - this could be the case if there was a previous configuration on the MX. Make sure the ports are configured as Access, VLAN 1 and enabled, and you shouldn’t lose any connectivity. Once you’re at that starting point you can then move to creating the DMZ. If all your ports are configured correctly and you’re still losing connectivity then I’d contact Support as it’s unlikely that you’ll get the assistance here that you need to troubleshoot this one.

Bruce · ‎Dec 8 2020

Yep, it’s done on a per user basis. Go to the user profile (top right-hand corner of Dashboard), Username -> My Profile, then scroll almost to the bottom and you should see the option to switch between Celsius and Fahrenheit.

Bruce · ‎Dec 8 2020

Mine just came back too

Bruce · ‎Dec 8 2020

Same issue here, I’m in the Asia/Australian DC. Give support a call if you need to do something urgent - but I’m sure they’re onto it now.

Bruce · ‎Dec 7 2020

Check that the devices actually have GPS positioning capabilities. I know for instance that the Apple iPads which only have the Wifi chipset (i.e. no LTE) didn't have the GPS capability either as it was embedded as part of the LTE chipset (not sure if that's still the case). They used a kind of psuedo GPS based on the Wifi networks they can see, so there are times it is inaccurate - a colleague of mine found this out the hard way when he attempted to use a Wifi iPad for navigation over open water...

Bruce · ‎Dec 7 2020

Yep, that approach should work for providing redundancy to the DC destination. The static route has a higher priority than the VPN peer and so should take preference all the time its available (MX route priority is here, https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior). The MPLS router will need to be connected to one of the LAN ports of the MX, and yes, the MX is a single point of failure. I can't see a way around a single point of failure with what you have without adding more kit - but the MX devices are pretty robust anyway. In most instances you shouldn't need the transit subnets specified as static routes, you just have the connected route (between the MX and the router) and the tracked static points to the far end of that for the DC subnets - the MPLS router will take care of routing from there. Like you said, internet connectivity won't fail-over in this scenario as if you try and put a static default via the MPLS network it will take priority and won't use the local internet unless it fails. Thinking of ways around this... if your MPLS provider can give you a second IP address from the MPLS router then you could do it by using that on WAN2, and then setting preferences for internet traffic - its not overly pretty, but might just work, and depends on how flexible your service provider is. Yep, if the MX fails your life becomes difficult, but not impossible. You'll need to establish internet connectivity to change the routing. You should be able to get the MS connected to the internet by using the Local Status Page on the MS. You can modify the Uplink IP address settings from here (the one it uses to connect to the Meraki cloud), so you could set the IP address and default gateway to get internet connectivity via the MPLS circuit (the routing for this is separate to the switch routing), and then once connected reconfigure the switch routing as needed.

Bruce · ‎Dec 7 2020

As @KarstenI correctly states you can't do this using VRRP. However, you should be able to incorporate the MPLS router and MX into your network to achieve some of your desired outcomes, the main thing you'd end up losing would be hardware redundancy as the MPLS router would need to be in front or behind the MX. One of the approaches you could consider is to use one WAN port on the MX to connect to the internet, the other to the MPLS router. You can then preference the internet link for internet traffic and the WAN link for WAN traffic, and if the internet link fails then the other WAN link (the MPLS) would get used for internet. Depending on the visibility you require you may need to get support to enable No NAT on the MPLS link, and potentially the inbound firewall in the Dashboard too (depending on where your traffic originates). What I don't think this is going to give you is your redundant path via the internet to the DC since I believe putting any kind of VPN on the MX towards the DC will make that the preferred route, rather than unencrypted out of the WAN port (to the MPLS router). If you get the opportunity to put an MX in the DC (or already have one) in one-armed concentrator mode then you can go down the SD-WAN path, which can give you exactly what you are looking for.

Bruce · ‎Dec 6 2020

Does everything still work when you first make the change to enable VLANs, without adding VLAN 10?

Bruce · ‎Dec 4 2020

The main issue you’ll likely encounter will be the wonders of spanning-tree (STP). Cisco, by default, runs Rapid-PVST+, Meraki uses standard RSTP. With the default setup you need to have the Cisco switch as the STP root, otherwise it all gets a bit hairy. Best solution is to swap the Cisco switches over to MSTP (sometimes written as MST) and use that, then they should interoperate seamlessly with the Meraki switches running RSTP - MSTP and RSTP are both standards and interoperate; PVST and its variants are Cisco proprietary and don’t interoperate as well as they potentially should. EDIT: there’s more detail on STP interoperability here, https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide

Bruce · ‎Dec 4 2020

Are the switches the same model? In most instances they need to be to be able to clone them, https://documentation.meraki.com/MS/Other_Topics/Switch_Cloning. If they’re not the same then it’s a manual process through the Dashboard (remember you can bulk configure multiple ports in Meraki, so it can be quite quick), or if you have done any scripting then you can use the API to copy most of the configuration across. There are a number of scripts on GitHub for copying port configurations.

Bruce · ‎Dec 4 2020

If you’re using a VPN tunnel to a non-Meraki client then you’d choose this under the IPSec configuration. For Phase 2 you’ll have to remove all other methods to ensure you are using SHA256. (Note: you need MX 15.12 or later). For AutoVPN the white paper, https://meraki.cisco.com/lib/pdf/meraki_whitepaper_autovpn.pdf, states that it uses SHA256, but not sure how you’d verify this. Might be something support can verify, and ensure that only SHA256 is used.

Bruce · ‎Dec 4 2020

My gut feel here is that this is something on the Fortigate side. If the VPN is coming up and you are able to ping and RDP from the Meraki to the Fortigate then traffic is travelling successfully in both directions over the connection. This would lead me to believe that there is a firewall rule on the Fortigate that is blocking traffic that is originating on the other side. The Meraki firewall rule error is because that subnet isn’t local, it’s at the remote site, and those rules don’t apply to VPN traffic. By default the Meraki MX will allow all traffic over the VPN to a learnt remote subnet (you can change this on the site-to-site VPN page, with the site-to-site outbound firewall rules).

About Bruce

Bruce

Community Record

Badges