About Bruce

Bruce

Hey @miguelsegura25, welcome to the community. I agree with you about Meraki and the Dashboard, its a unique platform. Hope you learn some things from the people in here and enjoy Meraki!

Bruce

No this is not possible. The Meraki meshing is proprietary and only works between Meraki access points (i.e. MR devices). I don't believe there is a standard for repeaters/meshing.

Bruce

I’ve been thinking about this, and have to agree with @MG41372 . It does look like the total tunnel count for a full mesh with hubs needs the L1 to be squared. Take for example three hubs, if they each have one uplink the formula works, and gives the answer 3. However, consider if each hub has two uplinks, then each of the three hubs will try to build 4 tunnels to each other hub (W1-W1, W1-W2, W2-W1, W2-W2) - whether it succeeds or not is all part of the design, but this is what the hubs will try and do. Quickly you realise this is a total of twelve tunnels, so the L1 must be squared to make the formula work

Bruce

The one point to remember with ACLs on the MS switches is that they’re applied to all traffic entering the switch, not going between VLANs - hence why there is no default deny all, as that would render the switch inoperative out of the box (it would just deny everything). And they’re stateless too - so just because they allow traffic in one direction, doesn’t mean they’ll let it come back the other way. As you’ve discovered this actually provides some great flexibility as it means you can actually stop clients from communicating within a VLAN. It also means that to stop communication between VLANs you could use deny rules that specify the source IP as any, the destination IP as the other VLANs subnet, and apply it to the source VLAN, simple as that. Then you don’t actually need the rules on the firewall to block inter-VLAN traffic as it is blocked as it enters the network. There are a couple of gotchas to watch out for. The MS390 switches still have limitations on support for switch ACLs, and the MS120/125 switch model also have restrictions.

Bruce

If you have both those APs in the same network then the MR18 will stay on 26.x firmware when you set the network to 27.x, the MR33 will upgrade. There will also be a number of the newer features (e.g. WPA3, iPSK without RADIUS) that you won’t get access to as they rely on all APs in the network having the more recent firmware.

Bruce

I wouldn’t say it was dead easy, but a nice challenge.

Bruce

@RobinGanderton if the modules worked in other devices and another link, and are being correctly reported as you state then I’d tend to go with it being a fibre problem. The characteristics (e.g. dispersion, scattering, attenuation, and ultimately loss) required of a fibre link to support a 100Mbps link are very different to those required to support a 10Gbps link, for example a 100Base-FX module can drive 2km on a good OM3 cable, but a 10GBase-SR will only get about 300m on the same cable. You should probably find someone with optical test gear to run a test on the link to see if it is able to support the 10Gbps link.

Bruce

The ICMP messages that you are seeing are part of the MX connection monitoring that it performs, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover. It’s also worth noting the point about the traffic flows and how they may stay pinned if you’ve had a recent failover to the WAN interface connected to the MG21. You may want to contact support and see if there is any tuning they can perform on the WAN interface connected to the MG21 to reduce the polling interval for the connection monitoring. Something else they can do, which you may want to consider, is assign the Cellular Failover firewall rules to WAN2 on the MX so that you can use more restrictive rules for the traffic goes out the interface connected to the MG21, as opposed to the primary path.

Bruce

Meraki states in this document, https://documentation.meraki.com/MG/MG_Datasheets/MG21%2F%2F21E_Datasheet, about 6 to 8 Megabytes per day, plus you then need to add in the telemetry from the MX (which it send on all WAN ports regardless of which is active). Even so, you shouldn’t be getting to 1GB of traffic over a month. You might need to resort to some packet captures to see exactly where the traffic is coming from and going to.

Bruce

Just to add to all the wonderful information already shared, the MS120-8 and MS120-8LP have external power supplies, whereas the MS120-8FP has an internal power supply. It’s just another thing to ponder as you make your decision.

Bruce

The recommended topologies are shown in this document, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair. However these don't cover the scenario with only a single LAN switch. I would suggest that you have two links from the switch to each of the MX, that way the failure of a single link won't cause a dual active scenario. You will need to ensure your LAN switch supports Spanning-Tree Protocol (STP) so that you don't end up with a Layer 2 loop.

Bruce

Hi @Andi1, is there more to your network on the LAN side, like a switch or something? If you just have a link between the MXs then it’s not a recommended solution. If you only have a single link to the primary MX I’m going to suggest that when this is failing you are getting a dual active scenario as both devices believe they should be active - i.e. neither is receiving a VRRP keep-alive from the other. Ultimately this is likely what is causing the issue, not sure exactly how, but guessing it’s likely to do with the VPN tunnels that are brought up and the routes that end up in the hub routing table.

