By Steve Harrison

Virtual Private Networks (VPN) have been a mainstay in corporations for the past 20 years. They allow companies, government agencies, and departments to make potentially sensitive communications over an untrusted network. In the last few years, they have become the transport independent overlays of most SD-WAN solutions.

The problem is that the configuration of these technologies and the plethora of phases, modes, and encryption algorithms means that getting and staying secure can be a laborious task. This is where Auto VPN from Meraki offers a quick and easy way to become—and automatically stay—secure via the cloud.

At Cisco Meraki, we’ve been talking about VPN for a long time. However, up until now, we haven’t described what makes our Auto VPN different from everyone else’s “normal” VPN.  In this blog post, we’ll show how our technology takes the hassle out of designing, configuring, and maintaining VPNs.

It started with Punch!

First, before we even think about VPN-ing from one MX to another, we need to know where and, more importantly, how they talk to one another. In order to do this, we leverage a service we call “punch”—we use this because our MX security appliances aren’t necessarily directly connected to the internet. They could be behind another public firewall or deployed in VPN concentrator mode in either a DMZ or data center core network.  

The punch process automatically tries to “punch” its way out to the internet/public IP space through any Network Address Translation (NAT) device. To do this, a technique called UDP hole punching is used (if your Meraki MX is behind an older “NAT-unfriendly” firewall, then we can use a technique called manual port forwarding to get around it). The MXs also use punch (or manual port forwarding) when it comes to tunnel establishment.

After Punch comes registration

The punch process is actually the “client” in a client-server relationship, with the server portion being the “Cisco Meraki VPN Registry.”  The VPN Registry is a service independent of the Meraki dashboard, used to register each MX’s public and interface IP addresses. The Registry then uses some simple logic to understand how to route between the various MXs in an organization (in order to create VPN tunnels). Namely:

1. Check for match – If the MX’s public IP and the interface IP match, then the MX in question is directly connected to the internet on that WAN interface
2. No Match – MX WAN circuits with different public IP addresses should route between those public IP addresses directly
3. Route Initiated – If the two MX’s public IP addresses match, then the MXs in question are in the same private network. As such, they should route to one another via their interface IP addresses

The VPN registry then passes this information to the dashboard.

Then the (Meraki) magic

Not only does the dashboard now know how to route between all the MXs in the organization, it also knows how many WAN paths each MX has, as well as the desired VPN topology. All of this together means that the dashboard magically knows:

• Who to build tunnels to and, more importantly, how to route
• Which IP subnets are accessible via which remote MX
• How to route to an indirectly connected (i.e., one without a direct tunnel) MX
• That both sides of the communication are entirely trusted and authenticated, as they are both authenticated, authorized, and managed by the dashboard

The above traditionally took days or weeks of careful planning and the provisioning of static IP addresses, route-maps, and tunnel parameters. Then, this would have to be configured into all the routers that form part of the organization (usually outside of working hours), eating up time and money. Also, routers normally have to do a special secure handshake with one another to ensure that they are who they claim to be and that the medium over which they are communicating is insecure.  

The Auto VPN on the MX has two key benefits over the technologies traditionally used:

First, on the MX all of the above “magic” happens within the first 30 seconds of an MX powering up, or is there by default as both sides are managed “automagically.”

…but before continuing, we have a little myth-busting to do, as there is no such thing as a completely secure encryption algorithm, as Alan Turing and company at Bletchley Park proved. In order to stop people from seeing your information, you need to regularly change the keying material the encryption algorithm is using.

The only way to do this effectively is to continually update the keying material you use with your encryption algorithm to encode your information (text) into ciphertext. This means that periodically you should change the keying data on every router. This keying material should be unique on a per virtual path basis; you can understand this is a massive task fraught with many misconfiguration dangers.  

This is the primary reason a lot of organizations with such setups simply “set and forget” their configurations and don’t realize how dangerous this can be.

(Now back to our originally scheduled programming!)

Second, and by far the most important advantage of Meraki and the dashboard, is that all MXs regularly check-in for an updated configuration file. This way, the dashboard can automatically refresh such keying material succinctly, thus maintaining tunnel security effectively and effortlessly.

All you need to do now is sprinkle a little patented Meraki magic dust and you have an enterprise-class, industry-leading SD-WAN solution.

Conclusion

Meraki Auto VPN takes a traditionally complex technology and transforms it with 100% cloud-based technology to make it simply work. Oh, and it’s so easy to configure that even your salesperson can do it. It’s also the baseline for SD-WAN and being able to save your business a lot of money. If you want to learn more and get free Meraki kit, watch our on-demand SD-WAN webinar or contact a Meraki sales rep for a demo and trial.

References

https://meraki.cisco.com/lib/pdf/meraki_whitepaper_autovpn.pdf
https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Troubleshooting_VPN_Registration_for_Meraki_Auto_VPN
https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Automatic_NAT_Traversal_for_IPsec_Tunneling_between_Cisco_Meraki_Peers