Meraki

GIdenJoe · ‎May 10 2023

If you navigate to Security & SD WAN -> Site-to-site VPN you will find halfway the page Organization wide settings. And there you will find your VPN peers. There is a grey X on the right to remove one.

GIdenJoe · ‎May 10 2023

The features you request are not available on the Meraki software stack. I believe if you need those features you will need Cisco Catalyst at least at your distribution layer. If your access layer is layer 2 you can use Meraki MS switches if you like the dashboard for your monitoring but at the distribution layer and beyond you will need advanced platforms that support your features and those can be found in Cisco Catalyst. Remember that also 3 families of Cisco Catalyst switches can be monitored in dashboard but configured using CLI or other ways,

GIdenJoe · ‎May 8 2023

Oh yes that is a typical one. If you have a public subnet behind the ISP router you will need to run a /29 if you want a primary/standby firewall. You only need to configure the external vlan on your switches. The other possibility is just to have the ISP run a private subnet behind their router like the typical 192.168.0.0/24 and you use 192.168.0.2 as virtual IP on your HA pair and have the ISP port forward every incoming flow to that IP.

GIdenJoe · ‎May 8 2023

You're no configuring a port but the management address of the switch. You can't have L3 interfaces on an MS120. It would also not make sense to have a management VLAN with a /31. If you would however have an MS2x or higher you can create VLAN interfaces and those will need to have a /30 or less.

GIdenJoe · ‎May 5 2023

Interesting. It would be interesting to have a premade filter that filters out NAT events and only shows the wanted flow logging. it would be handy if the "pattern" bit would also mention the matched rule number to make it easier.

GIdenJoe · ‎May 5 2023

I'm not sure about that: the sentence below throws me for a loop 😉 quote: I have a few devices changing to wifi from wired but want to maintain the same static IP addresses and have them all grouped together.

GIdenJoe · ‎May 4 2023

You can have the same VLAN's available for both wireless and wired users. However your pc has separate NIC's for wired and wireless connection and will connect on both simultaneously.and thus will not be able to have the exact same IP address.

GIdenJoe · ‎Apr 25 2023

For that you need to filter using localnet. So for example localnet:10.1.0.0/24. Then your usual actions are available on AP or MX where you want to use the traffic shaping. So you can use bandwidth limit (obey, ignore, set limit) which is per flow. And of course setting the priority and DSCP values. On wireless you can also set the PCP which selects the WMM queue.

GIdenJoe · ‎Apr 19 2023

If your traffic does not pass an MX you won't be able to see if traffic was dropped. If it does pass an MX you will have to use syslog and point your MX to that for it's flow logs and log all your deny rules to see what deny rule it matched.

GIdenJoe · ‎Apr 18 2023

We only had an issue with an update on W10 last year and that was fixed with a out of band update. The behavior there was that after receiving MM2 (main mode message 2) from the MX the MS client did simply not continue the IKE exchange. Maybe you could capture on your WAN side using filter (port 500 or port 4500) or the WAN IP of the client trying the VPN and determine if it is indeed stopping there or if there is another clue like a mismatch in IKE transforms.

GIdenJoe · ‎Apr 17 2023

Meraki does not use any public facing bug ID's like Cisco does. Perhaps internal they use them but you should ask them directly. For now be assured that this is a known issue listed in the Firmware issues.

GIdenJoe · ‎Apr 16 2023

I believe you have two options: 1) you could start with adding static routes for each branch pointing to the LAN interface of the old org Hub MX. And then when you move a branch to new org, first delete the static on old org and then the route should come in via new org AutoVPN. 2) you could make a summary route that contains all your branches on new org pointing to MX in old org hub. And then just add branches with a more specific mask. I'm not sure this would present an error. It surely will give you a warning to confirm at least.

GIdenJoe · ‎Apr 14 2023

Yes I believe that has been recognized as a bug. I also recently did a single stack member poweroff to test something and we also had the packet loss. Even the most recent MS 15.21.1 firmware has this issue according to the firmware release notes. Excerpt: Ms2xx/35x/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10)

GIdenJoe · ‎Apr 14 2023

As you said, your new design is layer 2 so the provider hands it off as layer 2 info. So you could perfectly add the switch in the DC to your HQ network. I don't know where your gateway lives (on your core MS or on your MX) so make sure both those interfaces for vlan 10 and 20 live on the same device. Also for your original design without the layer 2 link. If your local DC would have been behind a concentrator mode MX and your DR site also then you could have had equal subnets at both sites.

GIdenJoe · ‎Apr 5 2023

