Home > Architectures and Best Practices > Cisco Meraki Best Practice Design > Best Practice Design - MX Security and SD-WAN > General MX Best Practices

General MX Best Practices

Security Tools

The Security Center in the Meraki dashboard provides a centralized view for security filtering events. This includes both IDS/IPS and Advanced Malware Protection (AMP) events.

The Security Center provides information and insights to a network administrator through a variety of different components, each focusing on different analytics and uses. The top of the Security Center page allows control over the data being viewed.

An example info card for an IDS/IPS signature is included below. Selecting Show only this signature will only show events related to that signature.




These filters will be displayed below the navigation and control panel and can be dismissed by clicking the X on the right-hand side.




Security Center provides a variety of visual components to understand the security events on the network including Retrospective Malware Detections and Events over time shows the number of events matching configured filters  over a specified interval of time.






Read more about using security center In our Security Center article.

Intrusion Detection

You can enable intrusion detection by setting the Detection option to Enabled under Security Appliance > Configure > Threat protection.  When enabling intrusion detection, there are three distinct detection rulesets to choose from using the Ruleset selector:

  • Connectivity: Contains rules from the current year and the previous two years for vulnerabilities with a CVSS score of 10

  • Balanced: Contains rules that are from the current year and the previous two years, are for vulnerabilities with a CVSS score of 9 or greater, and are in one of the following categories:

    • Malware-CNC:  Rules for known malicious command and control activity for identified botnet traffic. This includes call home, downloading of dropped files, and exfiltration of data (unauthorized retrieval of data from client devices)

    • Blacklist:  Rules for URIs, user agents, DNS hostnames, and IP addresses that have been determined to be indicators of malicious activity

    • SQL Injection:  Rules that are designed to detect SQL Injection attempts

    • Exploit-kit:  Rules that are designed to detect exploit kit activity

  • Security:  Contains rules that are from the current year and the previous three years, are for vulnerabilities with a CVSS score of 8 or greater, and are in one of the following categories:

    • Malware-CNC:  Rules for known malicious command and control activity for identified botnet traffic. This includes call home, downloading of dropped files, and exfiltration of data

    • Blacklist:  Rules for URIs, user agents, DNS hostnames, and IP addresses that have been determined to be indicators of malicious activity

    • SQL Injection:  Rules that are designed to detect SQL Injection attempts

    • Exploit-kit:  Rules that are designed to detect exploit kit activity

    • App-detect:  Rules that look for and control the traffic of certain applications that generate network activity

The Balanced ruleset will be selected by default.

Intrusion Prevention

You can enable intrusion prevention by setting the Prevention option to Enabled under Security Appliance > Configure > Threat protection.  Traffic will be automatically blocked if it is detected as malicious based on the detection ruleset specified above.

Content Filtering

Content filtering allows you to block certain categories of websites based on your organizational policies. You can also block or whitelist (allow) individual websites for additional customization. For example, if you block the "Internet Communications" category this also blocks gmail.com and facebook.com because both websites are communication platforms. You can whitelist gmail.com and facebook.com to make sure that both websites are fully operational while all other websites providing chat functionality are blocked.


You have several options related to Content Filtering:

  • Blocked website categories: Select the categories you wish to block.

  • URL category list size: Select "Top sites only" for higher performance or "Full list" for better coverage. When "Top sites only" is selected, the list of top sites in each of the blocked categories will be cached locally on the appliance. In this mode, client requests for URLs that are not in the top sites list will always be permitted (as long as they are not in the blocklist). If "Full list" is selected, a request for a URL that is not in the list of top sites will cause the appliance to look the URL up in a cloud-hosted database. This may have a noticeable impact on browsing speed when visiting a site for the first time. But the result will be cached locally. Over time, the "Full list" performance should approach the speed of "Top sites" option.

  • Web search filtering: Enable this setting to enforce Safesearch for Google, Yahoo!, and Bing for all users in your network. This will not affect SSL/HTTPS searches.

  • Block encrypted search: Because Web search filtering cannot block encrypted searches, when it is enabled this option will appear. Enabling Block encrypted search creates a Layer 7 firewall rule that prevents users from accessing encrypted Google sites (with the exception of Gmail). Because Yahoo! and Bing do not use encrypted search. This will prevent users from circumventing Web search filtering by using encrypted Google searches.

  • Youtube for Schools: Enables Youtube's 'Youtube for Schools' functionality. This also requires you to enter a Youtube EDU ID.

  • Blocked URI patterns: Enter specific URI patterns you wish to block, one per line. See below for details on pattern matching.

  • Whitelisted URL patterns: Enter specific URI patterns you wish to explicitly allow, one per line. See below for details on pattern matching.

