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

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

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

Would Group Policies applied to the specific VLANs be useful in your environment?   https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Creating_and_Applying_Group_Policies ... View more

Well, I guess this depends on how you're taking a look at the MS450. It's designed as aggregation switch that's able to handle connections from several high performace distribution switches. Are you going to have 1Gig there? Possibly not by today... ... View more

Does this help?   https://documentation.meraki.com/MS/Other_Topics/MS_Switch_SFP_and_SFP__Overview https://meraki.cisco.com/lib/pdf/meraki_datasheet_sfp.pdf ... View more

MX68-style security appliance coupling the WiFi possibilities from MR with 8021.x available switched ports that also support LACP. ... View more

So often I‘m right on track with you Philip. In case of Stealthwatch, I really tend to disagree!   I‘ve done many POVs and customer implementations (Stealthwatch Enterprise in this case) and when you „only“ compare the Dashboard info, you‘re missing a whole lot of things. We found so many security issues that no Dashboard, SIEM or IPS in place ever noticed. ... View more

Hi Janice,   just scheduled a date. Hopefully some input from a Cisco partner addressing the whole security portfolio will be useful to you ... View more

What happens if you configure the ASA to route the subnet(s) behind the MX to the MX? ... View more

How does the ASA reach the prefixes behind the MX? Could you post a „show route SUBNETBEHINDMX“? ... View more

with Meraki AutoVPN, routing would be set up automatically for you. Here, you‘ll have to do it manually.   The question is: have you set up a static route on both ASA as well as MX pointing towards themselves for the connected subnets? ... View more

Exactly! One of the most beautiful things regarding Cloud management 😎 ... View more