Setting up site-to-site VPN
When using Systems Manager Sentry VPN security, the username and password used to connect to the client VPN are generated by the Meraki cloud. Usernames are generated based on a hash of a unique identifier on the device and the username of that device. Hello, I have setup the VPN client.my main subnet is 10.69.11.0/24 and my client VPN is 10.69.69.0/24. I have specified name servers as follows, 10.69.11.16 being the IP of my DC/DNS server. From a vpn client, I can ping, reach any resource using the IP address, but I can't resolve names.
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 appliances in 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 available if the MX-Z device is configured as a Hub. 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 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.
Spoke Type
Meraki Create Vpn User
Hubs
When an appliance is configured as a Spoke, multiple VPN Hubs can be configured for that appliance. In this configuration, the Spoke MX-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 routes take 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) Advertises the 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 Actions column. 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 devices 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-Z 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-Z device. 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.
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 meets the following criteria will be used for such a subnet.
A) Advertises the 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 device 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-Z device 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-Z device using 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.
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 Concentratormode. 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 tunnel configurations 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 cause traffic in a more 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.
Drivers supermicro. 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
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.
You can create Site-to-site VPN tunnels between a Security Appliance or a Teleworker Gateway and a Non-Meraki VPN endpoint device under the Non-Meraki VPN peers section on the Security & 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-Meraki VPN 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
NOTE For 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 device will 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, SHA1 or SHA256* authentication
- Diffie-Hellman group: Select between Diffie-Hellman (DH) groups 1, 2, and 5
- Lifetime (seconds): Enter the phase 1 lifetime in seconds
*SHA256 requires firmware 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-Z appliances 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 rules will not apply to inbound traffic or to traffic that is not passing through the VPN.
Cisco Meraki uses the integrated Windows client for VPN connection (no Cisco client at this time).
To be able to connect with simple AD user account credentials, along with a simple pre-shared key, the steps are very simple.
9 Steps total
Step 1: Get started
Click on Start and type in VPN, click on Change Virtual Private Networks (VPN)
Setup Meraki Vpn To Azure
Step 2: Add connection
Click on Add a VPN connection
Meraki Setup Vpn Windows 7
Step 3: Configure Windows connection
Pick VPN provider as Windows
Name the connection
Put in server name or IP
Switch VPN type to L2TP/IPsec with pre-shared key
Switch Type of sign in to User name and password
Enter the username and password if you want to save it, or leave blank and user will have to enter it on connection
Hit Save
Step 4: Edit settings
Once you hit Save, it will bring you back to the connection page
Click on Change Adapter Options
Step 5: Configure adapter
In the adapter window, click on the adapter with the name you created in the VPN window
Click on Change settings of this connection
Step 6: Step 6
Click on Security tab
Make sure Type of VPN is still Layer 2 Tunneling Protocol with IPsec
Set Data encryption to Require encryption (disconnect if server declines)
Set Allow these protocols
Check Unencrypted password (PAP) - will still be, so don't worry
Click Advanced settings
Step 7: Add key
Meraki Vpn Setup Ios
In the Advanced settings, click on Use preshared key
Type in the key you want to use
Hit OK to go back to the adapter settings
Click OK to close the adapter settings and save.
Close all other windows at this point.
Step 8: Connect
Connect ..
Click on the network icon in the system tray
Click on the VPN network connection name
Click on Connect
Meraki Setup Vpn Free
Step 9: Verify and disconnect
Meraki Vpn Setup Steps
Verify you are connected
Click on the network system tray icon again if the window closed or minimized
You should now see the VPN network name listed and Connected underneath it
(If you are done with your connection, click on it and click Disconnect)
Now and then Windows Updates breaks the encryption settings by changing from PAP to MS-CHAP. If users could connect before, but suddenly can't while others can, revisit Step# 6 and verify PAP is turned on, not MS-CHAP. Save and all set!
8 Comments
- ChipotleBMG_Zone Jun 20, 2018 at 12:42pm
I have a customer who is stating:
We've run into a weird problem where the built in Windows 10 vpn gets its settings changed whenever the wifi network changes. We have consultants who travel to various client sites and every time they try to connect to our vpn server they have to fix their vpn settings. The company we had hired to set up our vpn server said they can't help us with this, probably because it's a Windows issue
Any Ideas?
- HabaneroKrasimirPetrov_ Oct 31, 2018 at 02:46am
Good read. Thank you very much for sharing.
Excellent tutorial - SonoraLRSpartan Jan 8, 2019 at 04:49pm
We have been trying to overcome the same problems with MX64 and making an outbound rule entry in Windows Defender Firewall is what helped us. We had performed all the other instructions Meraki and MSFT had provided including the regedit (asumeUDPEncap..).
We created a UDP port rule for 500, 4500 and scoped it to our vpn IP address. Finally works.
I hope this helps.
- Pimientoericguth2 Jan 28, 2020 at 09:00am
LRSpartan - are you saying that you port forward UDP 500 and 4500 to your VPN range 192.168.XXX.00/24?
- PoblanoAaronTheYoung Feb 3, 2020 at 08:15pm
We are constantly plagued by our VPN connection losing its settings as well. I'm not sure if this it relates to change in WiFi, but the people that it occurs with do seem to be people that change WiFi often. Others who are using it from one network at home seem to not have the issue.
In any case, I am constantly connecting to users who are remote and fixing their settings. Either resetting their Username and Password settings or fixing the PAP/CHAP protocol settings.
Is there a way to use the Powershell command ADDVPNConnection to create a script that would re-create the settings in one fell swoop?
Any help would be appreciated.
- Datiltroberts2 Mar 4, 2020 at 08:22pm
We have seen those same settings and we hear there may be a Meraki VPN Client or Cisco AnyConnect Client that is Meraki compatible in the near future, but that has also been ongoing for like 3 to 4yrs now. Once it comes out, should be a moot point on Microsponge changing your settings. I have seen the same issue though, seems to be mostly tied to Microsoft and the firewall flipping the network to public and effectively blocks like everything so you can't connect. Only way we have gotten it to work is when on that network, switch it from Public to Private, reboot the machine and possibly also the network router you are using and then it works, and yes you are sharing when connected initially to that network, but once on the VPN, tunneled into your network and secure again. Fingers X'd on the client coming out vs WinDoze client.
- Pimientospicehead-hu3x0 Apr 14, 2020 at 06:09pm
The Dreytek VPN client works for the meraki, I hope Cisco comes out with their own soon.
- Jalapenobranchms Jan 21, 2021 at 10:04pm
I'm having nothing but trouble getting this to connect.
Using windows 10 and Meraki MX64.Can you suggest a resolution?
Comments are closed.