Meraki

Bruce · ‎Mar 15 2021

Yes, when the secondary MX becomes active it uses the IP address of the primary MX, there is only one IP address for each VLAN on the LAN side. No, there will be one STP forwarding, and one STP blocking connection per MX. So in your diagram both links to Switch A would likely be 'STP Active'. The MXs communicate at Layer 2 all the time through VRRP frames. You can't use a single IP address on the outside for a HA pair of Meraki MX, you need a minimum of two - one for each MX, this is because the redundant MX still needs to communicate with the Meraki cloud. With three IP addresses the VPN shouldn't drop when you failover to the redundant MX (since one IP address is passed from the primary MX to the standby); with two IP addresses the VPN tunnels will be torn down and rebuilt as the IP address changes.

Bruce · ‎Mar 15 2021

You don't need to use 192.168.1.0/24, but you can. As you are behind the NetGear router, and appear to have a Private IP address on the WAN port of the MX64, you will need to ensure that the NetGear is forwarding ports UDP500 and UDP4500 (for IKE and IPSec NAT-T) to the IP address on the WAN port of the MX64. Have a look through this document too, it may provide some assistance, https://documentation.meraki.com/MX/Client_VPN/Troubleshooting_Client_VPN

Bruce · ‎Mar 15 2021

Sorry, I thought you got the error when you were creating the Client VPN. If you were able to put 192.168.1.0/24 into the Client VPN configuration on the Meraki Dashboard then that is fine. You don't need to create this VLAN/subnet on the MX. When you have the VPN client on your Windows machine working you will see both the 12.168.128.xxx address, and you'll also see the address of the VPN/L2TP adapter, which will be in the 192.168.1.0/24 range that you added under client VPN in the Meraki Dashboard. If you're not getting the 192.168.1.0/24 address then your client VPN isn't connecting for some reason. Have a look in the MX event log and see if there are any messages there.

Bruce · ‎Mar 15 2021

Whatever you want.... say 172.16.1.0/24 if you're not using that anywhere else.

Bruce · ‎Mar 15 2021

The subnet that you create under Security & SD-WAN -> Client VPN must be different to the other subnets that you have created on the MX. The client will be given an IP address from this subnet, and the MX will handle the routing from that assigned IP address to the other subnets on the MX.

Bruce · ‎Mar 15 2021

The 'Bandwidth' field that you highlighted is applied to every client on the network across the total of their traffic. The 'Traffic Shaping' fields allow you to apply specific traffic shaping for a traffic type. That shaping may have to be within the limits of the client or it could ignore the per client limits, and it may apply only to one or more applications, hosts or networks.

Bruce · ‎Mar 15 2021

If you’re currently running in one arm concentrator mode then you need to swap to Routed mode first, Security & SD-WAN -> Addressing & VLANs, then the configuration of the LAN ports appears on the same page. Before you swap to Routed mode be sure you understand your network and traffic flows, if you don’t then you risk breaking your SD-WAN. This is especially true if you have a traffic path over a MPLS network, in this case you may struggle to use Routed mode (it may be the reason why the VPN concentrator was implemented).

Bruce · ‎Mar 15 2021

By all means give it a try, but I’d be surprised if it works any better. Every time I’ve had APs on the same channel it’s just given me headaches - with the exception of where I’ve expected that, like mesh with just a couple of APs. You don’t need power injectors if you want to try it, just switch the APs to a VLAN with no DHCP server. Just be aware that because the AP is on the same channel and is broadcasting the same SSID as another, it doesn’t mean a client can connect to it. A client still has to associate to the AP before it can communicate with it, that’s no different to when the APs are on different channels. If you can then give it a try, the client may more readily associate with an AP on the same channel, than one which isn’t, so roaming may work better, but you’ll also get more interference. If the clients are old then they’re probably not using some of the newer 802.11 amendments (e.g. 802.11k),or they may just not be implemented in the client’s stack, so just see what works best for your environment.

Bruce · ‎Mar 15 2021

