Wow! Guess this day will be my own „Meraki day“ From now on: earlier today I had the chance to take the CMNA class / lab and coming home I find myself featured here. Thanks a million for the having me! 🙂 ... View more

It's documented on https://developer.cisco.com/meraki/api/#/rest/api-endpoints/admins/create-organization-admin ... View more

Silly question: have you rebooted the MX? ... View more

You don‘t have to specify a VLAN. Just create a group policy including the QoS settings and assign it to the specified client. ... View more

Having a similar setup myself...even without a business behind it, I‘d say that‘s a pretty great line of defense. Levering Umbrella, I‘ve seen many things in the meantime, I didn‘t even think I‘d ever see in my own environment. Not only here but especially in client environments. It really adds a huge amount of security.   After all, you‘ll receive a huge 👍 .  😎 ... View more

Could you please gibe a little more details about what the question is or what your goals are? ... View more

Please see above, my post was edited: using another SSID, everything worked out of the box. Great stuff!  😎   Thanks a lot for your help!  👍 ... View more

Thanks for chiming in Philip!   Just to clarify: The Filter-ID attribute contains a specific Group Policy „Guest“. This group consists of firewall rules and is also passing the VLAN ID for the guest network. Isn‘t it meant to be this way?   However: looking at the dashboard, I can see the Group Policy is being applied by 802.1x for this client and also the VLAN is correct. As soon as I‘m manually configuring an IP address from the guest VLAN, everything starts working flawlessly as expected. DHCP also doesn‘t work in this case if I‘m trying to manually renewing the IP in this case. Using the Guest SSID directly, DHCP works out of the box though.   EDIT: Strangely enough, using a „fresh“ SSID for that (same settings) everything works including DHCP. Guess I simply messed up somewhere else. ... View more

If you‘re planning take a deep dive into ISE, don‘t even bother with the „official“ trainings from FastLane, Experteach etc.   I‘d highly recommend Aaron Wolands „Cisco ISE for BYOD and secure unified access“  http://www.ciscopress.com/store/cisco-ise-for-byod-and-secure-unified-access-9780134586663   You possibly won‘t find a lot about Meraki integration but will get a clear picture of what ISE is being capable of and how to configure it. ... View more

OK guys, unfortunately I‘ll have to disturb again. Had the chance to play around with it and ran into an issue I‘m unable to solve currently:   Client is being authenticated by ISE, policy („Guest“) is correctly applied. At least I can see the 802.1x applied policy on the client detail page Corresponding group policy contains a specific VLAN tag (Guest VLAN) as well as L3 firewall rules that prevent the client to access LAN segments Although the client is successfully connected, DHCP (provided by an MX that‘s the default gateway for the Guest VLAN) isn‘t successful. Configuring a static IP leads to expected network connectivity though   As you can see, I‘m currently stuck with finding out why DHCP won‘t work in this case. Using the Guest VLAN directly, DHCP is working flawlessly. Any hints would be highly appreciated. ... View more

Thanks a lot for the share! Starting to like this one a lot currently.   From my point of view, one thing is half-way missing if you want to use group policies from that document. At least it's not shown:   "Creating Authorization Profiles for Each PSK with Group Policy Assignment Navigate to   Policy > Policy Elements > Results > Authorization > Authorization Profiles Click add and create at least 1 PSK Authorization Profile. In this example, PSK1 is used and   'PSK1' is returned as the dashboard group policy to apply to the client via Filter-ID."   In a nutshell, the attribute being used in the AuthZ Profile is "ACL (Filter-ID)"? Has somebody tested this?   EDIT: Found the answer here https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Using_RADIUS_Attributes_to_Apply_Group_Policies ... View more

From my point of view, it'd be rather odd that the speed is too slow for handling authentications. Whenever I had to deal with certificate based 802.1x, it came down to fragmentation / MTU issues.   Perhaps that's another topic to consider if you're willing to discuss. ... View more

You could use the Dashboard: Security & SD-WAN -> Appliance Status. There you can see the status and network usage of your WAN interface(s). ... View more

Damn right, sir. The only thing the infrastructure will see is the VPN tunnel. Everything that‘s inside of it is being effectively hidden...which is the definite reason to use it. 😉   For that matter, VPN will also circumvent Layer 7 rules. The only Layer 7 rule coming into play is the one for the „outer“ traffic, aka VPN tunnel. ... View more

Thanks a lot for the explanation @Raj66! ... View more

Depending on where the MX is to be placed, you‘re stuck either with mandatory NAT or having to run a possibly not „ready“ No-NAT implementation.   From a technology point of view, MX is kinda comparable even to Cisco Firepower: it also runs Snort and uses the same AMP engine (you already mentioned Threat Grid). If you want to have more possibilities than „activate IDS / IPS with a specific ruleset and whitelist rules“, you‘ll not be very happy with it (which is similar to e.g. Check Point from what I‘ve heard). The simplicity on the other hand is unbeatable here. AMP and Threat Grid are great security products but only if they‘re able to see the traffic. With the current percentage of encrypted traffic the MX will have a hard time „seeing“ / analyzing threats unless the TLS decryption is officially available (if it makes sense or not though). Decryption performance on current MX seems way lower than Firepower though.   After all, there‘s one thing you won‘t ever beat with Meraki: the dashboard as single pane of glass for everything regarding your network which is of course very favorable when it comes down to OPEX. ... View more

Let me get straight to your questions:   1) Yes, by default everything is allowed on MX 2) Have you bound the group config to the correct VLAN interface? In a nutshell and giving a sneak preview for question 4: you don't need a source here because the source is the VLAN the group policy is bound to. This has to be taken care of in the firewall ruleset 3) If you want to prevent your Wifi devices (from the Wifi VLAN) to everything else, you will have to have sereal "Deny" statements (or use a supernet if possible). Otherwise, the policy looks rather fine 4) As said above: if you're using group policies only, there will be no "Source" column. If you need to specify specific source IPs, you would rather use the "global" firewall ruleset (Security & SD-WAN -> Firewall).   Hope that helps... ... View more

Looks like real fun! I also wouldn't decline a visit. 😉 ... View more

The whole point of the built-in cellular is for redundancy, along with warm-spare. This seems like a major flaw in my eyes. Exactly that's what it is. What's the point in having a setup that's as highly available when the "last line of defense" won't work anyways?   I'd be more than grateful if the Meraki folks could clarify this. 😬 ... View more

Wow, that‘s great news indeed! ... View more

Though I'm unable to help, I'd like to give out a friendly advice:   You're posting to a public forum where people spend their spare time to help out others. Spitting out half sentences without giving any clue that would enable them to help you could definitely be a wise decision. 🙂   To this specific case, for example the NPS setiings would help narrowing down the issue could definitely help... ... View more

So...what exactly is your question?! ... View more