Meraki

GreenMan · ‎May 23 2023

I wonder why you use the word 'useless' ? If you are particularly susceptible to DFS events, leaving you with maybe just UNII-1 - which is likely to be extremely busy - I sympathise, but it's worth re-iterating that, in the UK, UNII-3 is also still covered by DFS (not true for the US, I think), therefore no guarantees you can use it anyway. Remember too that each AP model has to be certified for use in those channels. I believe Meraki is planning to initiate this for WiFi6 models, that are not already certified (this would included MR44). The process can take some time, apparently - and there's no absolute gurantee of certification, of course, either.

GreenMan · ‎May 15 2023

My guess is that you may have performed a 'Renew my dashboard license' operation, when what you actually wanted to do is 'License more devices'. Bear in mind though that, if you do want to renew (usually because your co-termination date is coming up) you need to include licensing for all the devices that you want to carry on working after it's application; a renewal will effectively overwrite what's in the Dashboard already. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Licensing_-_License_More_Devices_vs_Renewal @alemabrahao is right though - Support should help you in the first instance. If you need to purchase something extra / different, they will refer you to your Meraki sales rep.

GreenMan · ‎May 15 2023

Yes - that seems very likely @cmr . Bear in mind, @SY2 that the link doesn't need to go directly to the Internet. Provided there's Internet breakout accessible further downstream, the MX can work fine if, for example, it's an MPLS network, with Internet via a private DC. If there's no such Internet though, the MX won't bring that WAN link up. You could consider connecting the private network to a LAN port (with a dedicated VLAN) though and use static routing? https://documentation.meraki.com/MX/Networks_and_Routing/MX_Addressing_and_VLANs#Static_routes While you can firewall between this and other VLANs - and use (for e.g.) IPS, your options around shaping / SD-WAN are rather reduced,I think. What are you looking to achieve here? I assume at leas one of your WAN links will have Internet access? With no Internet over either WAN, the MX definitely isn't the right tool for the job.

GreenMan · ‎May 15 2023

Many customers need flexibility around what coverage area is required, when choosing outdoor APs. NOT including antennas with the AP allows customers to make that choice without wasting money on basic omni-directional antennas - if they actually need (say) directional patch antennas. Compatible antennas are listed in the datasheet: https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR76_Datasheet search 'List of compatible antennas' If you do want straightforward omni-directional antennas then MA-ANT-20 would be the right ones: 1 x MA-ANT-20 includes a pair of antennas. They are dual-band so will work on the 2 x 2.4 GHz or on the 2 x 5 GHz antenna posts. So order 2 x MA-ANT-20 to cover the four ports on an MR76. Do not be tempted to leave any antenna posts without an attached antenna.

GreenMan · ‎May 15 2023

@alemabrahao is correct - a WAN link with no working Internet will not be considered for any traffic.

GreenMan · ‎May 11 2023

It just needs to dry out

GreenMan · ‎May 11 2023

If both tunnels use non-Meraki VPN, this could be configured to work; but that's not what is shown in the diagram

GreenMan · ‎May 11 2023

I think it would be useful to understand the use case here, but maybe check this out - this maybe addresses the need...? https://documentation.meraki.com/MR/Encryption_and_Authentication/Wi-Fi_Personal_Network_(WPN) It's definitely not the same technically - but might address the need? Anyway - would be good to understand what the customer is trying to achieve / avoid..?

GreenMan · ‎May 11 2023

You should really have APs that are in different sites placed in different Dashboard Networks, within your Organization. Your requirement could be addressed if you did that (and there are other benefits too). Consider creating the new Network by basing it on the existing one, to save yourself time

GreenMan · ‎May 11 2023

No - that won't work (hairpinning non-Meraki and AutoVPN) Take a look here: https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#AutoVPN_and_Non-Meraki_VPN_peers Why not reduce your hops / latency by building a tunnel directly from the MX84 to the VMX? (I assume the two MX appliances are in different Orgs, hence using non-Meraki VPN to inter-connect)

GreenMan · ‎May 11 2023

Bear in mind that anything that's still using big old GBICs is pretty unlikely to still be supported in any way by Cisco. You can probably make it work but... security? supportability?

GreenMan · ‎May 11 2023

It will route via VPN - to Meraki MX via AutoVPN or other IPSec tunnel terminators via non-Meraki VPN. If your on-prem devices are 'out there' via the the Internet, you won't be able to reach them natively (no VPN) via the VMX. Do you not need to secure that traffic?

GreenMan · ‎May 5 2023