Bruce

@AndyGray the MX doesn’t process a SIP packet any differently to any other packets (assuming the VoIP system uses SIP). There are no smarts in it (e.g. application layer gateway, ALG) like there is in other firewalls such as Cisco ASAs, and so the traffic should just follow the same path as any other traffic. Sometimes a SIP connection can get ‘stuck’ on WAN2 when a MX fails-back to WAN1 since if it’s using TCP (and the session stays up) the path via WAN2 stays up, which can cause problems. But that doesn’t sound like the issue in your instance. It sounds more like there is a configuration on the IP PBX that is defining the public IP address that should be used, or even caching it through what it sees from the phone? Or similarly to the above maybe the PBX is trying to hold up the SIP TCP session to the WAN IP address? Not saying it’s not the MX, but I’d look at what’s going on with the telephony system too. You might need some packet captures to really figure it out. Did you try rebooting the MX?

Bruce

You really need to get the Unfriendly NAT issue solved, whether or not the hub MX is on the edge or a concentrator, as this will likely cause issues. The Unfriendly NAT means an upstream firewalls is modifying the source port (or source IP address) differently for the two connections to the VPN registry (and potentially also the AutoVPN IPSec connection itself). The only solution is to create a static port forward on the upstream (customer) firewall and configure that manually in the Site-to-Site VPN configuration page. I don’t think I’ve ever tried to use a Z3 as a concentrator, so not sure if it will actually work (can’t see why it wouldn’t, since it’s almost the same, but it may be one of those gotchas). If it does work, then if you are able to successfully ping a device at a Z3 location from the ASA LAN then the routing is probably correct, and it is more likely the the TCP traffic is being blocked at a higher Layer (e.g. a firewall rule is blocking it). Out of interest, any reason why you are using a Z3 to connect to the ASA? Why not just connect it to a LAN port on the MX hub? (or are they on different sites?)

Bruce

Tricky one, had to use the ‘three are wrong, so the other must be right method’, and I think that got me a correct answer.

Bruce

Under Settings on the Camera page you will need to enable the External RTSP stream. It will then provide you the path to connect to the stream. You then just need an application to receive the stream and interpret it. Philip makes some great suggestions for this in his posts here, https://community.meraki.com/t5/Smart-Cameras/Need-an-easy-access-for-users-to-the-camera/m-p/124492/highlight/true#M2658. Here’s an example of the setting and link:

Bruce

@TravisFleming1, I believe what you may be seeing is a consequence of asymmetric routing. I’m guessing you have an interface for VLAN 27 on both the MX and MS, and likewise for VLAN 30. I would suggest you create a transit VLAN between the MX and MS, say VLAN 99 if you’re not already using it. Create VLAN 99 on the MX and a corresponding SVI on the MS stack, and make sure it’s permitted on the trunk between the MX and the MS. Set the default route (0.0.0.0/0) on the MS stack to use the VLAN 99 interface on the MX. Then remove VLAN 27 and VLAN 30 from the MX, so they only have interfaces on the MS stack. You then need to add a static route on the MX for the subnets of VLAN 27 and VLAN 30 with a next hop of the VLAN 99 MS stack SVI. The only other thing to be aware of is that the management interface on the MS switches can’t be in the same subnet as a Layer 3 interface on the MS. Hopefully all your MS management interfaces are in a separate VLAN and the Layer 3 interface for that VLAN remains on the MX - if not then this is probably a good time to separate them.

Bruce

Hi @ngsb. The MX devices can’t do the NAT of traffic going to a non-Meraki VPN peer, so it’s almost certain you will need to maintain the ASA (or another third party firewall) in the design. Having the ASA terminating this VPN will also let you distribute the routes to the far end into the Meraki Auto VPN, something you may not be able to do otherwise. Then you just need to work out which way round you want to position the devices. Do you want the ASA on the internet edge with the Meraki MX behind it in VPN concentrator mode, or do you have the MX at the internet edge, with the ASA behind it just to terminate the third party VPN. This may come down to what inspection you want to do on the edge - do you intend to use the Meraki Advanced Security with Cisco AMP, IDS/IPS etc., or do you only have the Enterprise license in which case you may consider using the ASA for those functions (assuming it can run the Firepower services software module). Either way, the MX68 will know of all the routes to the Z3 sites through Auto VPN, and you’ll need a static route from the MX68 pointing to the ASA for the cell routers (which needs to be advertised ‘in’ the Auto VPN). In the reverse direction you’ll need a route from the ASA to the MX68 for traffic to reach the Z3 sites. Ideally you’d want all the Z3 sites to exist under a single summary route if possible, that will make things much easier (e.g. each Z3 site is a 192.168.x.x subnet, and this can be summarised as 192.168.0.0/16 in a static route on the ASA). This is the basics, there will likely be other things you will find you need to do, and also some you could (like dynamic routing).