Advanced Malware Protection

Advanced Malware Protection (AMP) is an industry-leading anti-malware technology from SourceFIRE, integrated into MX Security Appliances.

AMP is available only in the Advanced Security Edition licensing.

It is important to understand several key concepts with AMP:


A file's disposition is a categorization from the AMP cloud that determines what actions are taken on the file download.

There are three file dispositions:

  • Clean - The file is known to be good.

  • Malicious - The file is known to be harmful.

  • Unknown - There is insufficient data to classify the file as clean or malicious.


Sometimes files will change disposition, based on new threat intelligence gained by the AMP cloud. This re-classification can also generate retrospective alerts and notifications.

AMP Integration Overview

The MX Security Appliance will block HTTP-based file downloads based on the disposition received from the AMP cloud. If the MX receives a disposition of malicious for the file download, it will be blocked. If the MX receives a disposition of clean or unknown, the file download will be allowed to complete.


The supported file types for inspection are:

  • MS OLE2 (.doc, .xls, .ppt)

  • MS Cabinet (Microsoft compression type)

  • MS EXE

  • ELF (Linux executable)

  • Mach-O/Unibin (OSX executable)

  • Java (class/bytecode, jar, serialization)

  • PDF

  • ZIP (regular and spanned)*

  • EICAR (standardized test file)

  • SWF (shockwave flash 6, 13, and uncompressed)

Cisco Threat Grid

Cisco Threat Grid is a unified threat intelligence and malware analysis platform, which is tightly integrated with Cisco Advanced Malware Protection (AMP) solution. It performs automated static and dynamic analysis, producing human-readable reports with behavioral indicators for each file submitted. Threat Grid’s global scalability drives context-rich information that can be consumed directly or via content rich threat intelligence feeds.


Threat Grid analyzes suspicious files against more than 950 behavioral indicators and a malware knowledge base sourced from around the world to provide industry-leading accuracy and context-rich threat analytics.


Leveraging Threat Grid as a part of a comprehensive network security strategy provides:

  • Deeper insights into what malware is doing or attempting to do, how substantial a threat it poses to your organization and how to defend against it

  • Accurate identification of threats with context-focused security analytics

  • Proactive protection for businesses using threat intelligence from Threat Grid Premium threat feeds

  • Defense against threats originating anywhere using the scale and power of a cloud service that analyzes hundreds of thousands of threats every day

Threat Grid and Meraki MX Integration

The AMP integration with Meraki MX Security Appliance provides Meraki users with the capability to leverage AMP’s File Reputation and File Retrospection services and benefit from the global intelligence held in the AMP Cloud. The AMP Cloud responds to queries from MX devices on files that are downloaded, and returns a file disposition of Clean, Malicious, or Unknown. Malicious files are blocked while Clean and Unknown files are allowed to pass through the MX to the end user. When Threat Grid integration is enabled, the MX will upload qualified, Unknown files to Threat Grid for additional static and dynamic analysis. Once the analysis is completed, a detailed report containing the threat score and behavioral indicators that matched the behaviors observed during analysis will be available in the Meraki Security Center. Depending on the severity of behaviors observed and a threat score, Meraki MX administrator may need to initiate further investigation and response. AMP for Endpoints is a complementary integrated endpoint protection solution which provides robust endpoint level visibility and control capabilities for threats that pass the perimeter defenses.

MX Networking

MX in the Data Center
Datacenter Redundancy (DC-DC Failover)

Deploying one or more MXs to act as VPN concentrators in additional data centers provides greater redundancy for critical network services. In a dual- or multi-datacenter configuration, identical subnets can be advertised from each datacenter with a VPN concentrator mode MX.




In a DC-DC failover design, a spoke site will form VPN tunnels to all VPN hubs that are configured for that site. For subnets that are unique to a particular hub, traffic will be routed directly to that hub so long as tunnels between the spoke and hub are established successfully. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable.




