Best Practice Design - MX Security and SD-WAN

Routed (NAT) Mode

Routed mode on a Cisco Meraki WAN appliance is best used when the WAN appliance will be connecting directly to your internet demarcation point. When this is the case, the WAN appliance will have a public IP address that is issued by the internet service provider. The WAN appliance will also be the device handling the routing for clients to the internet, and any other networks configured for the device to communicate to.  This mode is optimal for networking environments that require a WAN appliance with Layer 3 networking capabilities.

Passthrough or VPN Concentrator Mode

Passthrough mode on a Cisco Meraki WAN appliance configures the appliance as a Layer 2 bridge for the network.  The WAN appliance in this mode will not perform any routing or any network translations for clients on the network.  Passthrough or VPN Concentrator Mode is best used when there is an existing Layer 3 device upstream handling network routing functions.  The WAN appliance in this instance would still act as a WAN appliance, but with less functionality for Layer 3 networking.

The recommended use case for the WAN appliance in passthrough mode is when it is acting as a VPN Concentrator for the Cisco Meraki Auto VPN feature.  Passthrough or VPN Concentrator mode ensures easy integration into an existing network that may already have layer 3 functionality and edge security in place.  With this mode, a Cisco Meraki WAN appliance can be integrated into the existing topology and allow for seamless site to site communication with minimal configuration needed.

High Availability and Redundant WAN Connections

The recommended deployment to ensure the most possible uptime is an environment that combines two high availability paired WAN Appliances with multiple Internet Service Provider connections. In this architecture, there is full redundancy to minimize the possible downtime in the event of a failure in either an appliance or a service provider. 

 

High Availability (HA) Pair

When deploying two WAN appliances in high availability (HA), it is recommended to have the management traffic for HA traverse via a downstream connection to a layer 2 switch, and to not have a dedicated HA cable connected between the two appliances. The reason for this is because there is an increased potential for a spanning-tree loop if the WAN appliances are also connected to the same layer 2 switch. The best topology is to have the WAN appliances connected to the same downstream Layer 2 switch.

 

 

Addressing and VLANs

The best practice for planning and configuring a network is to have multiple VLANs for different traffic uses cases. This is especially recommended for separation of networks that will be hosting employee data and networks providing guest access. This is a critical consideration to ensure the maximum possible security for your networking environment. Using multiple VLANs for different use cases will also decrease the amount of broadcast traffic within the same subnet. When designing and configuring multiple VLANs, it is generally recommended to create the subnet to be sized for the necessary amount of devices intended to be in that particular network. Generally, networks with /24 subnet masks are large enough for common deployments, while also providing room for expansion and simple subnetting scalability if more VLANs are to be added. However, it is always best to consider the needs of your deployment when planning your subnets, as some deployments may require larger addressing spaces.

Routing and Layer 3 Connectivity

In certain deployments, the Meraki WAN appliance may not be the only device performing layer 3 functions for the entirety of the data network. Examples of this can be a deployment where the WAN appliance acts as the internet edge gateway while layer 3 routing is performed on downstream devices, or where another layer 3 capable device is added into the existing routing topology. If this is the case, then the WAN appliance must have static routes configured to allow for effective communication to the other layer 3 destinations in the network. The other layer 3 devices must also have static routes in place to the WAN appliance. 

In the example below, an WAN appliance is set up as an Internet edge firewall, with the rest of the layer 3 routing taking place on a downstream switch stack. With this configuration, it is best to have a single subnet configured between the WAN appliance and the other layer 3 device, to minimize the amount of traffic and routing that will be taking place as well as to keep routing consistency. This single subnet will act as a transit VLAN for all routing that is to take place between the two layer 3 endpoints in the topology. 

 

Layer 3 Firewall Rules

The Meraki WAN appliance allows for custom outbound firewall rules to be configured to ensure precise and granular control over which networks are able to communicate with one another.  The WAN appliance is a stateful firewall, meaning that all inbound connections are blocked unless they have either originated from within the WAN Appliance or a forwarding rule is configured.  

By default, all VLANs configured on the WAN appliance will be able to communicate with one another.  If there are VLANs you wish to not be able to pass traffic between, firewall rules will need to be configured.  It is best practice to restrict the amount of traffic that can travel between subnets that are not closely related.  For example, it is recommended to create firewall rules to block all traffic from a VLAN that may be used for guest access from being able to contact other VLANs used for business operations.  

 

 

