Within Wireless - Access Policy "Assign group policies by device type"... then select ALL the types and assign your PSK-ONLY-BLOCK-Group Policy 😉      Then within Network-Wide clients page - Add client section to override and assign a group policy to actually allow things 😉      ... View more

Hey @WarrenG ! I've definitely encountered this before and as mentioned above you could leverage a firewall to do it like @PhilipDAth and or leverage @Inderdeep 's ideas as well! A 3rd option... (because Meraki is SO flexible 😉 ) You can: --> Create an SSID with PSK and enforce a group policy to be applied that has deny ANY ANY. --> Under Network-Wide, Clients - Add a client by MAC address     --> Specify a unique Group Policy that grants access to that client MAC either globally or PER-SSID --> Sit back like a Dashboard DJ! Hope that helps as well! ... View more

Hey @lpopejoy !!!   I can totally understand the spirit of your comment. ...likewise, I was saying similar things back in the day!   (And now brace yourself for my employment bias... O:)    To your specific call out about MX14 firmware and older, the reality is that it's harder than most think to support a vast array of MX products/chipsets/models/etc AND at the same time maintain a congruent dashboard experience across almost all platforms! ...consider an older MX60 (released in 2012) all the way to MX450! Likewise, the other balance is maintaining Meraki Simplicity. Meraki has built a legacy of quick, simple, yet powerful configurations via a beautiful dashboard. In doing so, there will potentially be some concessions as we can't know all the nuances of what customizations each and every customer might potentially like/want/etc. Some might then call all our options to daunting and complicated where another would say just right... or vice versa.   One of the most important elements of this... is the seamless flow and logic of the dashboard. While we do develop features quickly, we're always keeping in mind the look, feel, and dashboard experience. We would hate for our dashboard to start to feel cluttered, overly complicated, or unintuitive. So there can definitely be a delay in feature to dashboard visibility too.   **But wait there's MORE!** Fortunately, we have savvy dashboard DJs like yourself who call in and ask for things via support or use the "Make a Wish" button... those things come to life! Literally, we try to develop directly for the customer needs as they grow! -->Dashboard things that USED TO BE "Support enable only certain things"... Wireless RADIUS Auth - Wireless VLAN tagging - Wireless VPN tunneling - Bonjour forwarding - Wireless Minimum bitrate bar - Band Steering - URL Based Walled Garden Domains - Mandatory DHCP - MX WAN2 (small desktop MXs) - WAN2 local status page only... now on dashboard! - 1:Many NAT - MX OSPF/BGP - Inbound Firewall Logging - Umbrella integration - AnyConnect - RADIUS 2.0 timers (Check out this DOC updated today!!!)... and many many many more...  So keep hammering that dashboard and bubble up all the ideas, thoughts, and ways we can make your experience better because not only do we listen but we have pivoted in product trajectory based on direct feedback from customers like yourself! and yes... support would love to get some things off their plate too! 😉 ... View more

Nope.    Client VPN is VERY basic and does just that.  Now if you want to get FANCY and see where most of our work has been going... Check out using AnyConnect for Meraki MXs!  https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance ... View more

+1 @BrandonS !   Think of it as creating a new, fresh, logical separation between all your other subnets... and not wasting! O:)  ... View more

Nice! Thanks for that @Naresh_Bhardwaj !   I would echo what @BlakeRichardson mentioned. If you're using the MX for DHCP, double check your Security & SD-WAN -> Addressing and VLANs page and make sure your subnet VLAN "MX IP" is configured correctly. Because based on that configuration, the client would be getting the IP address directly from the LAN the AP is plugged in to. Another Question: Does the Meraki Dashboard report the correct/expected IP address of the client device at Network-Wide -> Clients?   If the dashboard is correct, then I would guess there could be a VPN or proxy setup on the local machine. So while you're getting a local IP, there could be an agent on the machine that is forcing the traffic elsewhere.   As always, with ALL Meraki products that you own and are licensed for... Ping Meraki Support too! They can jump into your dashboard and validate your findings and give you real-time feedback to help you work your way through it!   You can go to Help -> Get Help on your dashboard or view some contact info here: https://meraki.cisco.com/support/!   Hope that helps! ... View more

Greetings @Naresh_Bhardwaj !   Quick question...  Within your Wireless -> Access Control Settings under that particular SSID and under "Addressing and Traffic" do you happen to be using "NAT Mode"?   If so, Meraki's cloud handles the DHCP of the client. This is done in order to isolate/segment guest traffic from all of your other infrastructure. For more information check out our handly dandy doc: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/NAT_Mode_with_Meraki_DHCP  -Cheers!   ... View more