Warm Spare (High Availability) for VPN concentrators

When configured for high availability (HA), one MX serves as the master unit and the other MX operates in a spare capacity. All traffic flows through the master MX, while the spare operates as an added layer of redundancy in the event of failure.


Failover between MXs in an HA configuration leverages VRRP heartbeat packets. These heartbeat packets are sent from the Primary MX to the Secondary MX out the singular uplink in order to indicate that the Primary is online and functioning properly. As long as the Secondary is receiving these heartbeat packets, it functions in the spare state. If the Secondary stops receiving these heartbeat packets, it will assume that the Primary is offline and will transition into the master state. In order to receive these heartbeats, both VPN concentrator MXs should have uplinks on the same subnet within the datacenter.




Meraki Auto VPN technology is a unique solution that allows site-to-site VPN tunnel creation with a single mouse click. When enabled through the dashboard, each participating MX device automatically does the following:

  • Advertises its local subnets that are participating in the VPN.

  • Advertises its WAN IP addresses on Internet 1 and Internet 2 ports.

  • Downloads the global VPN route table from the dashboard (automatically generated by the dashboard, based on each MX's advertised WAN IP/local subnet in the VPN network).

  • Downloads the preshared key for establishing the VPN tunnel and traffic encryption.

The net result is an automatic mesh site-to-site VPN solution that is configured with a single click.


Site-to-site VPN settings are accessible through the Security Appliance > Configure > Site-to-site VPNpage.

There are three options for configuring the MX's role in the Auto VPN topology:

  • Off: The MX will not participate in site-to-site VPN.

  • Hub (Mesh): The MX device will establish VPN tunnels to all remote Meraki VPN peers that are also configured in this mode, as well as any MX appliances in hub-and-spoke mode that have the MX device configured as a hub.

  • Spoke: This MX device (spoke) will establish direct tunnels only to the specified remote MX devices (hubs). Other spokes will be reachable via their respective hubs unless blocked by site-to-site firewall rules.

MX as a VPN Hub

Exit Hubs

This option is only available if the MX is configured as a Hub. This option lets you designate the remote MX device that is to receive all network traffic from the local MX device. This creates a Full Tunnel configuration where all traffic destined for a default route is sent to the specified MX.

In a full tunnel topology, all security and content filtering must be performed on the full tunnel client. The Exit hub will not apply Content Filtering, IPS blocking, or Malware Scanning to traffic coming in over the VPN. However, IDS scanning will be performed for this traffic.

Concentrator Priority

The concentrator priority determines how appliances in Hub (Mesh) mode will reach subnets that are advertised from more than one Meraki VPN peer. Similarly to hub priorities, the uppermost concentrator in the list that is a) advertising the subnet and b) currently reachable via VPN, will be used for such a subnet. It is important to note that concentrator priorities are used only by appliances in Mesh mode. An appliance in Hub-and-Spoke mode will ignore the concentrator priorities and will use its hub priorities instead.

MX as a VPN Spoke


When an appliance is configured as a Spoke, multiple VPN Hubs can be configured for that appliance. In this configuration, the Spoke MX will send all site-to-site traffic to its configured VPN hubs.

Default Route

When configuring Hubs for a Spoke, there is an option to select a hub as being a Default Route. If this option is selected, then that hub will be configured as a default route for the Spoke ( Any traffic that is not sent to a configured VPN peer network, static route or local network will be sent to the default route. Multiple hubs can be selected as default routes. Hubs marked as default routes take priority in descending order (first priority at the top).

Configuring Multiple VPN Hubs

To add additional hubs, click the "Add another hub" button just below the existing hub that is selected. Please note that only appliances in Mesh VPN mode can be hubs, so the number of Mesh VPN appliances in your dashboard organization represents the maximum number of hubs that can be configured for any given appliance.

The order in which hubs are configured on this page is the hub priority. Hub priority is used to determine which hub to use if more than one VPN hub is advertising the same subnet. The uppermost hub that is a) advertising the subnet and b) currently reachable via VPN will be used to reach that subnet.

Hubs can be deleted by clicking on the grey "X" to the right of the relevant hub. The hub priority list can be reordered by clicking and dragging the grey four-point arrow icon to the right of any hub in the list to move that hub up or down.


