Cloud managed VPN at Christian Aid using Meraki Security Appliances

When we decided to replace of our aging Cisco ASA firewalls, one thing we knew for sure was that we needed a VPN to give staff working in our remote offices access to the internal resources located at our HQ in London.

On the ASAs we used the Easy VPN feature to do this.  This is different from traditional IPSEC VPNs in that you don’t need to know the IP address for each node.  Since several ISPs we use for our global offices only give us dynamic IP addresses, this style of VPN isn’t possible.  Easy VPN gets around this by treating each ASA as a VPN client – the remote ASA 5505s initiate the VPN connection to a known hostname or IP address at the HQ.

This worked really well with the Cisco ASAs, so we wanted VPN that was as easy to roll out and maintain.  The Meraki security appliances proved to be even easier.

Basic Configuration

The interface for a site to site VPN is very simple with only three options to select for our purpose:

Mode

Three settings:

1. Disabled (i.e. no VPN)
2. Split tunnel (only traffic to and from VPN connected networks goes over the VPN tunnel)
3. Full tunnel (all internet traffic from the device is sent over the VPN tunnel.

At Christian Aid we use the Split tunnel option.  We know that the majority of traffic from each site is to and from the Internet (increasingly more so as we move our own resources to the cloud) and having that traffic first travel via HQ is not the very efficient, and will hammer our HQ internet connection.

Topology

Even simpler – only two options.  The first option to Connect Cirectly creates a mesh VPN – each node connects to every other node.  Traditional IPSEC VPNs can do this but have to configure the fixed public IP address of each node on all the other nodes.  The Meraki cloud handles this automatically.  Easy VPN did not allow us this option at all, so we never had to face the challenge of keeping IP addresses updated across over 40 locations.

A benefit of a mesh VPN is if clients at remote sites need to communicate directly without passing through HQ.  This lends itself to distributed Active Directory networks – with a mesh VPN domain controllers at different locations can replicate with each other.  Previously replication had to come via our headquarters.  A mesh VPN promised better replication and redundancy – if our headquarters went down for any reason, or DCs could still replicate.

We also wondered whether peer to peer communication solutions such as Skype would work better, although we haven’t really answered that yet.

There is a hidden third option that appears if you select Connect directly to only one peer that allows a hybrid of the two – if you select hub and spoke mode you can select multiple hubs – a spoke can create VPN tunnels to multiple locations.

You can also configure different topology settings for each node.

This allows you a great level of flexibility.  In our case, sites that have a DC are set to connect directly to all VPN peers.  Sites without a DC are set to only connect to our HQ.  This results in the DC sites being meshed so they can replicate, but non-DC sites aren’t part of the mesh.

More of this later when I discuss Non-Meraki VPN Peers.

NAT Traversal

This sets up port forwarding through the Meraki device (not through the ISP equipment which may be doing NAT – more on that later).  In our case Automatic has always worked fine.

Advanced configuration options

As mentioned above you can use the Topology option if you have more complex needs.  It is also possible to add non-Meraki VPN peers that can be joined to the mesh.  A future plan we are hoping to implement involves creating Domain Controllers on the Azure cloud, to make our Active Directory infrastructure site redundant.  The thinking is that we can then add these DCs as non-Meraki VPN peers, and they will then be linked to   As things currently stand, it looks like these may be one way only like Easy VPN clients.  At some point in the future we hope it is possible to create virtual Meraki VPN peers on the Azure cloud that can be configured to work exactly the same as a hardware MX device.  That would allow us to use Azure hosted servers to provide cloud based authentication, Active Directory, print driver deployment, RADIUS – my colleagues and I see a lot of potential in this. I guess I should make a wish…

Outcome and monitoring

With three basic settings in place across our MX devices, we had a working VPN network up and running so quickly we actually spent some time looking for additional settings before we realised we’d completed the job!  Meraki MX devices easily met or exceeded our requirements in this area.

Here is a map of our 45 sites connected by VPN at the time of writing this article.

Note that sites physically close together (at this scale) are grouped.