Understand Meraki cloud check-in process

Cisco Meraki is the most popular cloud-managed IT solution in the world, it has already billions of devices check in the cloud and running online every day. One of the fundamentals of using and troubleshooting these fancy MX/MS/MR/MV’s is to have them online first, while sometimes it’s not the case for end-users. You can of course call in the customer service for the help, but you will still need to assist locally and provide enough information for the support agent to analyze and decide the next steps.

Here, I want to walk you through the tests that I have done at home and figured out the Meraki cloud check-in process, which may help you fix the problem quickly without spending time talking to the support agent.

Before we jump into the test details, we need to know the below knowledge as well.

1. Meraki devices build the encrypted tunnel to certain cloud servers for the management traffic flows, incl. status reporting, firmware upgrade, configuration download. You can find the region of which cloud servers your devices connect to at the bottom of your dashboard organization page.
2. In order for Meraki devices to connect to the cloud, the dashboard “firewall info” lists the IP arranges and ports that have to be allowed at your uplink side (both your own upstream firewall and the ISP).
3. Your devices have been added into your dashboard organization and a network already, otherwise the devices will end up with nowhere to check-in.
4. There are certain cloud VPN registry servers for devices to connect at the UDP port 9350 and/or 9351. This is one of the best parts with Meraki Auto-VPN technology, the cloud servers are controllers for it.
5. The cloud servers open its UDP port 7351 for devices to build the management tunnel on. At your device side, it will be a random port.
6. We will not touch NTP, SNMP in this article, but those are very key services for the devices to run smoothly.

My organization locates in the North America region on n158.

The firewall info page from my organization.

The list below IP (range) that needs to be opened for the device uplink monitoring functionality.

Now, we can talk about the tests that I have done.

The network topology is as follows:

ISP modem ← → Z3 (to set firewall policy) ← → A layer 2 hub (for Wireshark packet capture) ← → MR42 (test device)

I also connected a PC to the hub to run the Wireshark application to capture all packets at the MR42 uplink side. Means the check-in packets between MR42 and the cloud.

The Z3 is up and running where I can set firewall policy to block or allow IP ranges and ports between the MR42 and the cloud.

With all the above setup ready, I started the Wireshark capture on PC and powered on the MR42.

Finding #1:

After the MR42 got its IP address, it tried to connect to the following cloud servers at port 9350, which means these two are the VPN registrars serving my device.

Unfortunately, I’ve blocked them, so MR42 would never get any responses.

Finding #2:

It connected to “canireachthe.net” successfully and seems to get what it wants. (I don’t know what this step is for. Welcome to share your thoughts on this matter.)

Finding #3:

It tried a series of DNS queries.

google.com, this is for uplink monitoring. (further capture shows that it has round robin to three websites for the uplink monitoring at google.com, yahoo.com and meraki.com)

mtunnel.meraki.com, to find the master server of the Meraki cloud.

mtunnel3.meraki.com, this should be a backup server of the Meraki cloud.

cs158–2037.meraki.com, this should be the configuration server of my device to connect to, and get its config file from.

Finding #4:

It is very interesting to see during all above DNS queries, there are cloud check in packets to the n158 cloud servers.

These IP addresses should be directly got from the stored config file on MR42.

Further test shows that even blocked the IP addresses of my n158 cloud servers, mtunnel.meraki.com & mtunnel3.meraki.com, the device can still get online with the cloud IP address at 64.62.142.12, which I believe is the reserved destination if the general cloud servers are not available.

Summary:

If the device has ever checked in to the cloud before, there is config file stored locally on the device. Therefore, the device will try to connect to the cloud servers with port 7351 at below order:

• n158 primary & secondary servers. (209.206.52.208, 209.206.48.98)
• mtunnel.meraki.com (nslookup at your end to see what it is.)
• mtunnel3.meraki.com (108.161.147.161, it may alter at your end.)
• mtunnel.meraki.com
• 64.62.142.12

Meantime, the device also tried to fetch its configuration files from its cloud config server. To my test, it is cs158–2037.meraki.com via TCP port 7734.

Please make sure your upstream open those IP ranges to secure a proper Meraki cloud connection.

Q you may have a question:

What happens if I factory reset the device? Will the check in process be different?

The answer is YES and the process is quite straight-forward:

After the factory reset, the device has the built in destination server (DNS query to config-2037.meraki.com), interact via TCP port 7734, then redirect to your cloud server (DNS cs158–2037.meraki.com), interact via TCP port 7734, get its config file and/or upgrade firmware.

And the device starts normal check in process to the configured primary and secondary cloud servers via UDP port 7751.

I hope this article helps you troubleshoot your Meraki device cloud check in problem, at least it can narrow down the issue and shorten the lead-time.