Meraki

BrechtSchamp · ‎Mar 19 2019

Are you doing it the right way? Input the tag, press enter, click the save button that now becomes active.

BrechtSchamp · ‎Mar 19 2019

No. While generally Meraki is forgiving in non-official support this is pushing it too far. Pretty sure the dashboard can't handle splitting up the 40G interfaces into 4 10G interfaces. Here are the officially supported SFPs: https://meraki.cisco.com/lib/pdf/meraki_datasheet_sfp.pdf

BrechtSchamp · ‎Mar 19 2019

Then do what @Ben said. Add yourself as admin to the org. It will be added to the list automatically.

BrechtSchamp · ‎Mar 19 2019

Have you checked this: https://documentation.meraki.com/MX/Client_VPN/Troubleshooting_Client_VPN What error comes up?

BrechtSchamp · ‎Mar 19 2019

I would take a packet capture in both the legacy and the Meraki setup to see the difference in the dhcp options sent in both dhcp Offers.

BrechtSchamp · ‎Mar 19 2019

https://community.meraki.com/t5/Solutions-APIs/How-to-get-Started/m-p/38861?collapse_discussion=true&filter=location&location=forum-board:api&q=Create.meraki.io&search_type=thread

BrechtSchamp · ‎Mar 18 2019

I'm afraid there's no way to control which addresses are assigned to who. Not unless you put in two separate MXs. I know that clients connecting to VPN do show up in the clients list and you could assign a group policy to them with their access rights. The problem is that I'm not sure if those entries are the same everytime they connect to the network. The name of their entries seems to be a MAC-address but I'm not sure how it's generated. If you have a lot of clients this would become problematic anyway because there's a limit to how many clients you can manually assign group policies to: 1000. Client VPN funcionality on the MX needs some work... I know anyconnect support is planned, definitely get your question in over a "make a wish" too. It makes sense to have such a feature (role-based access for client VPN) and could perhaps be added when they overhaul the client VPN functionality.

BrechtSchamp · ‎Mar 18 2019

1. https://create.meraki.io/build/scanning-api-docs/ 2. The Meraki cloud sends scanning api updates to a server/application of your choosing. 3. No separate license needed. The functionality is included with your AP subscription.

BrechtSchamp · ‎Mar 18 2019

Bragging rights... They also incentivise participation. And they activate the collector inside of us. See also this link: https://community.meraki.com/t5/Community-Tips-Tricks/Community-profile-badges-the-master-list/m-p/10733

BrechtSchamp · ‎Mar 18 2019

The packets are out of order. It would be easier to diagnose if they were in order. RST can be caused by multiple things. Likely the MX is receiving packets for TCP connections that are already closed.

BrechtSchamp · ‎Mar 18 2019

Have you tried the full url with option 66 instead of 67?

BrechtSchamp · ‎Mar 18 2019

I'd just make sure the same ssid is present in every site and use a robust wi-fi client on the vehicle. I know there are industrial APs that can be powered over dc which would be ideal in combination with the 12V dc power present on vehicles.

BrechtSchamp · ‎Mar 18 2019

Nothing yet. The feedback I did get is that it's only organized in San Francisco HQ atm so harder to arrange logistically anyway for me and my clients here in Belgium. Although I'd love to go.

BrechtSchamp · ‎Mar 18 2019

You can use the MX firewall for inter-vlan firewalling too if it's the L3 device routing between subnets. Basically you setup a rule that blocks all access to the IP address in the L3 firewall settings in Firewall & SD-WAN > Firewall. And then you indeed define a group policy in Network-Wide > Group Policies that has specific L3 firewall rules for that special group of people and assign it to them. Keep in mind that this will only work if the destination IP address you're blocking access to is on a different subnet than the source subnet the clients are on. If the special group of people are on their own VLAN you could use the regular firewall. Just add another rule with the source subnet set.

BrechtSchamp · ‎Mar 18 2019

@MerakiDave All right, thanks for clearing that up. I didn't realize there were multiple SE directors. If only there were a publicly accessible org chart :P.

BrechtSchamp · ‎Mar 18 2019

Thanks for the info. Keep us posted!

BrechtSchamp · ‎Mar 18 2019

Officially, the sizing should be equal to the MX100 so 250 tunnels. That said, this document by Aaron Willette says that that number is a bit conservative and replaced it with 500: https://www.willette.works/meraki-mx-sizing/ I believe Aaron is the global leader of the Meraki SE's one of the Systems Engineering Directors so the information is likely based on solid experience. It wouldn't hurt to consult your local Meraki SE about it though. Edit: Edited my statement about Aaron based on Dave's info below.

BrechtSchamp · ‎Mar 16 2019

L3 roaming is unnecessary in your setup as you only have one AP. I'd recommend to use regular bridge mode. Your wifi clients will get an IP from the modem. Then don't forget to allow wireless clients to access the wired subnet. Go to "Wireless" > "Firewall & traffic shaping" and set the L3 firewall to "allow" for the "Local LAN" destination. That should make everything work.

BrechtSchamp · ‎Mar 16 2019

Actually it's possible that Alexa needs to be able to communicate directly with the smart TV via the local subnet rather than the internet. So the L2 isolation would be a problem in that case. Unfortunately you can't use NAT mode without the isolation. So in that case you'd need to switch to bridge mode. This way the existing DHCP server on the LAN network would need to hand out IP addresses to the client (a Meraki MX or a provider modem for example). The clients would be able to communicate directly on the subnet. Note that this is generally not desired in guest networks. Let's say for example that your 80 sites are holiday houses and are rented out as a whole to families. Then this is less of an issue. But if multiple families/unrelated people use the same SSID at the same time this might not be desirable.

BrechtSchamp · ‎Mar 15 2019

It will not only block internet access, it will block all access to other subnets. Unless you have a flat network with only one subnet you would need to add exceptions for your local subnets to be able to communicate with each other. The rules below would cover all private ranges (but is likely overkill for you):

BrechtSchamp · ‎Mar 15 2019

Whether you do it in the regular firewall or in the group policies, 0.0.0.0/0 would be the catch-all, not /32. I'd also set the protocol as well as the port to any. Unless you know that the camera's traffic is specifically using TCP and destined for port 80. Also keep in mind that this would effectively limit the camera to only being able to communicate with devices in its own subnet. Other subnets in your own network would also be blocked. So it would make sense to add your local IP ranges as exceptions.

BrechtSchamp · ‎Mar 15 2019

I guess the news is out then :P. I thought it was supposed to be a secret until April 29th...

BrechtSchamp · ‎Mar 15 2019

Good, just checking :D.

BrechtSchamp · ‎Mar 15 2019

I assume you already submitted a wish from the dashboard? Have you reached out to an SE?

BrechtSchamp · ‎Mar 15 2019

5 minutes can happen. It depends on the kind of failure. There's more info here: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover

About BrechtSchamp

BrechtSchamp

Community Record

Badges