There are two tunneling modes available for MX appliances configured as a Spoke:

  • Split tunnel (no default route): Send only site-to-site traffic, meaning that if a subnet is at a remote site, the traffic destined for that subnet is sent over the VPN. However, if traffic is destined for a network that is not in the VPN mesh (for example, traffic going to a public web service such as www.google.com), the traffic is not sent over the VPN. Instead this traffic is routed using another available route, most commonly being sent directly to the Internet from the local MX device. Split tunneling allows for the configuration of multiple hubs.

  • Full tunnel (default route): The configured Exit hub(s) advertise a default route over Auto VPN to the spoke MX. Traffic destined for subnets that are not reachable through other routes will be sent over VPN to the Exit hub(s). Exit hubs' default routes will be prioritized in descending order.

NAT Traversal

If the MX appliance is behind a firewall or other NAT device, there are two options for establishing the VPN tunnel:

  • Automatic: In the vast majority of cases, the MX appliance can automatically establish site-to-site VPN connectivity to remote Meraki VPN peers even through a firewall or NAT device using a technique known as "UDP hole punching". This is the recommended (and default) option.

  • Manual Port Forwarding: If the Automatic option does not work, you can use this option. When Manual Port Forwarding is enabled, Meraki VPN peers contact the MX appliance using the specified public IP address and port number. You will need to configure the upstream firewall to forward all incoming traffic on that port to the IP address of the MX appliance.

Make sure the port number you have chosen is not already used by another service.

Local Networks

If you have multiple LAN subnets, you have the option to specify which VLANs and static routes participate in the VPN.


The same subnet can only be advertised from more than one appliance if all appliances advertising that subnet are in Passthrough or VPN Concentrator mode. All subnets advertised from an appliance in NAT mode must be unique within the Auto VPN topology.

Subnets to which the MX device has Static LAN routes can also be advertised over the VPN. If you choose to advertise a statically routed subnet over the VPN, ensure that the gateway device for each subnet is configured to route traffic for remote VPN subnets to the MX device, in order to keep your routing symmetrical.

VPN Subnet Translation

VPN Subnet Translation is not enabled by default, and is generally not recommended unless absolutely needed for a deployment. Deployments with a need for subnet translation can contact Meraki support to enable it.

In large distributed networks, multiple networks may have identical subnet scopes (i.e. overlapping subnets). Site-to-site VPN communication requires each site to have distinct and non-overlapping local subnets. In the event that multiple locations have the same local subnet, enable VPN subnet translation to translate the local subnet to a new subnet with the same number of addresses.


  • Branch 1 local subnet:

  • Branch 2 local subnet: (identical!)

  • Branch 1 translated subnet:

  • Branch 2 translated subnet:

In the example above, even though both networks have identical local subnets, they can communicate over the VPN using their translated VPN subnet. Branch 1 is accessible as and Branch 2 is accessible as over the VPN tunnel.

OSPF Route Advertisement

While the MX Security Appliance does not currently support full OSPF routing, OSPF can be used to advertise remote VPN subnets to a core switch or other routing device, avoiding the need to create static routes to those subnets. OSPF advertisement is only supported in VPN Concentrator mode.

Advertise remote routes: If this is set to Enabled, OSPF will be used to advertise remote VPN subnets as reachable via this concentrator.

Router ID: The OSPF Router ID that this concentrator will use to identify itself to neighbors

Area ID: The OSPF Area ID that this concentrator will use when sending route advertisements.

Cost: The route cost attached to all OSPF routes advertised from this concentrator.

Hello timer: How frequently the concentrator will send OSPF Hello packets. This should be the same across all devices in your OSPF topology.

Dead timer: How long the concentrator will wait to see Hello packets from a particular OSPF neighbor before considering that neighbor inactive

MD5 Authentication: If this is enabled, MD5 hashing will be used to authenticate potential OSPF neighbors. This ensures that no unauthorized devices are injecting OSPF routes into the network.

Authentication Key: The MD5 key number and passphrase. Both of these values must match between any devices that you wish to form an OSPF adjacency.

Non-Meraki VPN Peers

