Upstream Firewall Rules for Cloud Connectivity

The Cisco Meraki dashboard provides centralized management, optimization, and monitoring of Cisco Meraki devices. In order to manage a Cisco Meraki device
through dashboard, it must be able to communicate with the Cisco Meraki cloud (dashboard) over a secure tunnel. This tunnel is created between Cisco Meraki
devices and dashboard to pass management and reporting traffic in both directions.

Because the dashboard is located on the public internet, the tunnel is always initiated outbound from the managed device. Once a connection is established, the
device maintains the connection by occasionally sending packets and receiving a response. When a firewall or gateway exists in the data path between the
managed device and the dashboard, certain protocols and port numbers must be permitted outbound through the firewall for the secure tunnel to function.

Addresses and Ports to Allow

A complete list of destination IP addresses, ports, and their respective purposes can be found in dashboard under Help > Firewall info. This list changes
dynamically depending on the devices and services added on the dashboard.

1
CSV Version

"Source_IP","Destination_IP","FQDN","Ports","Protocol","Direction","Description","Devices_using_this_rule"
"Your network(s)","108.161.147.0/24, 199.231.78.0/24, 64.62.142.12/32, 209.206.48.0/
20","","7351","UDP","outbound","Meraki cloud communication","Access points, Cameras, MX Security
Appliance, Switches"
"Your network(s)","199.231.78.148/32, 64.156.192.245/32","","9350-9351","UDP","outbound","VPN
registry","Access points, MX Security Appliance"
"Your network(s)","Any","api.meraki.com","443","TCP","outbound","API Requests",""

2
 "Your network(s)","17.0.0.0/8","","443, 2195-2196, 5223","TCP","outbound","iOS Systems Manager
communication","Systems Manager"
"Your network(s)","Any","","5228-5230","TCP","outbound","Android Systems Manager communication","Systems
Manager"
"Your network(s)","Any","","80, 443","TCP","outbound","MV cloud archive, Advanced Malware Protection (AMP)
lookups, Systems Manager agent communication, Splash pages","Access points, Cameras, MX Security
Appliance, Systems Manager"
"Your network(s)","3.210.175.34/32, 13.52.29.190/32, 13.54.51.60/32, 35.161.241.24/32, 35.162.58.56/32, 35.
162.65.76/32, 50.18.100.0/32, 52.33.92.73/32, 52.57.34.238/32, 52.59.68.120/32, 52.208.175.132/32, 198.27.
154.12/32, 198.27.154.14/32, 209.206.48.0/20","","80, 443, 993, 6514, 7734, 7752, 30001, 60000-
61000","TCP","outbound","Camera streaming proxy, Mac/Windows remote desktop, Mac/Windows agent
communication, Insight data collection, Backup Meraki cloud communication, Backup configuration downloads,
Measured throughput to dashboard.meraki.com, Backup firmware downloads","Access points, Cameras, MX
Security Appliance, Switches, Systems Manager"
"Your network(s)","192.168.128.1/32","","1812","UDP","inbound","802.1X with customer-hosted
RADIUS","Access points"
"Your network(s)","Any","","123","UDP","outbound","NTP time synchronization","Access points, Cameras, MX
Security Appliance, Switches"
"Your network(s)","8.8.8.8/32","","53","UDP","outbound","Uplink connection monitor","MX Security Appliance"
"Your network(s)","8.8.8.8/32, 209.206.48.0/20","","","ICMP","outbound","Uplink connection monitor","MX
Security Appliance"

It's important to note that different organizations may communicate with different servers, so this list can vary between organizations.

There are some circumstances where the IP address or port used to communicate with the dashboard may change. If this type of change is required,
administrators are notified in advance. Secure tunnel connectivity is also redundant and will continue to operate though a secondary connection.

Devices Using the "Backup Cloud Connection"

While devices will primarily connect to the dashboard using UDP port 7351 for their tunnel, they will attempt to use HTTP/HTTPS if unable to connect over port
7351. When devices are operating like this, a message will be displayed on the device's status page indicating that the "Connection to the Cisco Meraki cloud is
using the backup cloud connection." If this is observed, please ensure that port 7351 is being allowed outbound through the firewall or security appliance traffic
from the Cisco Meraki devices it will pass through.

If unable to configure the recommended firewall settings for the backup cloud connection due to security constraints, please note that Cisco Meraki devices will
continue to operate normally, but some features of the dashboard may be slower to respond. This includes, but is not limited to:

• Configuration updates
• Live tools
• Firmware upgrades

Unlike other features, Meraki authentication is always sent over UDP 7351 and will not work over a backup connection.

3
 Note: While it is possible for Cisco Meraki devices to operate without the recommended firewall settings in place for the backup cloud connection, the
firewall settings for Meraki cloud communication are still required for the devices to function correctly.

Devices Using the "Uplink Connection Monitor"