Additionally, if there are internal users that need internet access, but should be blocked from accessing a certain site or IP address, the firewall rules can be configured with IPs or URLs as the destinations. The use case for this is if you know of a website the users in that VLAN should not access.

 

Layer 7 Firewall Rules

Best practice design for Layer 7 rules is to ensure that the category you have selected to block does not fall under the traffic flow for applications you may use.  For example, if you choose to block the category for "File Sharing," and you block all options, you may cause a disruption in service for an application such as Microsoft OneDrive.  It is best to try and configure Layer 7 rules as granular as possible, to avoid such scenarios.

Using Layer 7 firewall rules for blocking traffic based on countries also has its caveats as well.  While it may seem more secure to block all countries other than the one the WAN appliance is located in, this can cause issues with traffic flows to certain resources that may actually be necessary for daily operations.  Certain webpages and web applications can be hosted in a country not being blocked, but they may pull supplementary data or resources from a server located in a country that is being blocked by the WAN appliance.  As a result, certain aspects may not function as intended or may fail to function altogether.  It is essential to only block countries with a Layer 7 rule if you know traffic from this country is malicious in nature.  

Port Forwarding and NAT Rules

Due to the nature of the Cisco Meraki WAN appliance, all inbound traffic that did not originate from within the networks configured on the appliance will be dropped by default. This is because the Meraki WAN appliance is a stateful firewall, so the WAN appliance must be aware of or expecting incoming traffic.  For connections that originate from outside of the WAN appliance and need to be allowed in, either a port forwarding rule or a NAT rule can be configured to permit this traffic.  

Advanced Malware Protection (AMP)

Advanced Malware Protection (AMP) is an adaptive and powerful tool that is incorporated on the Cisco Meraki WAN appliance with the Advanced Security license.  AMP scans and inspects HTTP downloads that are moving through the WAN appliance.  The WAN appliance then takes action based on the threat intelligence it receives from the AMP cloud.  If a download matches a known signature from the AMP cloud, then the WAN appliance will block the download.  With a WAN appliance, it is highly recommended to have AMP enabled and functioning so your networking environment is secure and safe from attacks. 

Intrusion Detection and Prevention (IDS/IPS)

With the Advanced Security license, Intrusion Detection and Prevention (IDS/IPS) enables the Meraki WAN appliance to inspect all incoming and outgoing traffic that is being routed internally and externally in the networking environment. IDS/IPS searches for various signature-based attacks as traffic flows through the WAN appliance. This is achieved with the various rules and signatures that are in the SNORT® intrusion detection engine. This enables the WAN appliance to detect malicious traffic and not only provides alerts that a known signature was detected, but also take action against that threat and prevent it from doing harm on the network. To ensure a secure and stable networking environment, it is recommended to have Intrusion Detection and Prevention services enabled and operating on the WAN appliance.  

IP Source Address Spoofing Protection

IP Source Address Spoofing Protection is a security mechanism on the Cisco Meraki WAN appliance that enables protection from malicious users on the network from impersonating other hosts and attempting to bypass security restrictions.  The WAN appliance uses several methods of traffic verification to ensure client data is authentic and not spoofed by a malicious attacker.  It is recommended to have this feature set to the mode "Block" so malicious IP spoofing events are mitigated on the network by the WAN appliance as soon as they are identified. There is the option to have the mode set to "Log" but this will not provide protection against these types of attacks, but rather just alert that malicious traffic of this nature has been detected. 

 

 

Meraki Auto VPN

The Meraki WAN appliance allows for simple and seamless integration and configuration of VPN tunnels among sites.  This is achieved with Meraki's proprietary Auto VPN functionality that allows for simple and fast configuration of site to site VPN tunnels.  Additionally, Auto VPN enables maximum uptime of the site-to-site tunnels with congruent VPN tunnels on all available WAN interfaces. VPN tunnels are built actively on all WAN interfaces on the WAN appliance that can reach the Meraki cloud.  This allows for dynamic failover and built-in redundancy with no extra configuration needed.  It is recommended to use Meraki Auto VPN between WAN appliances for essential inter-site communication. Note that Auto VPN can only be used for Meraki to Meraki communications, for Meraki devices in the same Meraki dashboard organization. Separate Meraki dashboard organizations generally represent separate SD-WAN environments.

Uplink Configuration

