I would advise following some of the initial steps @ww suggested.  We can confirm a NAT router in front of us by examining the Appliance status page and selecting the "uplink" tab. If the WAN reads a private IP, we are likely behind a NAT. Similarly to @Brash's comments, if we have a public address configured on the WAN port and the public IP under the "General" header is different, we could be impacted CGNAT.    Another test to help confirm if the traffic is even reaching the MX is to take a packet capture on the MX WAN/internet port and then filter for either the public address initiating the connection to the server or the port the connection is to happen on (6180 in this case).    The following documentation helps cover NAT and port forwarding troubleshooting: https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Troubleshooting_Port_Forwarding_and_NAT_Rules ... View more

Hello, When the user connects we assign them a MAC address that will start with "03" and then the rest of the MAC is generated from a hash of the username.  ... View more

Hi MarkReb,  I know this is an older post but I figured I'd offer my thoughts on the topic.  The issues that have been observed on MR29+ with client balancing are because we updated to an active client balancing method that can be more aggressive and cause some client instability. These issues are much more prevalent in high-density wireless deployments with lots of clients and APs. I have not come across too many issues with band steering on MR29+. Generally, I advise having band steering enabled and client balancing disabled.  Depending on the needs of your wireless deployment and the combination of RF settings used, you could update to MR29 or 30 without issue.  For any potential issues that are observed after an update, it would be best to work with support if possible to confirm if there is a specific known issue we are hitting and get your case attached for tracking and updates on that issue.  ... View more

The flex radio settings are going to be located under Wireless > Configure > Radios Settings > RF Profiles Tab > Select your RF profile > General settings.  Note this is only going to be relevant if we have an MR57 or Cisco Catalyst Wireless 9166 AP.  ... View more

Specifically, this setting is only for Meraki-hosted Administrator accounts.   Correct, SAML accounts will use their own separate system. ... View more

OMG what a freakin confusing site. 😂 I think allowing a native alert of even having that link available from the dashboard would be a very useful tool.   ... View more

Hi ToryDav,  The MX appliances do not support multiple VLANs for client VPN and Any Connect clients. We do have the ability to assign group policies to client VPN users however that can make them subject to a different set of firewall rules.  I'd advise reviewing the following documentation: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Group_Policies ... View more

Hi Richard-Tapp,  It is advised to upgrade all APs for a network at once as it is against best practice to have a mixed firmware environment. The request to test firmware on one device can be made but it is not guaranteed to be accepted. The complication with running deprecated firmware is that it becomes more difficult to support especially if we are suspecting an issue related to a bug. We additionally would have the option to roll back firmware if we found it to be necessary.  I would still encourage re-opening your last Support case with Meraki Support to resume troubleshooting the issue and updating to a current stable firmware to help serve as an additional data point that this issue is spanning multiple firmware versions.  As you clarified the APs are offline for extended periods It would be good to access their local status page and obtain the support data file for support to review.  ... View more

Two excellent answers.   Also, when you think about it, it doesn't make sense to have a "source" when you apply a policy against a host.  The host itself must be the source. ... View more

Hi Rimccart, The NAK messages disappeared today after changing the dhcp port from trunk to access. I had configured the port that connect the dhcp server to trunk with native vlan 1. I think the dhcp server was responding to numerous dhcp requests from different vlans while on trunk hence generating the NAK messages. Happy this has resolved the issue. Thank you very much for your input. ... View more

Thanks for this! Pretty much what I was thinking. I haven't been able to easily test this because once I get connected on a device,  I don't see that windows pop up again for quite some time. It's not as easy as disconnect, turn off that policy, try again.    I'm pretty confident the device policy is at fault here. At some point I will just turn that off for a period of time and see what if the windows pop up is gone.    Thanks!  ... View more

Hi there,  If we are observing that the APs are not obeying the configured RF profile settings and there are no manual overrides specified then I would encourage you to engage Meraki support and open a case. Based upon the date of the initial post if APs have not lowered their power transmission in about 24-48 hours then there could be a greater issue.    I have observed scenarios where APs will not transmit at a forced maximum power due to regulatory domain restrictions, but I have not come across the opposite where they will not lower their maximum power transmission.  ... View more

From the image that was shared in the previous comment, the highlighted MAC address is the BSSID MAC that matches one of your own BSSID MACs broadcast from one of your Meraki APs. Placing this BSSID MAC on a blacklist could impact a client's ability to join your legitimate SSID as well. A Spoofed AP can only be found with a boots-on-the-ground approach so to say. https://documentation.meraki.com/MR/Monitoring_and_Reporting/Mitigating_a_Spoofed_AP   If we place a MAC in the block list for containment it is not going to stop the rouge AP from being detected or broadcast it is going to send deauthentication requests when a client attempts to communicate with that BSSID MAC.  https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal#Containment   As for a rouge Radius server attempting to authenticate users, we'd need to further verify what radius server is observed to be rouge and compare that server's IP address to what was configured for the Radius SSID. APs will only send radius requests to the configured servers so If there was a rouge radius server observed there would also likely be a duplicate IP address attempting to impersonate a configured legitimate server.  Meraki does not have a feature to only allow or block specific radius servers as the request is already only going to go to the specified radius serves it would not attempt to send a radius request to an address that is not configured.    If you take a capture on the AP's wired interface and observe it sending raduis request to an address that is not configured on any SSID then a support case should be opened.  ... View more