Cisco Meraki MX security appliances include features to use multiple redundant WAN links for internet connectivity.

These features rely on connectivity tests using multiple protocols to various public internet addresses.

We ask that network administrators allow these common protocols (HTTP, HTTPS, DNS and ICMP) to "any" internet address to allow the connectivity tests to
function correctly.

Upstream Firewall Rules for MV Sense Settings

In instances where MV Sense is configured to transmit to outbound IP addresses or upstream local resources, the upstream firewall rules will need to be
configured to allow for MQTT telemetry and analytics data to be sent outbound. These destination IP address (or hostnames) and ports are configurable on a
per-camera basis, so ensure these are recorded in a central location for all devices within your network(s). MQTT commonly uses port numbers of 1883 for TCP
and 8883 for TLS.

For Integration with Cisco DNA Spaces, MV cameras need to use port 1883.

MX Connection Tests
The MX runs tests to determine uplink status:

DNS test

• Query the DNS servers (primary or secondary) configured on the internet interface for the following hosts:
◦ meraki.com
◦ google.com
◦ yahoo.com

Internet test

• Pings to either 209.206.55.10 or 8.8.8.8. One ping per second.

• Uses a round-robin technique to send an HTTP GET to http://meraki.com or http://canireachthe.net. An HTTP
response of any kind will result in a success.

ARP test

• ARP for the default gateway and its own IP (to detect a conflict).

Connection monitoring runs on the uplink once it is activated, meaning a carrier is detected and an IP address is assigned (static or dynamic).

The first test DNS query is sent, if a DNS response is received, DNS is marked as good for 300 seconds on that uplink. During this time, the MX continues
running the DNS test every 150 seconds. Each successful DNS query test results in DNS being marked as good for another 300 seconds.

If a test DNS query times out at any point, the MX decreases the testing interval to 30 seconds. If the DNS test continues to fail for a time period exceeding 300

4
seconds, which is last time the test was successful, DNS will be marked as failed on the uplink. Otherwise, a successful test will again mark the DNS as good for
another 300 seconds. Once marked as good, the test is run every 150 seconds.

Note: The MX will only decrease the DNS testing interval to 30 seconds if a test DNS query times out. Any record-type response to a test DNS query
will result in a successful DNS test.

The MX then begins performing the internet test. If either the ICMP or the HTTP test is successful, the internet test is marked as good for 300 seconds on that
uplink. During this time, the MX continues running the internet test every 150 seconds. Each successful internet test (meaning either a successful ICMP test or a
successful HTTP test) results in the internet being marked as good for another 300 seconds. If any test within the internet group fails, the MX decreases the
testing interval to 20 seconds. If the tests continue to fail for a time period exceeding 300 seconds from the last successful test, the internet will be marked as
failed on the uplink. Otherwise, any successful ICMP or HTTP test will mark the internet test as good for another 300 seconds. Once marked as good, the test is
run every 150 seconds.

When both the HTTP and ICMP tests have been unsuccessful for a period of time that exceeds 300 seconds, the uplink will be failed over. Therefore, it can take
approximately five minutes for failover to occur in the event of a soft failure (where the physical link is still up but provides no internet access).

Note: An MX will only failover to a backup cellular connection if all three tests (internet, DNS, and ARP) are marked as failed

Note: Please be aware of the failover traffic flow behavior between the primary and
secondary uplinks.

• Traffic is mapped to an internet interface by source and destination IP address and port. Any newly
initialized IP traffic matching the source and destination IP address and port of an existing mapping will be
sent over the same internet interface. This is done to preserve the connection state of certain flows that
require the source and destination to remain the same for the duration of the connection.
• Each of these traffic mappings expires after 300 seconds (five minutes) of no traffic matching the mapping.
This duration is reset each time new traffic is generated that matches the mapping. With frequent
communication between a pair of hosts, this can result in traffic consistently using a single uplink for
communication, as the mapping is continuously refreshed.

In summary, if the primary uplink goes down, all traffic will failover to the secondary uplink. When the primary uplink is back-up, traffic that doesn't
have a mapping will use the primary uplink. All traffic with an existing mapping will continue to use the secondary uplink.

These mappings can't be cleared by support. You could temporarily remove the non-primary uplink, reboot the MX/Z, or prevent the client device from
sending traffic to the MX/Z for a period of 300 seconds (five minutes).

Upstream Firewall Rules for MX Content Filtering Categories

In instances where another firewall is positioned upstream from the MX, the following FQDN destinations need to be allowed in order for categorization
information traffic to pass successfully to the MX, so it can use the proper category classifications. Keep in mind that the IP addresses these domains resolve
to will be different regionally, so ensure you are allowing the correct, current IPs if using IP-based rules instead of FQDN rules on your upstream firewall.
Domain names to whitelist on upstream firewall

• meraki.brightcloud.com (resolves a CNAME to service.brightcloud.com)

• service2.brightcloud.com