Under the SD-WAN settings, the uplink connections for the WAN appliance can be configured to best fit the needs of your networking environment.  The uplink bandwidth limit can be configured and changed to best fit the requirements of the connection with your internet service provider.  It is best practice to set the throughput bandwidth to the highest possible amount based on your bandwidth set by your provider as to avoid potentially saturating the connection.  

For uplink monitoring, it is recommended to configure multiple uplink statistic test IPs on the Meraki dashboard.  This is exceptionally useful for troubleshooting purposes, as it allows the dashboard to collect and monitor data on certain connections specified.  A few examples of connections to monitor would be a general connection to the internet (Google's 8.8.8.8 is configured by default), the connection to your service provider gateway, and the connection to any remote sites that may be participating in site to site VPN tunneling. 

Another feature of the functionality that the WAN appliance includes is automatic security list updates for features such as AMP, IDS/IPS, and content URL filtering.  These lists can be configured to check for changes in security rules on an hourly, daily, or weekly basis.  The best practice to ensure your environment stays secure is to have this interval set to check the security lists hourly.  The frequency of updates can be changed per each WAN uplink, including the cellular uplink as well.  

 

 

Uplink Selection

Included with the SD-WAN options is the ability to have the WAN appliance route traffic to different uplinks depending on certain scenarios. Uplink selection enables the ability of policy-based routing on the WAN appliance, which uses flow preferences for specific traffic as it heads out the WAN connection. With this tool, it is recommended to have the uplink connections be set to load balance the traffic if applicable. This is best used if there are redundant internet connections that have similar bandwidth capabilities.  

With flow preferences based on the source traffic, it is easy to shape traffic to best fit the nature of the network traffic as it transverses to the WAN connection. An example of what a flow preference may be used for is guest traffic.  To allow for a consistent and stable connection the more cost-effective secondary WAN connection can be configured to handle guest related traffic. 

SD-WAN Policies

SD-WAN policies can be configured to control and modify the flows for specific VPN traffic. With multiple WAN uplinks, the WAN appliance will proactively build multiple tunnels with each available WAN interface.  In the case where there are redundant WAN connections on the WAN appliance, traffic flows based on the type of traffic traversing the VPN connections can also be configured to allow for best performance. Custom policies set to desired preferences can be set to ensure traffic flows take the appropriate path based on your environment.  If a WAN connection that normally handles traffic such as file transfers begins to have performance issues, the Cisco Meraki WAN appliance can dynamically change the VPN connection to an alternative WAN uplink. This is done with custom policies or predetermined policies on the dashboard. It is encouraged to configure said policies in your deployment to best fit the needs based on the nature of the traffic and the capabilities of the WAN connections available on the WAN appliance. 

 

Global Bandwidth Limits

In larger deployments, bandwidth limits for end-user devices can to be put in place to ensure the uplinks do not become saturated. This largely depends on the type of traffic that is seen from users, how many users are on the network, as well as the throughput capabilities of the WAN appliance and the uplinks. With more substantial deployments where there are a large number of clients, it is recommended to set a bandwidth limit on all traffic. The amount of bandwidth required per client can vary depending on the type of traffic seen in the networking environment.  

Speedburst is an option to allow clients a short window of time to exceed the bandwidth limit configured to allow, for example, a large file to transfer faster. This is a useful feature if there are users that will be handling and uploading large files frequently on the network. Speedburst is a recommended feature to enable, with the caveat that it should only be used if there are not a large number of clients that will need high amounts of bandwidth at the same time. If there are a select few users or devices that require moments of higher bandwidth then Speedburst is recommended.

  

Traffic Shaping Rules

Different types of traffic require different priorities on the network.  The WAN appliance is able to prioritize and shape traffic on the local network based on the traffic type.  The Meraki dashboard offers default traffic shaping rules that best fit the needs for most deployments.  These default rules ensure best performance for local voice traffic, software updates for end client devices, and collaboration applications.  It is recommended to enable these default traffic shaping rules on the WAN appliance as it allows for simple and fast configuration for the best performance of network traffic.

Auto VPN at the Branch

Before configuring and building Auto VPN tunnels, there are several configuration steps that should be reviewed.

WAN Interface Configuration

While automatic uplink configuration via DHCP is sufficient in many cases, some deployments may require manual uplink configuration of the WAN appliance at the branch. The procedure for assigning static IP addresses to WAN interfaces can be found in our MX IP assignment documentation.

Some WAN Appliance models have only one dedicated Internet port and require a LAN port be configured to act as a secondary Internet port via the device local status page if two uplink connections are required. WAN Appliance models that require reconfiguring a LAN port as a secondary Internet port currently include the MX64 line, MX67 line, and MX100 devices. This can also be verified per-model in our installation guides online. This configuration change can be performed on the device local status page on the Configure tab.

Subnet Configuration

Auto VPN allows for the addition and removal of subnets from the Auto VPN topology with a few clicks. The appropriate subnets should be configured before proceeding with the site-to-site VPN configuration.

Hub Priorities

Hub priority is based on the position of individual hubs in the list from top to bottom. The first hub has the highest priority, the second hub the second highest priority, and so on. Traffic destined for subnets advertised from multiple hubs will be sent to the highest priority hub that a) is advertising the subnet and b) currently has a working VPN connection with the spoke. Traffic to subnets advertised by only one hub is sent directly to that hub.