If you capture your WAN interface and filter on the host IP of the other side or filter on port 500 or port 4500 you have to see the security association frames. It might be possible that you'll have to start a ping from an inside interface on your MX to an IP on the LAN on the other side (even if it does not exist) to trigger an attempt to bring up the tunnel. Also watch on your fortigate if it is set to responder only that you have to initiate on the MX in that case. If it is IKEv1 you should see 6 main mode messages and 3 quick mode messages. If you use IKEv2 you only have 4 messages. You have to filter on the same initiator SPI to get the packets only pertaining to a certain session or setup your wireshark with an IPsec profile containing useful columns to quickly see where in the exchange it is failing. You will see messages with INFORMATIONAL message coming from the device that does not like what the other side is sending. Most common are: - One or both of the devices are behind NAT and you are getting the IKE-ID wrong. (failure will happen right after the packets are encrypted) - You still have wrong parameters at any end and there are no matching phase 1 policies (you should see it fail after the first message) - You use IKEv2 and you have multiple local or remote networks and the device on the other side can't put everything in one SA.

GIdenJoe · ‎Apr 5 2023

I'm eager to read your findings 🙂

GIdenJoe · ‎Apr 4 2023

I believe it is a dashboard modification. I'll have to test with another customer that has MR46E combinations. Most of our customers are quite up to date with the MR software so I can't be 100% sure if there are any changes in the firmware that facilitated this. I invite any customer/MSP's that manage MR46E's to test this out.

GIdenJoe · ‎Apr 4 2023

Hi all, Last few years multiple topics in this community were about the limitations on the MR46E's transmit power in combination with one of the MA-ANT-3 models. example: https://community.meraki.com/t5/Wireless-LAN/MR46E-Too-low-2-4-Ghz-transmit-power-in-ETSI/m-p/150004 These antennas had in their specs the mention of a per-element antenna gain which caused Meraki dashboard to limit your transmit power even more below what we were used to. Normally you just take your max allowed EIRP and subtract the antenna gain to reach your maximum Tx power. However this per-element mention made it so that you had to subtract an additional 6dB on an MR46E which would put the max Tx power in Europe with a ANT-3-F6 to 2 maybe 3 dBm... 😉 I have recently noticed on a customer dashboard that this limitation has been removed and you now can treat the antenna gain again like any normal antenna. So in the case of my example you can set the Tx power to 8 dBm instead of 2. Also on the 5 GHz band you can now go way higher even on the channels that only allow up to 23 dBm. No longer need to put the channels on 100 and higher to fix this.

GIdenJoe · ‎Apr 4 2023

You really need to survey the area and use multiple antennas to see what provides the best coverage. The AP is not the issue here because it is only allowed to send 9 dBm on 2.4 GHz because your antenna has 10.x to 11 dBi of gain totalling the EIRP at 20 dBm which could be the max in your region. However if you choose a slightly lower gain antenna you could up your Tx power to match that. 5 GHz is allowed to transmit higher but you get a 6 dB penalty due to the smaller receive antennas. Your area may simply be too large to cover with two antennas.

GIdenJoe · ‎Apr 3 2023

I've had my fair share of stacking cables but I have yet to find any faulty one. I'll keep a look out for any though.

GIdenJoe · ‎Mar 30 2023

Oh this explains it. I thought it was a bug triggering all kinds of repeat messages 😉

GIdenJoe · ‎Mar 29 2023

MAC address filtering is not an easy thing to do on Meraki AP's without a radius server. Usually you have to have a splash login page without valid users and then create a group policy that bypasses that splash page. You can then add the mac addresses as clients on the client page and apply that group policy to them.

GIdenJoe · ‎Mar 29 2023

Once you're done in the brunch offices, do you also go to the dinner office? 😜 In all seriousness, you can easily use the MX at the hub in concentrator mode and even use BGP with your Fortigate to route your internal subnets to it if you have some servers there. The choice to also do full mesh is just a little checkbox on your spokes (the brunch offices) and then you can apply those policies on your Fortigate also. However to do that make sure you have alot of upstream bandwidth in your main office since all internet traffic will be going from the internet to the main office, back out the main office towards your brunch offices.

GIdenJoe · ‎Mar 21 2023

Those are inbound rules. These don't exist in IPv4 since those are in the port forwarding section. Scroll a bit to see the OUTBOUND rules. Then you should be able to create v4, v6 and dual stack rules.

GIdenJoe · ‎Mar 17 2023

The most important part is first to check where your root bridge lies. Is the Aruba switching in the CORE/DISTRIBUTION and are they root also for the CIST? Then you should not have any issues with a downstream Meraki that has regular priority values. Or is it the other way around? If so you'll have to draw out your MSTP topology and where the master port lives.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges