Meraki

BrechtSchamp · ‎Mar 23 2019

@jdsilva wrote: Fixed! +1

BrechtSchamp · ‎Mar 22 2019

Extra info... Replies on older topics still give notifications.

BrechtSchamp · ‎Mar 22 2019

Also no notifications on the bell icon for replies I think.

BrechtSchamp · ‎Mar 22 2019

Is there anyone else not getting notification emails? I'm subscribed to all subforums but I'm not getting any emails. Happening since today...

BrechtSchamp · ‎Mar 22 2019

This is something the code you write should do, there are no parameters to do this from the API side.

BrechtSchamp · ‎Mar 22 2019

I'm not entirely sure what you're trying to do, but there are no filtering functionalities in that call (apart from the MAC-address you specify). The only thing you can do is limited the number of results returned using the perPage parameter. I tested it out and it seems to work fine here (with perPage set to 5). The startingAfter and endingBefore shouldn't be specified manually but rather use the values as returned by a call. Here's an example, I clicked the headers tab so I could show you the returned "next", "previous" and "last" links:

BrechtSchamp · ‎Mar 22 2019

Insight bases its analysis on DPI like techniques on the real user traffic. So you would have to have it go through the MX. Maybe you could have it go through the MX and fallback to your current routing instead in case of problems. But that seems like a needlessly complex setup and I'm a fan of k.i.s.s. In the future they may add the sensor functionality to the switches and APs...

BrechtSchamp · ‎Mar 21 2019

Don't know if it's the reason, but i noticed one of the dates has 213 instead of 2013. Can you give that a check?

BrechtSchamp · ‎Mar 19 2019

No need to feel dumb. How do you think I found out... 😉

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

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

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

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

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

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 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

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?

About BrechtSchamp

BrechtSchamp

Community Record

Badges