Meraki is a widely deployed enterprise SD-WAN, switching and wireless solution. This is all managed in a centralized single pane of glass cloud hosted management system which facilitates an ease of deployment without the requirement for a large network engineering team for design and deployment. There are drawbacks in this system as there is always a tradeoff between complexity and functionality. This post will discuss this tradeoff within the VPN environment in Meraki deployments covering the below topics.
- AutoVPN – how it works and what it does
- Non-Meraki VPNs – how they work in a Meraki world
- AutoVPNs and Non-Meraki VPNs together – where they do work, where they don’t work
Auto VPN
SD-WAN Meraki VPNs between different Meraki nodes are built automatically using the AutoVPN feature. This feature is an automated Meraki solution which only requires a single click in the Meraki Dashboard. This allows the quick provision of Branch sites connectivity back into the Meraki network environment. The Site-to-site VPN policy is automatically provisioned which removes administrative overhead, however, does remove some granular control.
As with many SD-WAN solutions, there is the option to provide multiple internet uplinks which the Meraki system can use to build the transport overlay. With multiple links available the Meraki system can auto-heal and move traffic from a failed connection to a functioning connection. There are also options to dynamically define which links can be used to route traffic, to load balancing and to define what the failure parameters are for failover.
The SD-WAN options relating to traffic shaping in the Meraki Platform resemble QoS solutions which exist across many non SD-WAN solutions without offering packet by packet steering or AI driven traffic steering, like some leading SD-WAN vendors. The policy is defined by the user and once a failure threshold has been reached traffic will be moved to a backup link. Unfortunately, this results in a link which is completely standby and means that you are unable to maximize what is available by dynamically adapting to the condition of the link on a packet-by-packet basis.
Split-tunneling and full-tunneling is facilitated by the AutoVPN feature to allow flexibility for Branch and Remote workers connections to either be offloaded to reach SaaS/internet solutions or have all traffic backhauled through the Hub site.
There is also the option to deploy a virtual MX solution to Cloud providers, such as, AWS and Azure. This vMX acts as a one-armed VPN concentrator allowing private cloud hosted services to be reached easily over an automatically configured AutoVPN solution.
The diagram below depicts an example of an AutoVPN deployed solution. There are spoke MX nodes deployed at Branch offices with a Hub MX at a corporate data centre, a virtual MX providing access to cloud hosted solutions and a series or remote workers with a Z3 teleworker solution. All these locations can easily be interconnected within the Meraki Dashboard by enabling the VPN feature at each location. Once the VPN feature is enabled they will automatically build VPNs to each other by dynamically deciding the IP address to use on each device, defining IPSec policy and enabling NAT Traversal.
Non-Meraki VPN
The Meraki platform will allow the network administrator to build 3rd party VPNs manually within the Meraki Dashboard. This allows an interoperability with sites which may contain other vendor hardware with no option to deploy a Meraki platform. This is not a granular solution, with options to define the IPSec policy but the policy is applied to all nodes enabled for VPN connectivity in the whole environment.
In the example below there is the option to create a 3rd party VPN to some shared cloud hosted resources with a vMX VPN concentrator. This would allow the 3rd party to access services hosted behind the vMX. If it were decided to extend these VPN connections beyond the vMX to the Hub site then the VPN configuration would only need to occur on the 3rd party side. This is due to the 3rd party VPN configuration being universal on the Meraki platform.
Auto VPN and Non-Meraki VPN together
In the instance there is a requirement to allow access to the entire environment to the 3rd party, this would not be facilitated by the Meraki platform. By design 3rd party Meraki VPN routes are not propagated to AutoVPN peers. This means that in this example if a VPN between the vMX and 3rd party was configured, the vMX would not propagate these routes to the Hub, Spokes or home workers and therefore the 3rd party resources would not be reachable outside of the Cloud environment.
The solution to this problem is to introduce a 3rd party vendor into the Meraki environment to use as a VPN concentrator for 3rd party VPNs. In this instance you can build all your 3rd party VPNs outside of the Meraki system and share the routes to all AutoVPN peers through the locally hosted 3rd party device and share the remote 3rd party routes to the local MX as depicted in the diagram below. This can be achieved by giving the 3rd party vendor device it’s own connection to the internet to form the VPNs or by using port forwarding on the Meraki system to keep the Meraki on the edge.
Summary
The Meraki SD-WAN solution provides an easy to use and deploy solution for a universally Meraki environment. Once a different vendor is introduced the tradeoff between complexity and functionality is exposed, with a complete redesign required to facilitate communication between the two environments. It is worth noting that once you go down the Meraki path, it is hard to diverge!