Sticky clients are a common problem. Unfortunately it is the client that makes the final decision when to roam. You can try and influence this by changing minimum data rates or lowering power levels (even modifying RX-SOP in some instances), but sometimes the clients just won’t budge. There are some times parameters you can modify on the client too. Mesh only works if the AP can’t get a wired connection (I.e. it can’t get a DHCP address), and then the APs automatically converge onto the same channel (they scan for the meshing SSID). If you’ve got wired connections to the APs then I’d stick with using wired.

Bruce · ‎Mar 14 2021

Okay, not being able to specify the source interface for the Ping from a MX is just to do with the firmware version. The summary of what you've proven so far is the following: There is a path from the MXs LAN interface (192.168.235.170) to and from the DVR since you are able to ping the DVR from your machine when on the same subnet. The MX is correctly performing the port map from the outside to the inside; you've shown traffic captures of traffic to x.126.204.197:8014 from the WAN, and captures to 192.168.3.14:8014 from the LAN interface. In all cases of traffic coming from outside the WAN only SYN packets are ever seen, no return traffic is seen. Between the MX and the DVR (if my understanding is correct) there is a Fortigate device providing SD-WAN services, and a ASA in front of the subnet that the DVR is on. My gut feel at this point in time is that the reverse path for traffic from the DVR back to the MX is broken for public IP addresses (remember that the port map doesn't change the source IP address of the incoming packet, only the destination). This is going to be on either the Fortigate or the ASA. Although they correctly route traffic back to the 192.168.235.0/24 network, they're not routing public IP addresses back (e.g. 189.53.34.42). It is entirely possible that there is a firewall/ACL blocking the traffic, but more likely I'd go with a routing issue. You'll need to troubleshoot this from the other end, either the DVR, the ASA or the Fortigate (the closer to the DVR the better), to see if you can route traffic out to the internet via the MX.

Bruce · ‎Mar 13 2021

I think you’ve pretty much hit the nail on the head. You’re essentially following Method 1 in this, https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX. Couple of points to note: You’ll need to configure the IP address, subnet, gateway, etc. of the new MX250 on its local status page. There’s no need to remove the more specific routes as they’ll be dropped from the AutoVPN when the device goes down anyway (one less step). If you’re not using dynamic routing between the MX and the switch you may need to adjust the routes on the switch end so traffic doesn’t get black-holed (and put them back later). When the new MX250 comes up you will need to re-enable AutoVPN, it will come up initially as AutoVPN ‘off’, but when you swap it to ‘hub’ all the old config will be there. Hope it all goes well!

Bruce · ‎Mar 12 2021

Because a system is cloud managed doesn’t mean you’ve given a third party company full control of your network any more than trusting that the firmware installed on a Cisco/Aruba/Huawei device doesn’t provide a back door to your system for that organisation. No user data passes through the Meraki cloud it only used for control, and Meraki have very strict controls and procedures in place about who has access to what. You can find a great deal of detail on this at https://meraki.cisco.com/trust. It is also possible to completely block access to your organisation if you believe it is sensitive: I understand that this is a big step for some people, but I’d say it’s less of a risk than storing data in Microsoft OneDrive/M365, AWS, Azure or GCP - where the hosting company potentially has access to real information about your company and what it does. To that end I know that Government organisations in a number of jurisdictions trust the Meraki network platform, whereas they have specific M365 environments (deployed by Microsoft) specifically for Government and their agencies to meet their data storage requirements. All up every customer should understand how their network is controlled and where their data is or isn’t stored, but please make sure that what you are communicating to clients is accurate and valid.

Bruce · ‎Mar 12 2021

Yep, it means that. If you are doing a full tunnel (I.e. the hub is the default route) then no traffic will exit the spoke directly to the internet, it will all go into the tunnel and exit via the hub. However, I’d suggest that more often than not the spoke MX would be configured as split tunnel so internet traffic gets routed directly from the spoke MX so the hub doesn’t become a bottleneck. Configuring the firewall rules on a MX isn’t generally too hard anyway. By default they allow all outbound initiated connections, and deny all inbound initiated connections.

Bruce · ‎Mar 12 2021

Is 172.20.20.1 the ASA, or is the ASA after that gateway? Which Source IP did you use when you did the ping from the MX?

Bruce · ‎Mar 12 2021

Meraki switches do running Spanning Tree Protocol (rapid spanning-tree to be precise), but other than the priority of switches there is nothing more that you can configure. However, they do follow all the normal STP rules that you’d expect.

Bruce · ‎Mar 12 2021

The Z3 only has one uplink, if you want two uplinks you need an MX - MX64 is the smallest.

Bruce · ‎Mar 12 2021

Have a look on the ASA and the DVR if you can as it looks like there is nothing at all coming back from the other end. It’s most likely either a routing issue from the MX - either to or from the DVR - so try pinging each device you expect in the path from the MX until you get a failure (starting with 172.20.20.1), or it’s a firewall/access-list. Does the ASA have a default route for unknown IP addresses?

Bruce · ‎Mar 11 2021

Can you do a longer capture (maybe on the LAN interface of the MX?) to see what responses are coming back from the DVR, if any. That packet only appears to be the SYN of the TCP handshake, or is that all you are seeing? Are there any ACLs or firewalls on the DVR itself to prevent access from public IP addresses (or unknown IP addresses)?

Bruce · ‎Mar 11 2021

Looks like you’re doing a port forward from the WAN IP address of the MX to 192.168.14.3. Is there a route towards that network on the MX? The route you’ve posted is for 192.168.15.0/24, which doesn’t encompass the address in the port map.

Bruce · ‎Mar 11 2021

Some thing like these? Media converter with PoE? Can’t say I’ve ever used one, but should be the answer. https://www.perle.com/products/media-converters/poe-media-converters.shtml

Bruce · ‎Mar 10 2021

@Mloraditch, @Skachroo, yep, my mistake, you can't get an Advanced Security license for a VMX. They don't have that option, because they don't support that capability. Its worth noting though, that this is one of the few exceptions where you can use an ENT license when the rest of the organization is licensed for Advanced Security. If this is for Azure its worth checking with your Meraki rep whether its supported or not as Azure still isn't listed on the Meraki website yet, https://meraki.cisco.com/product/security-sd-wan/virtual-appliances/vmx-large/. Supposedly its meant to be happening soon...

Bruce · ‎Mar 10 2021

You’re about right with the difference between Warranty and SmartNet (or Meraki Now as I believe it’s called on the Meraki kit - or was initially). The Warranty covers you for hardware replacement (in theory only so long as the device has a corresponding license), most devices are lifetime warranty, although some like camera and outdoor APs aren’t. With the Warranty you get advance replacement of a failed device, with a next business day replacement within commercially reasonable efforts. Now depending where you are in the world, and where the closest devices are that may or may not end up being next business day. SmartNet/Meraki Now improves on the Warranty by allowing you to extend the hardware replacement period for those devices that aren’t covered for their lifetime, but again you need to have a valid license for the device. It also allows you to purchase improved replacement times, e.g. 24x7, 24x2, and with or without an engineer. There is also a next business day option, which almost guarantees what it says, so better than the Warranty. The difference is that with SmartNet/Meraki Now Cisco actually make sure they have spares located close to the install address.

Bruce · ‎Mar 10 2021

Should be something like LIC-VMX-L-ENT-1Y - change the ENT to SEC if needed, and the number of years.

Bruce · ‎Mar 10 2021

You can mark traffic however you like, and create whatever QoS scheme you like within your organisation. You then assign the markings you choose to the queues you want. Most people stick to one of the well-known schemes so that it’s easier for someone else to follow. Specifically with marking video as AF46, assuming you mean DSCP 46 or EF, then my concern would be that if your also running voice as EF then you may impact the voice quality. Voice works best with low jitter, introducing video packets into the queue may increase jitter since unlike voice, video is not a smooth consistent bandwidth, it varies a lot. The other consideration is that depending on how much of your smaller links video is using you may reduce the overall effectiveness of QoS. If you prioritise too much traffic then you might as well prioritise none - the guide used to be to give the highest priority to no more than about 30% of link bandwidth (with modern bandwidths this is usually not a problem).

Bruce · ‎Mar 9 2021

Finally MX16 code is available in public beta, here are the firmware release notes. Important notice This is an early-stage beta version for the MX 16 release. Due to this, we recommend taking additional caution before upgrading production appliances. Where applicable, MX 15 or MX 14 releases will provide a more stable upgrade alternative. Due to a regression currently under investigation, MX appliances may be unable to establish cellular connectivity on both integrated cellular modems and external USB modems. We recommend that customers that rely on cellular connectivity in their deployments wait until a later MX 16 release to upgrade. Legacy products notice When configured for this version, Z1, MX60, MX60W, MX80, and MX90 devices will run MX 14.55. Mx 16 new feature highlights Added support for Cisco AnyConnect client VPN on Z3(C), MX67(C,W), MX68(W,CW), MX84, MX100, MX400, MX600, MX250, and MX450 appliances. Added Network-Based Application Recognition (NBAR) integration. Bug fixes Stability improvements for MX67(C,W) and MX68(W,CW) platforms Corrected an issue that resulted in MX appliances incorrectly using their WAN interface MAC address when 1) the MX appliances are configured in high availability, 2) the MX appliances are configured as one-armed VPN concentrators, and 3) traffic was being sourced from the shared virtual IP. MX appliances will now properly use the virtual MAC address in these cases. Fixed an issue that could cause IDS/IPS rule lists to not update. Updated the AnyConnect VPN service Corrected an issue that could cause the IDS/IPS process from not restarting properly after a configuration update. Resolved an issue where DNS responses directing clients to a content filtering blocked page were improperly forwarded to the WAN network when an MX was configured as a passthrough appliance or one-armed VPN concentrator. Mitigated an issue that resulted in traffic flows being incorrectly mapped to a secondary WAN interface during the bootup process of MX appliances. Fixed an issue that resulted in traffic from client devices connected through an AnyConnect client VPN connection to MX appliances configured as one-armed VPN concentrators not being processed correctly. Resolved an issue when 1) Client VPN is enabled and 2) an MX appliance is configured in one-armed VPN concentrator mode, the MX appliance may be unable to establish connection to the Meraki Dashboard after a reboot. Security and stability improvements Known issues After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions Some stability-impacting issues present in MX 14 that affect a small population of MX67(C,W) and MX68(W,CW) appliances still exist. Some stability-impacting issues present in MX 14 that affect a small population of Z3(C) appliances still exist. Please note that until certification has been obtained, the Z3C will not be supported on Verizon's network. World-wide device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed in North America and North America device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed outside of North America. When deployed in warm spare / high availability (HA), MX67C and MX68CW do not support using their cellular connectivity to pass client traffic. In this deployment, the cellular connectivity can only be used for device monitoring or network troubleshooting. This is an expected limitation for these platforms. MX67C, MX68CW, and Z3C units must be connected to the Meraki Dashboard initially to retrieve an update to allow for proper use of the integrated cellular connectivity. This is most likely to be an issue when bringing the units online for the very first time. On the MX67(C,W) and MX68(W,CW) platforms, when the MX is providing PoE to a connected device, this information will not be reflected on the Meraki Dashboard. Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240. Significant performance regressions for VPN traffic may be observed on MX84 and MX100 appliances Group policies do not correctly apply to client devices Z3(C) appliances that are upgraded to MX 16 versions cannot directly downgrade to MX 14 releases. They must first downgrade to an MX 15 release. MX IDS security alerts are not detected for Anyconnect VPN traffic BGP-learned routes may not be properly reflected in the Route Table page on the Meraki Dashboard, despite BGP and packet routing operating correctly. There is an increased risk of encountering device stability issues on all platforms and across all configurations.

About Bruce

Bruce

Community Record

Badges