Configuring Allowed Networks

To allow a particular subnet to communicate across the VPN, locate the local networks section in the Site-to-site VPN page. The list of subnets is populated from the configured local subnets and static routes in the Addressing & VLANs page, as well as the Client VPN subnet if one is configured.

To allow a subnet to use the VPN, set the Use VPN drop-down to yes for that subnet.

Auto VPN at the Data Center

Deploying a One-Armed Concentrator

A one-armed concentrator is the recommended datacenter design choice for an SD-WAN deployment. The following diagram shows an example of a datacenter topology with a one-armed concentrator:

NAT Traversal

Whether to use Manual or Automatic NAT traversal is an important consideration for the VPN concentrator.

Use manual NAT traversal when:

• There is an unfriendly NAT upstream.

• Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter.

• It is important to know which port remote sites will use to communicate with the VPN concentrator.

If manual NAT traversal is selected, it is highly recommended that the VPN concentrator be assigned a static IP address. Manual NAT traversal is intended for configurations when all traffic for a specified port can be forward to the VPN concentrator.

Use automatic NAT traversal when:

• None of the conditions listed above that would require manual NAT traversal exist.

If automatic NAT traversal is selected, the WAN Appliance will automatically select a high numbered UDP port to source Auto VPN traffic from. The VPN concentrator will reach out to the remote sites using this port, creating a stateful flow mapping in the upstream firewall that will also allow traffic initiated from the remote side through to the VPN concentrator without the need for a separate inbound firewall rule.

Topology

The following is an example of a topology that leverages an HA configuration for VPN concentrators:

 

Behavior

When configured for high availability (HA), one WAN Appliance is active, serving as the primary, and the other WAN Appliance operates in a passive, standby capacity. The VRRP protocol is leveraged to achieve failover. Check out our MX Warm Spare documentation for more information.

WAN Appliance IP Assignment

In the datacenter, a WAN Appliance can operate using a static IP address or an address from DHCP. WAN appliances will attempt to pull DHCP addresses by default. It is highly recommended to assign static IP addresses to VPN concentrators.

Uplink IPs

Use Uplink IPs is selected by default for new network setups. In order to properly communicate in HA, VPN concentrator WAN Appliances must be set to use the virtual IP (VIP).

Virtual IP (VIP)

Virtual IP is an addressing option that uses an additional (third) IP address that is shared by the HA WAN Appliances. In this configuration, the WAN Appliances will send their cloud controller communications via their uplink IPs, but other traffic will be sent and received by the shared virtual IP address.

Failover Times

There are several important failover timeframes to be aware of:

Service	Failover Time	Failback Time
Auto VPN Tunnels	30-40 seconds	30-40 seconds
DC-DC Failover	20-30 seconds	20-30 seconds
Dynamic Path Selection	Up to 30 seconds	Up to 30 seconds
Warm Spare	30 seconds or less	30 seconds or less
WAN connectivity	300 seconds or less	15-30 seconds

Configuring OSPF Route Advertisement

Meraki WAN Appliances support advertising routes to connected VPN subnets via OSPF.

A WAN Appliance with OSPF route advertisement enabled will only advertise routes via OSPF; it will not learn OSPF routes.

When spoke sites are connected to a hub WAN Appliance, the routes to spoke sites are advertised using an LS Update message. These routes are advertised as type 2 external routes.

BGP and Auto VPN

BGP VPNs are utilized for Data Center Failover and load sharing. This is accomplished by placing VPN Concentrators at each Data Center. Each VPN Concentrator will utilize BGP with DC edge devices. BGP is utilized for its scalability and tuning capabilities.