@Bruce! Thanks for the announcement!!! Here are some reminders to make sure your dashboard is READY to go! How do I enable this feature? Prerequisites?   Navigate to Network-wide > General and set "Traffic analysis" to "Detailed: collect destination hostnames." This will add Traffic analytics to your Monitor tab the next time you refresh (Network-wide > Traffic analytics).      To enable the Hostname visibility feature: Navigate to Network-wide > General. Select "Traffic analysis enabled" from the Traffic analysis drop-down menu located in the Traffic analysis section. Select “Report specific hostnames” from the Hostname visibility drop-down menu.  Click Save Changes Enabling hostname visibility will allow you to view statistics about specific hostnames and IP addresses that are visited by clients on your network.    What are the feature integrations? Where do I see this?   Application Tracking  Network-wide > Traffic analytics Network-wide > Clients > Application details Firewall rules Security & SD-WAN > Firewall > Enforce Layer 7 deny rules Wireless > Firewall and traffic shaping > Enforce Layer 7 deny rules Traffic shaping rules Security & SD-WAN > SD-WAN & traffic shaping > Traffic shaping rules > Enforce L7 traffic shaping policy Wireless > Firewall and traffic shaping > Enforce L7 traffic shaping policy SD-WAN policy Security & SD-WAN > SD-WAN & traffic shaping > SD-WAN policies > VPN traffic > Enforce L7 SD-WAN policy Group policy rules Network-wide > Group policies > Layer 7 firewall > Enforce Layer 7 deny rules Network-wide > Group policies > Traffic shaping > Enforce L7 traffic shaping policy   How do I verify whether an app classification is supported? Protocol Pack details? The signatures supported by NBAR2 on devices are delivered via Protocol Packs. Refer to the NBAR2 Protocol Pack library for more details on the app support - link       For more information regarding the NBAR integration, please refer to the following cross-product documentation: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Network-Based_Application_Recognition_(NBAR)_integration Happy NBAR'ing!!!   ... View more

@DarrenOC Definitely working with the MS390s and seeing the customer base growing!!! ... BUT not with anything older than MS14.16 firmware O:)  Wifi6 AP --> MS390 --> MX ... FULL STACK NBAR!!! 🤯  🤓 ... View more

Hey @max10! Thanks for reaching out! I would say first and foremost, start with a site survey. The value of this can't be highlighted enough. Performing an active wireless site survey is a critical for deploying a high-density wireless network and helps to evaluate the RF propagation in the actual physical environment. The active site survey also gives you the ability to actively transmit data and get data rate coverage in addition to the real-world range.   In addition to verifying the RF propagation in the actual environment, it is also recommended to have a spectrum analysis done as part of the site survey in order to locate any potential sources of RF interference and take steps to remediate them. Site surveys and spectrum analysis are typically performed using professional grade toolkits such as Ekahau Site Survey or Fluke Networks Airmagnet. Ensure a minimum of 25 dB SNR throughout the desired coverage area. Remember to survey for adequate coverage on 5GHz channels, not just 2.4 GHz, to ensure there are no coverage holes or gaps. Depending on how big the space is and the number of access points deployed, there may be a need to selectively turn off some of the 2.4GHz radios on some of the access points to avoid excessive co-channel interference between all the access points. Some other things to ponder: Video streaming requires 3 Mbps for HD quality video... will you even allow that?  What type of traffic WILL you allow? A network this dense should only be configured to use 20MHz channels Challenging outdoor mounting locations / directional antennas / etc Wifi Cell overlap should be 15-20% for voice/video services and 5-10% for just basic data usage  All of those above however, will require a site survey to validate/deploy as well!  So, I would definitely work with a partner or some of the site survey tools mentioned above!   Good luck! ... View more

Greetings @hmc250000! What @DarrenOC is true! HA configuration is quite straightforward and the doc you originally posted should do! To your questions: "Where do we configure the VIP?" The VIP can only be configured on the WAN interfaces "Can we use private ip addresses?" Private address space can be used for your WAN interfaces including your VIP - likewise, these must be in the same subnet. So just make sure there is at least a /29 to accommodate the 3 address. A-WAN1/B-WAN1/VIP How would this work for the LAN?" Typically, we see, depending on the placement of the MXs and the gateways, the LAN ports configured as transit or management networks. There also needs to be communication between the LAN ports of each MX via a switch downstream in order to exchange VRRP heartbeats. The MX doesn't participate in STP, so it is best like Willette.Works' doc mentions to prune out your Mgmt/Heartbeat VLAN on a specific LAN port to prevent unintended BPDU flooding.   Hope that helps! ... View more