Bruce

Hubs will always connect to other hubs, that is standard Meraki AutoVPN operation. With spokes you can select which hubs they will connect to. The exit hubs should work fine. What you are describing sounds similar to what is often called regional hub-and-spoke in this document, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_Auto_VPN_General_Best_Practices I doubt this will assist with some of your issues, which appear to be due to the Great Firewall, but as a concept it should work.

Bruce

@Dutra the MX outbound firewall rules will be applied to any traffic that is going from the LAN side to the WAN side (but not into a VPN/SD-WAN tunnel - the Site-to-Site VPN Outbound firewall rules apply to theses), or that is going from one VLAN to another on the LAN side. The static route will just direct traffic where to go, the firewall rules will only be applied if the traffic crosses one of the Layer 3 boundaries I mentioned above.

Bruce

@Dutra, creating a outbound firewall rule won’t allow the reverse inbound traffic to initiate the connection, it will only allow a flow that was initiated in the outbound direction. As Philip stated you’ll need to connect the network to a LAN port with its own VLAN. The outbound firewall rules apply to traffic that is ‘outbound’ from any VLAN, which includes going from one VLAN to another, so you can create outbound firewall rules that apply to traffic sourced from the non-Meraki network with a destination of the Meraki networks. All this assumes there is no AutoVPN or SD-WAN involved.

Bruce

Did the installer provide you a test report showing the loss across each of the fibre cores from end to end? It sounds like a fibre problem, but as Philip said move the switch and test with a patch lead, that will pretty much confirm if it’s the fibre run or the kit.

Bruce

@Dunky, yep if you had a vMX in Azure then you could put in a Site-to-site VPN firewall rule and it would work, since the traffic will be Outbound at the vMX (and so hit the firewall). That would be another solution - nice idea.

Bruce

@AlexP, I have to agree with @Dunky in that I thought the Outbound Site-to-Site VPN firewall was a stateful firewall. After reading @Dunky‘s post I thought I’d try it in my lab… So I have Pi-A on 172.17.10.10/24 on site A, and another Pi, Pi-B on 172.18.10.10/24 on Site B. The two are connected via a hub and spoke Auto VPN, the hub being site H. With no Site-to-Site VPN firewall rules I can successfully ping from 172.17.10.10 to 172.18.10.10, and also from 172.18.10.10 to 172.17.10.10 (the reverse). I then put in place a deny rule on the Site-to-Site VPN firewall, Deny ICMPv4 from source 172.17.10.10 to destination 172.18.10.10. I then ran the ping test again. The ping from 172.17.10.10 to 172.18.10.10 failed, as expected. However, the ping from 172.18.10.10 to 172.17.10.10 was successful, which makes me believe the Site-to-Site VPN firewall is stateful. As the first ICMP message to 172.17.10.10 was seen in the inbound direction it stored the state and allowed the return (outbound) message from 172.17.10.10 toward 172.18.10.10, even though the firewall rule should deny it if it was stateless. Therefore I believe the Site-to-Site VPN firewall is stateful. It would be great to get confirmation of this, or if there are any flaws in my testing (other than it just being for ICMP). @Dunky, if as per above, the Site-to-Site VPN firewall is stateful then there is no solution to your problem as the inbound connection will always establish state, and thus be permitted in the outbound direction. As @ww stated, you may be able to achieve something with a Group Policy applied to the destination client (the ACLs in them are stateless), or alternatively put a third party firewall into the solution that can apply inbound firewall rules to the VPN, which will terminate the non-Meraki VPN peer (and may also provide for other flexibility for the non-Meraki peer too).

Bruce

Officially the warranty is only valid for the original equipment owner, it doesn’t transfer if they sell it (I have heard of devices being replaced under warranty for the second owner if they have a valid license, but it can’t be guaranteed). You can sell the device, but often you may find people reluctant to purchase them as they can’t be sure it isn’t claimed, and you can’t give them the serial number until they’ve purchased it (as they could just claim it and stop anyone from using it). If you do sell it they will need a license, so it’s good to let them know that. You should also advise whether it’s a -NA or -WW version as that will determine where it can be used (assuming you’re happy to ship overseas if requested).

Bruce

Community Record

Badges