More information about implementing BGP and its use cases can be found in our BGP documentation.

Dashboard & Cloud

The Meraki WAN Appliance is a cloud managed networking device. As such, it is important to ensure that the necessary firewall policies are in place to allow for monitoring and configuration via the Meraki dashboard. The relevant destination ports and IP addresses can be found under the Help > Firewall Info page in the dashboard.

VPN Registry

Meraki's Auto VPN technology leverages a cloud-based registry service to orchestrate VPN connectivity. In order for successful Auto VPN connections to establish, the upstream firewall must allow the VPN concentrator to communicate with the VPN registry service. The relevant destination ports and IP addresses may vary by region, and can be found under the Help > Firewall Info page in the dashboard.

Uplink Health Monitoring

The WAN Appliance also performs periodic uplink health checks by reaching out to well-known Internet destinations using common protocols. The full behavior is outlined here. In order to allow for proper uplink monitoring, the following communications must also be allowed:

• DNS test to canireachthe.net

• Internet test to icmp.canireachthe.net

Hardware Redundancy in VPN Concentrator Mode

WAN Appliance VPN Concentrator warm spare is used to provide high availability for a Meraki Auto VPN head-end appliance. Each concentrator has its own IP address to exchange management traffic with the Meraki Cloud. However, the concentrators also share a virtual IP address that is used for non-management communication.

WAN Appliance VPN Concentrator - Warm Spare Setup

Before deploying WAN Appliances as one-arm VPN concentrators, place them into Passthrough or VPN Concentrator mode on the Addressing and VLANs page. In one-armed VPN concentrator mode, the units in the pair are connected to the network "only" via their respective ‘Internet’ ports. Make sure they are NOT connected directly via their LAN ports. Each WAN Appliance must be within the same IP subnet and able to communicate with each other, as well as with the Meraki dashboard. Only VPN traffic is routed to the WAN Appliance, and both ingress and egress packets are sent through the same interface.

WAN Appliance VPN Concentrator - Virtual IP Assignment

The virtual IP address (VIP) is shared by both the primary and warm spare VPN concentrator. VPN traffic is sent to the VIP rather than the physical IP addresses of the individual concentrators. The virtual IP is configured by navigating to Security & SD-WAN > Monitor >Appliance status when a warm spare is configured. It must be in the same subnet as the IP addresses of both appliances, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

The two concentrators share health information over the network via the VRRP protocol. Failure detection does not depend on connectivity to the Internet/Meraki dashboard.

WAN Appliance VPN Concentrator - Failure Detection

In the event that the primary unit fails, the warm spare will assume the primary role until the original primary is back online. When the primary VPN concentrator is back online and the spare begins receiving VRRP heartbeats again, the warm spare concentrator will relinquish the active role back to the primary concentrator. The total time for failure detection, failover to the warm spare concentrator, and ability to start processing VPN packets is typically less than 30 seconds.

WAN Appliance Warm Spare Alerting

There are a number of options available in the Meraki dashboard for email alerts to be sent when certain network or device events occur, such as when a warm spare transition occurs. This is a recommended configuration option and allows a network administrator to be informed in the event of a failover.

The event, “A warm spare failover occurs,” sends an email if the primary WAN Appliance of a High Availability pair fails over to the spare, or vice-versa.

This alert and others, can be referenced in our article on Configuring Network Alerts in Dashboard.

If you are having difficulties getting warm spare to function as expected, please refer to our MX Warm Spare - High Availability Pair document.

HW Redundancy in NAT mode

WAN Appliance NAT Mode – Warm Spare

WAN Appliance NAT Mode Warm Spare is used to provide redundancy for internet connectivity and appliance services when a WAN Appliance is being used as a NAT gateway.

WAN Appliance NAT Mode - Warm Spare Setup

In NAT mode, the units in the HA pair are connected to the ISP or ISPs via their respective Internet ports, and the internal networks are connected via the LAN ports.

WAN configuration: Each appliance must have its own IP address to exchange management traffic with the Meraki cloud. If the primary appliance is using a secondary uplink, the secondary uplink should also be in place on the warm spare. A shared virtual IP, while not required, will significantly reduce the impact of a failover on clients whose traffic is passing through the appliance. Virtual IPs can be configured for both uplinks.