Hey @Greyston! Thanks for reaching out! Quick clarification: Meraki APs don't tunnel/connect/need a Cisco WLC for their connectivity. They will, however, listen to your other Cisco AP wireless infrastructure and adjust their channels, power, etc to make sure the experience of connected clients is ideal. Another point to note: Meraki MESH will only mesh with other Meraki APs. This is only because Meraki developed a proprietary mesh that will seamlessly allow a wired uplink to flip to a wireless uplink and not miss a beat with connected wireless clients. So, all that's to say - If you would like to use a ruggedized Meraki AP anyone of these outdoor models (MR70/74/84/76/86) should work! You could drop a couple of these and barring wireless environments be able to mesh them with any other Meraki indoor AP in an area that doesn't require the ruggedization. Also, here's an interesting design if you want to wirelessly mesh a switch over as well! https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link If you weren't to go the Meraki route, you can buy a Cisco AP and install Autonomous mode firmware and build a WGB via CLI to talk to another Cisco autonomous mode AP... but that's another forum for another time 😉 Hope that helps! ... View more

@arapheon VRRP will absolutely be implemented as this is the mechanism we leverage to elect which is the active MX. Do keep in mind VRRP advertisements are sent out the LAN ports only (once every second) as there is no guarantee the WAN ports will be able to communicate so they won't be sent out those interfaces. As far as your initial post about DHCP/VPN drops, I would definitely open a ticket with support so they can validate the issues you're seeing and offer their expertise!  Hope this helps! ... View more

Yep! What @cmr mentioned! The MX will be your gateway for all your devices... and it's WAN port will be plugged into your cable modem (which will give out DHCP by default) - then your MX will NAT all your network devices down stream. The FLAW with your design is the COPIOUS amount of hours you'll spend configuring, troubleshooting, upgrading, etc all your Ruckus gear O:)! An MR46 or two would be a nice touch! 😉 Cheers! ... View more

@PhilipDAth Quick clarification! 😉  Cisco ISE is not required to leverage Adaptive policy. You can assign devices/groups/SSIDs/Interfaces SGT values via the dashboard. Likewise, you can natively: Define Policies, Source/Dest/SGT value/Descriptions Create groups and bind them to network objects Create custom ACLs to apply within policies Apply specific Adaptive policy to targeted networks In order to dynamically authenticate and assign unique user SGTs, then Cisco ISE is an EXCELLENT choice to do so!  (@BobbyMcLeod Likewise, Cisco ISE is only NAC that can hand out SGTs) ... View more

NO NAT requires 15.3+, so while your 15.42 is not labeled "beta" it does support it and support will be able to find that documentation.   Keep in mind: This is a beta feature, and we do not recommend beta features for production environments, however, if your deployment requires the use of this feature, we recommend testing in a lab environment first.   Also, if this is a scenario to terminate a MPLS connection, we recommend using the MX in passthrough mode or terminate MPLS connections on the LAN side of the security appliance whenever possible. ... View more

@ww is correct - you can call into Meraki Support and they will be able to enable a No-NAT option, however, there are other ramifications that will happen that Support can explain.   I'm curious what the design is because we have a lot of customers who manage the Meraki way without the No-NAT option. A lot of times Meraki solves problems differently than the traditional networking ways and therefore one may not need a feature that was traditionally used in the past. ... View more

@SdotB While I may not be able to diagnose what is wrong, hopefully this could help you grasp the "Reason:Reserved"! 😉 Reason codes are based on IEEE 802.11-2012 standard and for the wireless LAN management frame parameters. So, when there is a deauth and that deauth meets specific IEEE specifications, that reason code will be reported. However, when that deauth doesn't match, nor meet any of the IEEE defined specifications, the reason will be: "Reserved". (Which admittedly can be a LOT of reasons!) So, if you were to run a packet capture from the dashboard on the AP and dig into the frames, you'd be able to find the Deauthentication and management frames report that same reason. My recommendation would be to run a monitor mode capture and then submit that to Meraki Support. A monitor mode capture will be able to hear all the things in the air and not be limited to just want the AP hears. This could help illustrate and/or isolate where to focus your attention. Instructions for setting up a monitor mode packet capture can be found here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine  Hope that helps! ... View more