As things stand, the VMX is not built for this use case. From the Overview section of the document you have linked: VMX is "a virtual MX appliance running in the Azure Cloud that serves as an Auto VPN termination point for your physical MX devices" The features that make an MX appliance a UTM for a site (firewall, IPS, content filtering, malware scanning) are not charged for / supported by the vMX (there's no Advanced Security license for vMX) For your use case, you're probably better off with something like a virtualised Firepower: https://www.cisco.com/c/en/us/products/collateral/security/firepower-ngfw-virtual/threat-defense-virtual-ngfwv-ds.html

GreenMan · ‎May 5 2023

Security & SD-WAN is a menu you only get if you deploy an MX appliance in the Network in question. With just MR, there are generally two alternative approaches, though you can mix-and-match between different SSIDs. You could use NAT mode, where each AP is it's own DHCP server and (as the name implies) performs NAT. This is generally used for static Guest users. Most corporate SSIDs will run in Bridged mode, where you will need to provide a DHCP server elsewhere, either directly in the VLAN in which clients are placed or as a DHCP helper on the gateway for said VLAN. In an environment where an MX is deployed, it's the MX that generally provides the default gateway function and is setup to locally act as a DHCP server or relay - maybe to a DC with a fully centralised DHCP setup, over meraki secure SD-WAN. Have a good read of this: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignment

GreenMan · ‎May 4 2023

Glad it's working! Pease could you ensure you raise cases with Meraki Support, so they record the problem with 18? It may be that Support would like to gather more diagnostic information, in order to pin-point (and thus fix) the precise issue, but I appreciate that would take more time and might require a test setup, which might be difficult for you - but if you could at least register the issue, that would help. Thanks in advance

GreenMan · ‎May 2 2023

Correct - the facility to do this doesn't currently exist. You could make a request for this using the 'Give your feedback' button in the bottom right of the Dashboard. If it's particularly important to you, you may also wish to take it up through your Meraki account team. Contact details are available via Help (or ?) > Get help > Still need help? > Contact your Meraki Sales representative, within Dashboard.

GreenMan · ‎Apr 27 2023

¿Cómo está configurado el puerto del switch?

GreenMan · ‎Apr 27 2023

If you need Support to do something for you, you need to raise a case with Meraki Support via the appropriate means. This Community page is not included within that. After all - even if Support monitored here, how do they know which is your Dashboard Organization? See options for contacting Support under Help (or ?) Get help in the Dashboard. This is still supported, to the limits enabled by Google functionality, as per this KB article: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_WPA2-Enterprise_with_Google_Auth

GreenMan · ‎Apr 27 2023

I'd be tempted to try the current Stable MX firmware on this (17.10.5, I think) - but raise a case with Meraki Support, if you haven't done so already. If it works on 17, it's still worthwhile raising a case for the issue on 18, to the benefit of many MX customers - though Support might request you leave it on 18 for a period of time, to do some more testing & gather related information.

GreenMan · ‎Apr 27 2023

Make sure you have enabled access (e.g. configured firewall rules) for the camera's IP to all of the necessary MV destinations in the Meraki cloud. These are shown under Help (or ?) > Firewall info, within the Dashboard.

GreenMan · ‎Apr 26 2023

The native IP addressing is retained for traffic that flows within the VPN, but by default, when the Internet traffic flows over the metro ethernet circuit, it will be NATed behind the address assigned to that MX's WAN interface. This should not be a problem for outbound sessions, but inbound ones (if you have them) would be blocked by the MX firewalling, by default. If, for example, you have a system in your HQ that needs to initiate a session to a device on a VPN-disabled VLAN at your remote site, the NAT & firewalling will need to be addressed: https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX Unless you go for No-NAT

GreenMan · ‎Apr 26 2023

This type of statistical shaping ("only apply the limit when the link is full") is not supported.

GreenMan · ‎Apr 26 2023

You're not creating a Network-wide > User then? Sorry - misunderstood precisely what mechanism you're using for sign-up ...?

GreenMan · ‎Apr 26 2023

If you're connecting to the MX via VPN (non-Meraki or AutoVPN) then the Security & SD-WAN > Firewall configuration does not come into play (including port forwarding etc). You do need to get your VPN configuration right though, to enable the desired subnets to communicate: https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Non-Meraki_VPN_peers If the VLANs on the destination MX, that you need to scan, do not have VPN enabled, they will not be reachable. This is configured under Security & SD-WAN > Addressing & VLANs In terms of traffic filtering, the ones that affect in-VPN traffic are configured within the Security & SD-WAN > Site-to-site VPN menu.

GreenMan · ‎Apr 26 2023

I'd recommend you connect the Metro ethernet via WAN2 and configure proper SD-WAN, to address this. As it appears it's an entirely private connection, you may want to ask Meraki Support to enable 'No-NAT' on the Metro ethernet uplink. You would probably configure the primary uplink as WAN2 then, provided you don't advertise a default route from your SD-WAN Hub(s), Internet traffic will break out locally - and you would configure an any x5 SD-WAN flow preference for Internet traffic to prefer the Internet link. Thus both services would be backed up over the opposite link.

About GreenMan

GreenMan

Community Record

Badges