Sounds like contacting support is the best way to go. ... View more

There's been a couple of similar posts previously. - Solved: MR46 Wont Get DHCP IP, IP Stuck at 0.0.0.0 - The Meraki Community   If you unplug the AP and plug a different device (such as a PC) into that same switch port, does it pull an IP address? If so, try factory resetting the AP and/or opening a support case. ... View more

There's no simple way to delete clients from the dashboard. However, they will transition out of the dashboard if they haven't been seen in 30 days. You can also give them a 'blocked' policy in the meantime to ensure that they can't access anything if they reappear. However there was a mention that something like it might be possible leveraging GPDR privacy features Solved: Remove/Clear Client - The Meraki Community Not sure of manually adding a client with the same name but different MAC (I can't see why it wouldn't work) but you can definitely re-name discovered clients to have the same name.   ... View more

If the two Windows machines are on the same L2 (VLAN and subnet), it should be a fairly simple flow. What you've described is very typical of Windows firewall (especially Windows server) - blocking all inbound ping requests. For testing, I would disable the firewall completely.   Other than that, I would start by:  - Check ARP on both machines to verify whether they have address resolution for eachother. In cmd, type "arp -a"  and check for the other machine's IP.  - Run up wireshark on both machines and run a ping from one to the other to determine which direction the ping is failing.   From the above tests, you should be able to verify whether the issue is a machine not replying or the switch blocking a ping request/reply. That way you can focus your troubleshooting to the appropriate device. ... View more

Sorry, when writing up the reply, i forgot that this would be specific to Meraki (*facepalm*). Yes, the information I provided was for an ASA. ... View more

Probably not of much help here as my Anyconnect knowledge is very limited but it's definitely possible. My previous company had something similar.   Looking at the XML schema, I don't see anywhere to insert a message via XML directly. However, the description indicates it should be editable in the message catalog.   + <!-- + This control enables an administrator to have a one time message + displayed prior to a users first connection attempt. As an example, + the message could be used to remind a user to insert their smart + card into it's reader. + + The message to be used with this control is localizable and can be + found in the AnyConnect message catalog. + (default: "This is a pre-connect reminder message.") + --> + <ShowPreConnectMessage>false</ShowPreConnectMessage> Source: [PATCH] Provide profile.xml for AnyConnect (infradead.org)     Looks like the message string is under localization settings Solved: SSL VPN (AnyConnect) and Customize Preconnect Message - Cisco Community     ... View more

Yes, either should be fine ... View more

Not quite. You need to ensure that your internal DNS can forward requests that it doesn't have the answer for.  These should be forwarded to another DNS that does have the answer. Typically you would set up to forward to an external, top level DNS, such as 8.8.8.8 (Google's DNS) or 1.1.1.1 (Cloudflare DNS ... View more

You'll need one of those set up in order to resolve domains external to your environment, including the Meraki dynamic domain name for your MX. ... View more

When you say doesn't resolve correctly, is it resolving to any IP address at all? Is your client PC using a well known internet DNS or an internal DNS? ... View more

As the client has already been given an IP address, it will typically hold onto it until expiration. It would be up to the client to request a new IP from the DHCP server.   Most operating systems will support this in one way or another but you'll need to log onto the client directly. Worst case scenario, rebooting the client should also force it to pull a new IP. ... View more

It sounds like you're thinking of applying static IP's to known devices and dynamic IP's to unknown devices in a completely flat network, and setting firewall rules based on whether it's a 'static range' or 'dynamic range' within the same overall subnet.. If that's the case, it's theoretically possible but pretty poor from a design perspective and I'd probably advise against it.   From a high level, there's probably a few better ways you could do this.   The cleanest way I can think of that would cover both wired and wireless clients is RADIUS 802.1x authentication. Essentially, your devices authenticate to the RADIUS server and are placed into a VLAN (based on a designated filter). You can then apply the rules to the VLAN.   For your scenario, on the RADIUS server you can setup MAC address whitelisting  for your known clients, and then send all other clients to a separate VLAN using CoA. Clients can then be 'transitioned' from unknown to known by adding the MAC address to the whitelist.   References: MS Switch Access Policies (802.1X) - Cisco Meraki Configuring RADIUS Authentication with WPA2-Enterprise - Cisco Meraki     Otherwise, you can simply separate known from unknown by applying separate VLAN's, and separate SSID's (or using Identity PSK with group policies if the same SSID is required). ... View more

I thought Meraki insights was under a completely separate licensing SKU separate from the enterprise, adv sec, etc. ... View more

Neat.   Assumedly it's a new feature coming out soon but can't find any more information on it. All external documentation still points to only a single Enterprise license for the Z3.   I'm guessing something will be announced soon over at Feature Announcements - The Meraki Community ... View more

In case anyone stumbles across this and it helps them, I opted for option 1.   I opened a case with Meraki support who enabled the No-NAT feature very quickly. I then configured the appropriate static IP on the MX in pre-staging. Then during deployment, all that was required was literally moving an Ethernet cable from the existing router to the MX.   When we do the final phase of moving away from MPLS, I'll re-enable NAT, fix up the WAN IP and configure the SD-WAN tunnel with DIA. ... View more

Thanks @MeredithW  Congrats to the top contributors... Killing it as always.   A great community indeed. ... View more

Meraki recommends using the hostname precisely for the reason you mentioned. In the event of a WAN failover, the hostname should update to the new WAN IP.   In regards to getting it working, using a hostname vs an IP address shouldn't make a difference as long as the hostname resolves correctly. Are you using the Meraki dynamic hostname or do you have another hostname defined? Does the hostname resolve to the correct IP on the client PC? ... View more

It doesn't look like you have a rule for DHCP/DNS. This may or may not be required depending on your setup and design.   Have you verified whether users are able to obtain an IP and can resolve the domain names? Have you verified that the firewall rules are applying correctly? (Eg. Performing a telnet for the TCP ports)   If the above are successful, you may be missing some specific rules for the applications. ... View more

A @Owen advised, you will need to use the SFP ports for your WAN connection. You essentially required a 1000 Base-T SFP.   The Meraki brand SFP is MA-SFP-1GB-TX. You can find the full SFP datasheet here   The linked SFP should work (Meraki devices accept 3rd pary SFP's) but there's no guarantee on compatibility or reliability.   ... View more

It sounds like your clients are getting de-authorized. Wireshark would be a good place to start to see who is sending the client the deauth.   There's other tools (both paid and open source) out there which dig further into WiFi analysis. You should be able to find some with a few google searches and checking some forums. I can't personally vouch for any as I've never had to use anything more than Wireshark. ... View more

Good to hear you were able to make some progress.   Dropping the MTU on the Meraki switch shouldn't have made a difference. It just needs to be the same as or higher than the MTU at the source and destination endpoints. When working with MTU, also make sure to check whether the value to be input includes the Ethernet header or not. From memory ESXi takes the payload size (9000) but some products will expect payload+header (9216).   One other test you can do is path isolation. Do the eui's in the latency alerts indicate a specific destination or path? I don't remember off the top of my head if they're path specific or device specific identifiers. If you have the ability to do so, you can isolate down to a single path and then work your way up re-enabling additional links/paths until you hit issues. ... View more