You can create Site-to-site VPN tunnels between the MX appliance and a Non-Meraki VPN endpoint device under the Non-Meraki VPN peers section in Security Appliance > Configure > Site-to-site VPN page. Simply click "Add a peer" and enter the following information:

  • A name for the remote device or VPN tunnel.

  • The public IP address of the remote device.

  • The subnets behind the third-party device that you wish to connect to over the VPN. can also be specified to define a default route to this peer.

  • The IPsec policy to use.

  • The preshared secret key (PSK).

  • Availability settings to determine which appliances in your dashboard organization will connect to the peer.

IPsec Policies

There are three preset IPsec policies available.

  • Default: Uses the Meraki default IPsec settings for connection to a non-Meraki device

  • AWS: Uses default settings for connecting to an Amazon VPC

  • Azure: Uses default settings for connecting to a Microsoft Azure instance

If none of these presets are appropriate, the Custom option allows you to manually configure the IPsec policy parameters. These parameters are divided into Phase 1 and Phase 2.

Phase 1

  • Encryption: Select between AES-128, AES-192, AES-256, DES, and 3DES encryption

  • Authentication: Select MD5 or SHA1 authentication

  • Diffie-Hellman group: Select between Diffie-Hellman (DH) groups 1, 2, and 5

  • Lifetime (seconds): Enter the phase 1 lifetime in seconds

Phase 2

  • Encryption: Select between AES-128, AES-192, AES-256, DES, and 3DES encryption (multiple options can be selected)

  • Authentication: Select between MD5 and SHA1 authentication (both options can be selected)

  • PFS group: Select the Off option to disable Perfect Forward Secrecy (PFS). Select group 1, 2, or 5 to enable PFS using that Diffie Hellman group.

  • Lifetime (seconds): Enter the phase 2 lifetime in seconds


NOTE: IKEv2 is now supported on MX security appliances that are running firmware version 15.12 or higher.  IKEv2 must also be enabled by Cisco Meraki support to function on an MX that will be establishing a tunnel to a peer device using IKEv2.  

Peer Availability

By default, a non-Meraki peer configuration applies to all MX appliances in your dashboard organization. Since is not always desirable for every appliance you control to form tunnels to a particular non-Meraki peer, the Availability column allows you to control which appliances within your organization will connect to each peer. This control is based on network tags, which are labels you can apply to your dashboard networks.

When "All networks" is selected for a peer, all MX appliances in the organization will connect to that peer. When a specific network tag or set of tags is selected, only networks that have one or more of the specified tags will connect to that peer.

More information on network tags can be found in our Organization Overview article..

VPN Firewall Rules

You can add firewall rules to control what traffic is allowed to pass through the VPN tunnel. These rules will apply to inbound and/or outbound VPN traffic from all MX appliances in the organization that participate in site-to-site VPN. To create a firewall rule, click Add a rule in the Site-to-site firewall section on the Security Appliance > Configure > Site-to-site VPN page. These rules are configured in the same manner as the Layer 3 firewall rules described on the Firewall Settings page of this documentation.

Monitoring Site-to-Site VPN

You can monitor the status of the site-to-site VPN tunnels between your Meraki devices by clicking Security Appliance > Monitor > VPN Status. This page provides real-time status for the configured Meraki site-to-site VPN tunnels. It lists the subnet(s) being exported over the VPN, connectivity information between the MX appliance and the Meraki VPN registry, NAT Traversal information, and the encryption type being used for all tunnels. Additionally, the Site connectivity list provides the following information for remote Meraki VPN peers:

  • Name of the remote Meraki VPN peer.

  • Subnets that are being advertised over the VPN by the remote peer device.

  • Status (whether the peer is currently reachable).

  • Round-trip packet latency over the VPN (in milliseconds).

  • Last time a heartbeat packet was sent to determine the status of the VPN tunnel (in seconds).


This page displays limited information for non-Meraki peers.

Supported Addressing Modes

Concentrator Mode

All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, see our MX Addressing and VLANs article.

One-Armed Concentrator

In this mode the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the recommended configuration for MX appliances serving as VPN termination points into the datacenter.

NAT Mode Concentrator  

It is also possible to take advantage of the SD-WAN feature set with an MX configured in NAT mode acting as the VPN termination point in the datacenter.

Last modified



This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7671

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community