LAN configuration: LAN IP addresses are configured based on the Appliance IPs in any configured VLANs. No virtual IPs are required on the LAN.

Additional warm spare configuration details can be found in our article, MX Warm Spare - High Availability Pair.

WAN Appliance NAT Mode - Virtual IP Assignment

Virtual IP addresses (vPs) are shared by both the primary and warm spare appliance. Inbound and outbound traffic uses this address to maintain the same IP address during a failover to reduce disruption. The virtual IPs are configured on the Security & SD-WAN > Monitor > Appliance status page. If two uplinks are configured, a vIP can be configured for each uplink. Each vIP must be in the same subnet as the IP addresses of the appliance uplink it is configured for, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

WAN Appliance NAT Mode - Failure Detection

There are two failure detection methods for NAT mode warm spare. Failure detection does not depend on connectivity to the Internet / Meraki dashboard.

WAN Failover: WAN monitoring is performed using the same internet connectivity tests that are used for uplink failover. If the primary appliance does not have a valid Internet connection based on these tests, it will stop sending VRRP heartbeats which will result in a failover. When uplink connectivity on the original primary appliance is restored and the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

LAN Failover: The two appliances share health information over the network via the VRRP protocol. These VRRP heartbeats occur at layer 2 and are performed on all configured VLANs. If no advertisements reach the spare on any VLAN, it will trigger a failover. When the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

WAN Appliance NAT Mode – DHCP Synchronisation

The WAN Appliances in a NAT mode high availability pair exchange DHCP state information over the LAN. This prevents a DHCP IP address from being handed out to a client after a failover if it has already been assigned to another client prior to the failover.

DC-DC Failover - Hub/Data Center Redundancy (Disaster Recovery)

Meraki's WAN Appliance Datacenter Redundancy (DC-DC Failover) allows for network traffic sent across Auto VPN to failover between multiple geographically distributed datacenters.

DC Failover Architecture

A DC-DC failover architecture is as follows:

• One-armed VPN concentrators or NAT mode concentrators in each DC

• A subnet(s) or static route(s) advertised by two or more concentrators

• Hub & Spoke or VPN Mesh topology

• Split or full tunnel configuration

Operation and Failover

Deploying one or more WAN Appliances 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 are advertised from each datacenter with a VPN concentrator mode WAN Appliance.

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

When a WAN Appliance is configured to connect to multiple VPN concentrators advertising the same subnets, the routes to those subnets become tracked. Hello messages are periodically sent across the tunnels from the remote site to the VPN hubs to monitor connectivity. If the tunnel to the highest priority hub goes down, the route is removed from the route table and traffic is routed to the next highest priority hub that is reachable. This route failover operation only applies when identical routes are advertised from multiple Auto VPN hubs.

Concentrator Priority

When multiple VPN hubs are configured for an organization, the concentrator priority can be configured for the organization. This concentrator priority setting determines the order in which VPN mesh peers will prefer to connect to subnets advertised by multiple VPN concentrators.

This setting does not apply to remote sites configured as VPN spokes.

Other Datacenter Considerations

When implementing an DC-DC architecture, a warm spare concentrator configuration (see warm spare section above) and OSPF route advertisement should always be taken into consideration for WAN Appliances acting as VPN concentrators in a datacenter. Additionally, route flow logic should be considered for all applications in the deployment environment to ensure availability requirements are met. To assist with better understanding DC-initiated flows, please refer below.

VPN Topologies

There are several options available for the structure of the VPN deployment.

Standard Hub & Spoke

 

How it works:

Utilizing the standard Meraki Auto VPN registry to ascertain how the VPN tunnels configured need to form (i.e. via public address space or via private interface address space) as described in Configuring Site-to-site VPN over MPLS.

When should it be used?

Whenever possible. It is strongly recommended that this model is the 1st, 2nd and 3rd option when designing a network. Only if the deployment has an exceptionally strong requirement should one of the following hub and spoke derivatives be considered.

VPN Mesh

It is also possible to use a VPN mesh configuration in an SD-WAN deployment.

In a mesh configuration, a WAN Appliance at the branch or remote office is configured to connect directly to any other WAN Appliances in the organization that are also in mesh mode, as well as any spoke WAN Appliances that are configured to use it as a hub.

• Full Mesh - Total Tunnel Count
  
  Where H is the number of WAN Appliances and L is the number of uplinks each WAN Appliance has.

