A good way to prevent someone from sniffing the traffic would be to segment the network the AP's sit in from the one users attach to on the wire. Simple ACL or firewall rules would prevent users from being able to sniff anything on the management vlan. If it's a concern over sniffing the air - the portal is no different security wise than what people put credit card transactions on with SSL.    If they must have AP to ISE traffic double encrypted (Radius MD5 Hash plus another) they could use a Cisco-Meraki MX and tunnel all AP traffic to it, then from it to ISE would be the only single encryption. The MX could sit in the same data center as the ISE server.  ... View more

1. The client VPN password depends on what directory the client is authenticating against - i.e. AD or the Meraki Cloud. If you are storing user names / passwords in the cloud than you have the option to make the passwords for those users strong   2. By using Active Directory as the user directory that accounts will authenticate against, passwords and the policy around them, along with automated user creation / deletion amongst other benefits can be controlled by the directory servers.   ... View more

Not that I'm aware of but as the portal itself is recommended as using SSL and any credentials sent to said portal encapsulated within that encryption, what is the requirement driving the need for L2 encryption to ISE for guest portal services?   In most deployments both the AP IP's and Radius server are on the internal networks and therefore encryption isn't a requirement.     ... View more

Out of pure curiosity as I have no answer to the why - does the graph for week to change and resemble something closer to week 1 if you change the top results to 10 as they were in week 1? ... View more

And it's still not putting that in at the end - open the link and add a ')' at the end. Not sure why that didn't paste... ... View more

https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Advanced_Malware_Protection_(AMP)   Sorry the ')" in the previous post was cut off. I don't believe it's posted to the user event logs - its all in the security center. ... View more

That seems to conflict completely with the information presented below which shows that malware or AMP is reported on in the security center;   https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Advanced_Malware_Protection_(AMP)     ... View more

I can't answer Question 1 - I believe it is a single 'array' for both 2.4/5Ghz. A quick call into support should be able to confirm the physical characteristics.   For Question 2: For both the 42E and the 53E both bands go out all 2.4/5 antenna ports - so a 42 is a 3x3:3 AP, thereby 3 external antenna ports would be required to support the two wifi bands with 3 spatial streams. Same logic behind the 52E which is 4x4:4 thus the four ports for 2.4/5. As each Meraki AP currently sold supports a four radio architecture - WiFi scanning / BLE - one port for each radio exists. This was done in the models to allow for differentiated coverage for scanning or BLE versus WiFi. i.e. Directional antenna used for the WiFi with omni for the BLE / Scanning - or visa versus depending on the use case.    I'm not sure what else you mean by band allocation other than to say its not band separated like the outdoor. Aesthetically this would start to get crazy with 8x8 (If band separated 16 antennas sticking out) and use case for indoor doesn't support for sending 2.4 into a different area than 5 (typically). ... View more

What subnet are you handing out for the VPN client devices and do you have a route for that subnet pointed back to your passthrough MX? ... View more