Site-to-site VPN Settings

Site-to-site VPN
Meraki AutoVPN 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/Z1 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.

Setting up site-to-site VPN

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

Type
There are three options for configuring the MX/Z1's role in the AutoVPN topology:
Off: The MX/Z1 will not participate in site-to-site VPN.
Hub (Mesh): The MX/Z1 device will establish VPN tunnels to all remote Meraki VPN peers that are also configured
in this mode, as well as any MX/Z1 appliances in hub-and-spoke mode that have the MX/Z1 device configured as a
hub.
Spoke: This MX/Z1 device (spoke) will establish direct tunnels only to the specified remote MX/Z1 devices (hubs).
Other spokes will be reachable via their respective hubs unless blocked by site-to-site firewall rules.

Tunneling
There are two tunneling modes available for MX/Z1 appliances configured as a Spoke:
Split tunnel: 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: The configured Exit hub advertises a default route over AutoVPN to the spoke MX. Traffic destined for
subnets that are not reachable through other routes will be sent over VPN to the Exit hub. Full tunneling requires a
single full tunnel Exit hub be specified.

Hubs
When an appliance is configured as a Spoke and is set to Split tunneling, 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.

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.

Exit Hubs
This option is only available if Full tunneling is configured for a Spoke MX, or 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.

Security features over full-tunnel VPN

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.

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 AutoVPN 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

This feature is not enabled by default, please 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.

Example:
Branch 1 local subnet: 192.168.31.0/24
Branch 2 local subnet: 192.168.31.0/24 (identical!)
Branch 1 translated subnet: 10.0.1.0/24
Branch 2 translated subnet: 10.0.2.0/24
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 10.0.1.0/24 and Branch 2 is accessible as 10.0.2.0/24 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. 0.0.0.0/0 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

Peer availability
By default, a non-Meraki peer configuration applies to all MX or Z1 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 and Z1 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 here.

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
outbound VPN traffic from all MX appliances in the Organization that participate in site-to-site VPN. They will not apply
to inbound traffic or to traffic that is not passing through the VPN. To create a firewall rule, click Add a rule in the Siteto-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-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.