About BrechtSchamp

BrechtSchamp

What @natuan says is the only way you can do this I think. But then that WAN link has to have that dedicated IP of course.

BrechtSchamp

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

BrechtSchamp

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

BrechtSchamp

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

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

BrechtSchamp

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

BrechtSchamp

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

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

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

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

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

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

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

BrechtSchamp

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

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

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

@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

Thanks for the info. Keep us posted!

BrechtSchamp

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

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

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

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

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

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

BrechtSchamp

Good, just checking :D.

BrechtSchamp

Community Record

Badges