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

Currently, as @alemabrahao  stated, API and creating an alert based on the API result would be the best solution for a low-power mode alert. There is no native dashboard email alert or AP alert status for low-power mode. I did take a moment to use this topic and submitted a feature request surrounding this idea and having a native alert for low power mode.  ... View more

Hi Keith_Li,  If enabled, all accounts under that Org will be forced to enable and set up 2FA. If DUO is your preferred MFA app it can be used but you are not limited to it.  ... 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

Both messages from @PhilipDAth and @BlakeRichardson are helpful. A situation like this is going to need a more in-depth review of the device-to-cloud communication and Meraki Support should be able to help with this.  If we can, we should try to avoid rebooting the devices to recover them. Rebooting an offline device before it has an opportunity to reconnect will clear device logs and then Support would not be able to get much data on any outage event.  ... View more

Hi zball8888,    This is likely because one network has AD integration enabled and the other does not. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies#Available_Options   Please see the above doc and the second blue note: " Note: Source IP addresses on layer 3 firewall rules are only configurable on WAN Appliance when active directory integration is enabled. " Can you confirm if one site has AD integration enabled?   ... View more

Hi Richard-Tapp, From the issues that are described, it may not be specific to Africa that would cause this constant disconnection behavior for the networks. To help narrow the scope a bit further is this issue only observed to impact the device management traffic to dashboard, so clients do not see an issue themselves? When the APs are disconnecting is it a short flap or will be be prolonged periods? Is there any means to recover the APs manually or do we wait for a natural recovery? What is the current AP firmware? Newer firmware should be using TCP 443 for dashboard communication. It may also help to have APs on the latest firmware as well (MR30.5 currently).  What IPs and ports were observed in the packet captures? ... View more

Hi Benkip,    It sounds like this is only impacting one SSID, correct?  If this is only impacting a particular SSID are there any settings on this SSID that drastically differ from the others? This could be the SSID configurations or the RF profile settings as well if the bitrates are set per SSID.    When we see this DHCP failure log in Meraki have we examined the impacted client's timeline as well? Were there any additional events just before this DHCP failure, such as roaming or disconnection events? ... View more

Hi Benkip,    The logs for the DHCP server rejection is curious. What are the DHCP server logs indicating when the wireless client is attempting to connect to the network? If a capture is taken at the DHCP server to the DHCP server switch port is the NAK originating from the server? Did the update to MS15.22 alleviate the believed unexpected behavior that was being hit? ... 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