- Last updated
- Save as PDF
Site-to-site VPN
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-Z 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 & SD-WAN> Configure > Site-to-site VPN page.
Type
There are three options for configuring the MX-Z's role in the Auto VPN topology:
- Off: The MX-Z device will not participate in site-to-site VPN.
- Hub (Mesh): The MX-Z device will establish VPN tunnels to all remote Meraki VPN peers that are also configured in this mode, as well as any MX-Z appliancesin hub-and-spoke mode that have the MX-Z device configured as a hub.
- Spoke: This MX-Z device (spoke) will establish direct tunnels only to the specified remote MX-Z devices (hubs). Other spokes will be reachable via their respective hubs unless blocked by site-to-site firewall rules.
Hub Type
Exit Hubs
This option is only availableif the MX-Z deviceis configured as aHub.This option lets you designate the remote MX-Z device that is to receive all network traffic from the local MX-Z device. This creates a Full Tunnel configuration where all traffic destined for a default route is sent to the specified MX.
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 hubwill 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.
Spoke Type
Hubs
When an appliance is configured as aSpoke, multiple VPN Hubs can be configured for that appliance. In this configuration, theSpokeMX-Z device 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 (0.0.0.0/0). 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 routestake priority in descending order (first priority at the top).
Configuring multiple VPN hubs
To add additional hubs, click the "Add a 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 meets the following criteria will be used to reach that subnet.
A) Advertisesthe subnet
B) Currently reachable via VPN
Hubs can be deleted by clicking on the grey "X" to the right of the relevant hub under the Actionscolumn. 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.
Tunneling
There are two tunneling modes available for MX-Z devicesconfigured 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 trafficis routed using another available route, most commonly being sent directly to the Internet from the local MX-Z device. Split tunneling allows for the configuration of multiple hubs.
- Full tunnel (default route): The configured Exit hub(s)advertisea default route over Auto VPN to the spoke MX-Z device. Traffic destined for subnetsthat are not reachable through other routes will be sent over VPN to the Exit hub(s). Exit hubs' default routeswill be prioritized in descending order.
Concentrator priority
The concentrator priority determines how appliances in Hub (Mesh)mode will reach subnets that are advertised from more than one MerakiVPN peer. Similarly to hub priorities, the uppermost concentrator in the list that meets the following criteriawill be used for such a subnet.
A)Advertisesthe subnet
B) Currently reachable via VPN
It is important to note that concentrator priorities are used only by appliances in Meshmode. An appliance in Hub-and-Spoke mode will ignore the concentrator priorities and will use its hub priorities instead.
NAT Traversal
If the MX-Z deviceis 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-Z devicecan automatically establish site-to-site VPN connectivity to remote Meraki VPNpeers 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, MerakiVPN peers contact the MX-Z deviceusing the specified public IP address and UDP port number. You will need to configure the upstream firewall to forward all incoming traffic on that UDP port to the IP address of the MX-Z device.
Make sure the port number you have chosen is not already used by another service. For example, do not use port 500 or 4500 as these are used for Client VPN and 3rd party VPN peer communication.
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 Routed mode must be unique within the Auto VPN topology.
Subnets to which the MX-Z 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-Z device, in order to keep your routing symmetrical.
In full tunnelconfigurations when specifying a prefix to be part of a VPN, everything covered by that prefix will be allowed in the VPN. Therefore, subnets that overlap will causetraffic in amore specific subnet to be sent through the VPN, even if it is not configured to be included in the VPN. For example, if 10.0.0.0/16 is configured to be included in the VPN but 10.0.1.0/24 is not, traffic sourced from 10.0.1.50 will still be sent over the VPN.
VPN Subnet Translation
This feature is not enabled by default, please contact Meraki support to enable it.
Moreover, this feature is only supported for Auto VPN and is not intended to work with non-Meraki VPN peers.
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.
Subnet Translation 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 communicateover 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
Note: As part of MX 18.1 firmware updates we are introducing a new “Routing page”, more details found here.
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 supported in VPN Concentrator mode or in Routed mode on MX 13.4+ firmware with VLANs disabled.
Advertise remote routes: If this is set to Enabled, OSPF will be used to advertise remote VPN subnets as reachable via this MX
Router ID: The OSPF Router ID that this MX will use to identify itself to neighbors
Area ID: The OSPF Area ID that this MX will use when sending route advertisements.
Cost: The route cost attached to all OSPF routes advertised from this MX.
Hello timer: How frequently the MXwill send OSPF Hello packets. This should be the same across all devices in your OSPF topology.
Dead timer: How long the MX 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 a Security Appliance or a Teleworker Gatewayand a Non-Meraki VPN endpoint device under the Non-Meraki VPN peers section on theSecurity & SD-WAN > 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.
- What IKE version to use (IKEv1 or IKEv2)*
- The public IP address of the remote device.
- The Remote ID of the remote peer. This is an optional configuration and can be configured to the remote peer’s UserFQDN (e.g. user@domain.com), FQDN (e.g. www.example.com)or IPv4 address as needed.
- Which of these values you use is dependent upon your remote device. Please consult its documentation to learn what values it is capable of specifying as its remote ID, and how to configure them (e.g. crypto isakmp identity for ASA firewalls
- 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.
-
Note that if an MX-Z device is configured with a default route (0.0.0.0/0) to a Non-MerakiVPN peer, traffic will not fail over to the WAN, even if the connection goes down.
-
- 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.
*IKEv2 requires firmware version 15.12 or greater
When configuring NMVPN connections between 2 MXsin different organizations that are running MX15code and above that are not using a UserFQDNand are NATedbehind an upstream device, please ensure that the remote ID field of the NMVPN peer is filled out with the private IP address of the remote NATed MX.
Non-Meraki VPN Peering with FQDN
This feature enables theuse of FQDN instead of an IP address while configuring a Non-Meraki VPN peer. Using IP addresses can be tedious because with a dynamic IP address, a customer has to manually modify the Non-Meraki VPN settings on the Site-to-Site VPN page when there is an IP address change. With FQDN configuration, the hostname of the remote peer would automatically get resolved each time a connection is initiated.
“FQDN” differs from “User FQDN”. The MX resolves the FQDN to an IP address of the remote peer, whereas, “User FQDN” is used in conjunction with the IP address of the remote peer. “FQDN” identifies the remote peer and is configured in the “Public IP/Hostname” field.“User FQDN” identifies the local peer and is configured in the “Local ID” field.
Supported Products:
-
MX running firmware 18.1 or higher
-
RequiresIKEv2
Configuration
The FQDN of the Non-Meraki VPN peer can be configured in the Public IP/Hostname field when IKEv2 is the selected IKE version.
The default behavior of the MX is to set remote_id to FQDN if it is not explicitly added in the dashboard "Non-Meraki VPN peers" settings. Please note, the remote id on one peer needs to match the local id on the other peer for the tunnel to be established.
Ifthe configured FQDN fails to resolve,an event will be reported in Network-wide > Eventlog on Dashboard
NOTEFor IKEv2
Meraki Appliances build IPsec tunnels by sending out a request with a single traffic selector that contains all of the expected local and remote subnets. Certain vendors may not support allowing more than one local and remote selector in a given IPsec tunnel (e.g. ASA 5500-X series firewalls running certain firmware releases); for such cases, please use IKEv1 instead.
An MX-Z devicewill not try to form a VPN tunnel to a non-Meraki peer if it does not have any local networks advertised.
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, and 3DES encryption
- Authentication: Select MD5, SHA1or SHA256* authentication
- Diffie-Hellman group: Select between Diffie-Hellman (DH) groups 1, 2,5 or 14*
- Lifetime (seconds): Enter the phase 1 lifetime in seconds
* These settings requirefirmware version 15.12 or greater
Phase 2
- Encryption: Select between AES-128, AES-192, AES-256, 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
On May 8th 2018, changes were introduced to deprecate DES for encryption. Click here for more information.
NOTE: Please ensure the phase 2 lifetimes are equal on both ends of the tunnel whenever possible. While MX's can sometimes honor a shorter phase 2 lifetime if they're acting in response to build a tunnel, they cannot while serving as the initiator of the tunnel.
Peer availability
By default, a non-Meraki peer configuration applies to all MX-Zappliances in your Dashboard Organization. Since it 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-Z 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 to/from from all MX-Z appliances in the Organization that participate in site-to-site VPN. These rules are configured in the same manner as the Layer 3 firewall rules described on the Firewall Settings page of this documentation. Note that VPN Firewall ruleswill not apply to inbound traffic or to traffic that is not passing through the VPN.
Monitoring site-to-site VPN
You can monitor the status of the site-to-site VPN tunnels between your Meraki devices by clicking Security & SD-WAN > 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-Z 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.
Troubleshooting
Refer to Site-to-site VPN Troubleshootingfor common issues and troubleshooting steps.
FAQs
Site-to-Site VPN Settings? ›
A site-to-site Virtual Private Network (VPN) provides this by creating an encrypted link between VPN gateways located at each of these sites. A site-to-site VPN tunnel encrypts traffic at one end and sends it to the other site over the public Internet where it is decrypted and routed on to its destination.
How to configure site-to-site VPN? ›- Step 1: Create a customer gateway. ...
- Step 2: Create a target gateway. ...
- Step 3: Configure routing. ...
- Step 4: Update your security group. ...
- Step 5: Create a VPN connection. ...
- Step 6: Download the configuration file.
A site-to-site Virtual Private Network (VPN) provides this by creating an encrypted link between VPN gateways located at each of these sites. A site-to-site VPN tunnel encrypts traffic at one end and sends it to the other site over the public Internet where it is decrypted and routed on to its destination.
What is an example of a site-to-site VPN? ›For example, a site-to site VPN would allow a company's headquarters in Chicago to connect to a smaller branch in Long Beach, California. Due to the rise of remote work and eLearning, businesses take advantage of this tech to share information securely.
What is site-to-site VPN vs normal VPN? ›A remote access VPN connects remote users from any location to a corporate network. A site-to-site VPN, meanwhile, connects individual networks to each other.
When should I configure a site-to-site VPN? ›Companies have traditionally used site-to-site VPNs to connect their corporate network and remote branch offices in a hub-and-spoke topology. This approach works when a company has an in-house data center, highly sensitive applications or minimal bandwidth requirements.
How do I test my site-to-site VPN? ›- Use an AMI that responds to ping requests. ...
- Configure any security group or network ACL in your VPC that filters traffic to the instance to allow inbound and outbound ICMP traffic.
Site-to-site VPN disadvantages
A site-to-site VPN does not provide additional security to the networks that it connects; the secure tunnel it establishes just protects data in transit between two or more networks.
VPNs are insecure because they expose entire networks to threats like malware, DDoS attacks, and spoofing attacks. Once an attacker has breached the network through a compromised device, the entire network can be brought down.
What are the limitations of site-to-site VPN? ›Site-to-Site VPN supports a maximum transmission unit (MTU) of 1446 bytes and a corresponding maximum segment size (MSS) of 1406 bytes. However, certain algorithms that use larger TCP headers can effectively reduce that maximum value.
Which are the three modes that a site to site VPN supports? ›
Main Mode - Used when VPN Sites have permanent/Static public IP address. Aggressive Mode - Used when One Site has permanent/static public IP and the other site has a dynamic/temporary public IP address. Hub and Spoke - Setting up VPNs when two or more remote sites (Spokes) want to connect to central site (Hub).
Why use site to site VPN? ›Site-to-site VPN security is the most important benefit, as IPsec protocols will ensure all traffic is encrypted in transit through the VPN tunnel. The site-to-site VPN tunnel only allows traffic from one end to the other, blocking any attempts to intercept the traffic from the outside.
Does site to site VPN require public IP? ›A VPN gateway requires a public IP address for its configuration. A public IP address is used as the external connection point of the VPN.
What ports are required for site to site VPN? ›It might also require UDP port 500 for Internet Key Exchange (IKE) to manage encryption keys, and UDP port 4500 for IPSec NAT-Traversal (NAT-T). Sometimes, if the UDP ports are blocked, VPN devices try to use TCP port 500 and TCP port 4500.
What encryption should I use for site to site VPN? ›Additionally, AES-256 uses 14 rounds of encryption as compared to 10 with AES-128. Based on these facts, you should choose based on security requirements and compatibility on your customer gateway. However, we recommend AES-256.
How do you check if my connection is going through a VPN? ›- Turn off your VPN.
- Visit WhatIsMyIPAddress.com. You'll see your public IP address — the one that's assigned to you by your internet service provider (ISP). ...
- Turn on your VPN and connect to a server in your chosen location. ...
- Check your IP address again using the same method as before.
Websites and other online services you visit can see the IP address of the VPN server you're connected to. If they want to, they can check that IP address against lists of known VPN and proxy servers to see if you're using a VPN.
How do I know if my VPN location is working? ›There are several different ways to check that your VPN service is working properly and protecting your internet traffic and personal data. Check your IP address. Take note of your current IP address, connect to a VPN server, and recheck the IP address. If it differs from the one you initially noted, your VPN works.
Why you shouldn't use VPN all the time? ›Why shouldn't I use a VPN? A VPN might reduce your connection speed even if your internet service provider isn't throttling your speed; Using a VPN on mobile will increase your mobile data usage; Using a VPN is considered an offense in some countries, and you can get fined or even be incarcerated for it.
Does VPN weaken internet? ›Yes. A VPN will slow down the internet speed on any device. Some more than others, depending on the capabilities of the device, but even your iPhone is vulnerable.
Can my VPN cause internet problems? ›
If the internet is not working when you're connected to VPN, using an older VPN version might be the reason. Having an updated VPN is important to avoid connection issues. If you are running an outdated version, update it. You can also re-install the VPN software again.
Can a site to site VPN be hacked? ›VPN services can be hacked, but it's extremely difficult to do so. Most premium VPNs use OpenVPN or WireGuard protocols in combination with AES or ChaCha encryption – a combination almost impossible to decrypt using brute force attacks.
Do internet providers block VPN? ›There are multiple ways an ISP can block your VPN connection. One of the most common and easier approaches is to block the VPN server's IP address. This is the same method that websites—especially streaming sites—use to block VPN users.
Why do so many websites not work with VPN? ›Many websites block VPNs because they don't want to break their contracts. Simply put, many VPN users want to bypass geo-blocking features.
What are the 3 most common VPN protocols? ›- OpenVPN. OpenVPN is a very popular and highly secure protocol used by many VPN providers. ...
- IKEv2/IPsec. IKEv2/IPsec sets the foundation for a secure VPN connection by establishing an authenticated and encrypted connection. ...
- WireGuard. ...
- SSTP. ...
- L2TP/IPSec. ...
- PPTP.
Can police track online purchases made with a VPN? There is no way to track live, encrypted VPN traffic. That's why police or government agencies who need information about websites you visited have to contact your internet service provider (ISP for short), and only then your VPN provider.
How to configure Cisco site to site VPN? ›- Step 1: Creating Extended ACL. Next step is to create an access-list and define the traffic we would like the router to pass through the VPN tunnel. ...
- Step 2: Create IPSec Transform (ISAKMP Phase 2 policy) ...
- Step 3: Create Crypto Map. ...
- Step 4: Apply Crypto Map to the Public Interface.
- Configure the VPN Service Listeners. Configure the IPv4 and IPv6 listener addresses for the VPN service. ...
- Create an IKEv1 IPsec Tunnel on the CloudGen Firewall. ...
- Create an IPsec Tunnel on the Remote Appliance. ...
- Create Access Rules for VPN Traffic.
- Right-click on the wireless/network icon in your system tray.
- Select Open Network and Sharing Center. ...
- Click Set up a new connection or network.
- Select Connect to a workplace and click Next.
- Click Use my Internet connection (VPN).
- Enter Your VPN Server IP in the Internet address field.
In ASDM you can go to Monitoring -> VPN -> VPN statistics -> Sessions and select "IPsec Site-to-Site" as the filter. Hi Tod, on the cli, indeed the counters in "show crypto ipsec sa" will tell you whether data is passing over the tunnel.
What are site to site VPN routing protocols? ›
Site-to-Site VPN provides a site-to-site IPSec connection between your on-premises network and your virtual cloud network (VCN). The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives.
What are the requirements for IPsec VPN? ›All IPsec VPN configurations require at least two items: (1) the Internet Security Association and Key Management Protocol (ISAKMP) or Internet Key Exchange (IKE) policy; and (2) the IPsec policy.
Is IPsec a site to site VPN? ›IPsec VPN securely interconnects entire networks (site-to-site VPN) OR remote users with a particular protected area such as a local network, application, or the cloud.
What is site to site VPN in VPC? ›AWS Site-to-Site VPN is a fully-managed service that creates a secure connection between your data center or branch office and your AWS resources using IP Security (IPSec) tunnels.
What parameters do you need to specify to connect to a VPN? ›The VPN type to be provisioned on the device. Specify the name which needs to be displayed as the VPN name on the end user's mobile device. Host name or IP address of the VPN server. Select whether the user must authenticate using password or certificate while initiating the VPN connection.
What are the two 2 components required to configure remote access VPN? ›The two main components of this type of VPN are a network access server (often called a NAS but not to be confused with network-attached storage) and VPN client software. A network access server could be a dedicated server or it might be a software application running on a shared server.
What is site to site IPSec tunnel configuration? ›A site-to-site IPsec tunnel interconnects two networks as if they were directly connected by a router. Systems at Site A can reach servers or other systems at Site B, and vice versa. This traffic may also be regulated via firewall rules, as with any other network interface.
How to configure IPSec VPN on router? ›- Log in the web interface of the modem router. ...
- Go to Advanced > VPN > IPSec VPN, and click Add.
- In the IPSec Connection Name column, specify a name.
- In the Remote IPSec Gateway (URL) column, Enter Site B's WAN IP address.
- Configure Site A's LAN. ...
- Configure Site B's LAN.