For example, if all WAN Appliances have 2 uplinks and there are 50 WAN Appliances, then the total number of VPN tunnels would be 4900 and every WAN Appliance would have to be able to support 196 tunnels from the number of VPN peers for a single WAN Appliance (49) multiplied by the number of VPN tunnels between each peer (4), in this case, we would need 50 MX100s as a minimum.

China Auto VPN Architecture

 

In the above diagram, we are utilizing Meraki Auto VPN to connect the enterprise sites inside China. The above diagram also demonstrates the Chinese government-approved dedicated circuits connecting the Chinese parts of the enterprise to the rest of the global enterprise. Dynamic routing such as BGP or OSPF can be utilized to exchange routing information between the domains.

Creating a Template Network

As outlined above, a template network should be created for each type of site to be deployed.

To create a template network:

1. In the dashboard, navigate to Organization > Monitor > Configuration templates

2. Choose Create a new template

3. Select a descriptive name for your template. If this is a completely new template, select Create new

   • If this template should be based on an existing network, select Copy settings from and select an existing Security appliance network from the drop-down menu.

4. Choose Add:

 

 

5. If you would like to bind existing networks to this new template, select those networks as Target networks and choose Bind. Otherwise, choose Close.

Template VLAN Configuration

1. In the dashboard, navigate to Security & SD-WAN > Configure > Addressing & VLANs

2. Under Routing section, LAN setting sub-section click VLANs 

3.  Choose Add VLAN under Subnets sub-section

4. Select a descriptive name for your VLAN

5. Choose whether the subnetting should be Same or Unique for every network bound to this template.

   • If Same is chosen, all the networks bound to the template will share the exact same subnet. This is not eligible for site-to-site VPNs.

   • If Unique is chosen, each network bound to the template will get a unique subnet based on the configured options. The MX does allow local VLAN overrides on templates, however, the chosen subnet needs to be from the same subnet pool assigned to the VLAN on the template and you can't override the VLAN ID. 

     • Subnets are assigned randomly to each network bound to the template.

 

           

 

For more information about template IP range VLAN allocation, reference our article on Managing Networks with Configuration Templates.

Template Static Routes

 

In template-based WAN Appliance deployments, static routes can be configured on the parent template and passed to child networks like other configuration parameters.  The procedure for configuring a template-based static route is almost identical to the procedure for a regular network, with the exception of how next-hop IP addresses are defined as the next-hop value may be network specific.

1. In the dashboard, navigate to Security & SD-WAN > Configure > Addressing & VLANs > Routing > Static Routes

2. Choose Add Static Route

• Name  

  • Text description for the static route(not parsed)

    • Ex: prodWirelessNet

• Subnet 

  • Subnet reachable via static route specified in CIDR notation

    • Ex: 10.0.10.0/24  

• Next Hop IP

  • Next-hop IP is the IP address of the device that connects the WAN Appliance to this route.  There are two methods for specifying next-hop values on template-based networks. 

    • Option A: IP Assignment

      • Manually define next-hop value

      • Required Info: 

        • Next-hop IP address

    • Option B: IP offset

      • Calculate next-hop IP based on network address for specified VLAN 

        • NOTE: Next Hop IP will be calculated as Network Address + Offset and not VLAN Interface IP + Offset

      • IP offset parameters: 

        • Select the desired VLAN from the dropdown

        • Offset value (a positive integer) 

      • Example:

        • VLAN configured: 10.0.254.0/30

        • VLAN Interface IP: 10.0.254.1

        • Offset: 2 

        • Calculated route next-hop IP: 10.0.254.2

• Active 

  • The active modifier controls conditions that must be met for the WAN Appliance to deem the route usable and add the route to the local routing table. 

    • Always: 

      • The route will always be active in WAN Appliance's routing table 

    • While next-hop responds to ping: 

      • The route is available as long as the configured next hop is responding to pings

    • While host responds to ping:

      • The route is available as long as the configured host is responding to pings

 

Template Firewall Rules

When configuring layer 3 firewall rules, CIDR notation, as well as the VLAN name, can be used. The VLAN name is used when the entire subnet needs to be specified whereas CIDR notation is used when more flexibility is needed to specify the subnets.

 

1. Go to Security & SD-WAN > Configure > Firewall > Layer 3, click Add a rule

2. Choose the policy, specify if the rule matched should be allowed or denied

3. Select the protocol to match in outbound traffic

4. Specify the IP address or range using CIDR notation to match the outbound traffic. Note that also the name of the VLAN can be chosen as well

5. Choose the Src/dst port to match in outbound traffic

 

Template SD-WAN Policies

1. SD-WAN policies can be configured to control and modify the flows for specific VPN traffic. You can have a specific type of traffic go over one Uplink over the other. 
    

2. Go to Security & SD-WAN > Configure > SD-WAN & traffic shaping > SD-WAN policies > VPN traffic, and choose Add a preference

3. You'll be prompted with the Uplink selection policy dialog box. From this box, you can define the type of traffic that should adhere to the policy on the Traffic filters section. You can either add Custom expressions to select traffic based on Protocol/Source/Destination criteria, or you can select traffic based on pre-defined applications. 

   • To add a custom expression to select traffic. 

     • Choose Add +

     • The Custom expressions option should already be selected.

     • Choose the Protocol. You can choose either TCP, UDP, ICMP or Any

     • Choose Source to define the source address criteria. You can select one of the following: 

       • You can choose Any

       • You can type in the source in CIDR format( eg: 10.0.0.0/8), and then choose Add

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Add VLAN

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then click Host, type in the last octet of the host address, then choose on Add host

     • Choose the Src port. The Source port could be 'Any', a port number (eg: 2000), or a port range (eg: 2000-3000) within 1-65535.

     • Click Destination to define the source address criteria. You can select one of the following: 

       • You can choose Any

       • You can type in the source in CIDR format( eg: 10.0.0.0/8), and then choose Add

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Add VLAN

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Host, type in the last octet of the host address, then choose Add host

     • Choose the Dst port. The Destination port could be 'Any', a port number (eg: 2000), or a port range (eg: 2000-3000) within 1-65535.

   •  To add a pre-defined application to select traffic.

     • Select the application type from the menu and then the interesting application in question from the sub-menu (e.g., VoIP & video conferencing > Webex)

     • Add all the applications which you want them to adhere to the policy and then choose Add+ to exit the applications menu

4. Under the Policy section, you can select one of the following as the Preferred uplink

   • WAN1 or WAN2. If you choose WAN1 or WAN2, you'll have the opportunity to configure failover criteria under Fail over if drop-down menu. You can select either Poor performance and then choose one of the performance classes from the Performance class drop-down menu or you can choose Uplink down.  By default, VoIP is the only pre-defined performance class. Any additional performance classes have to be defined under Security & SD-WAN > Configure > SD-WAN & traffic shaping > SD-WAN policies > Custom performance classes.

   • Best for VoIP. The uplink that is best for VoIP traffic will be chosen.

   • Load balance. The WAN Appliance will balance traffic across the uplinks that meet the performance class selected from On uplinks that meet performance class drop-down menu.

   • Global preference. The uplink will be chosen based on the configuration under Security & SD-WAN > Configure > SD-WAN & traffic shaping > Uplink selection > Global preferences. 

5. Once you are done with configuring the criteria to apply the policy and the policy, choose Save

 

Local Overrides

Once a WAN Appliance network has been bound to a template, some options can still be configured normally through the dashboard. Any local configuration changes made directly on the WAN Appliance network will override the template configuration.

In the example below, the bound WAN Appliance was directly configured to have a custom Default VLAN. This change can be made in the template network, under Security & SD-WAN > Configure > Addressing & VLANs:

 

 

If a network is removed from a template, local overrides will automatically be lost as well as any template related configuration. The WAN Appliance will automatically get the configuration from the network it is on.

 

 

DHCP Exceptions

The Meraki WAN Appliance provides a fully-featured DHCP service that can be enabled and configured on each VLAN individually. When bound to a template, local overrides can be made to the DHCP configurations under Security & SD-WAN > Configure > DHCP.

 

 

Forwarding Rules Overrides

To override forwarding rules, navigate under Security & SD-WAN > Configure > Firewall > Forwarding rules overrides.

 

Active-Active AutoVPN

To override the uplink selection rules for Active-Active AutoVPN, navigate to Security & SD-WAN > Configure > SD-WAN & traffic shaping  > Active-Active AutoVPN.

 

Templates with MXs of Different Port Counts

You can toggle the LAN2 port between LAN and Internet, through Uplink configuration under the Local status tab on the Local Status Page.

Client VPN

To manage client VPN users, navigate under Network-wide > Configure > Users

 

For more detailed guidance on the above Client VPN setup, please refer to the Client VPN Overview document.