non-Meraki VPN peer to Auto-VPN sites?

[cabricharme]

What is the best practice to connect a non-Meraki VPN peer (e.g. our Azure or AWS services) to our auto-VPN sites (networks)?

Seems this cannot work purely within Meraki:

Auto VPN and Non-Meraki VPN peers

An MX Security Appliance can establish tunnels to both Auto VPN and Non-Meraki VPN peers. The MX will send traffic to those VPN peers using the principles discussed above. However, an MX that builds tunnels to both Auto VPN and Non-Meraki VPN peers, will not route traffic between the non-Meraki VPN peers and other Auto VPN peers.

... yet this seems a fairly common SD-WAN configuration for any org with multiple branches and hybrid or MSP-managed environment?

P.S. The other parts I can't seem to wrap my head around:

• why is there an "availability" configuration in non-Meraki VPN peering settings? Just in case remote networks aren't connected via auto-VPN but via some other mechanism?
• when "availability" is set to "all networks", the non-Meraki VPN peer is lit up green on the network where it's configured, and red on all others. Is this Meraki way of saying, "we don't support this configuration even though our UI provides no indication that it won't work during configuration"?

[alemabrahao]

Using a vMX on azure or aws.

[PhilipDAth]

https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Comparison_Datasheet

[cabricharme]

vMX is not always an option with MSPs. In our case - not (yet) an option.

The goal is to make it work between a non-Meraki peer and auto-vpn peers. Performance requirements are negligible.

[KarstenI]

The "Availability" option is exactly what you need when you are not (yet) ready for vMX. You configure the non-meraki VPN once, and any branch that is configured in the Availability option, will build an individual IPsec-tunnel. With that you have a very small config even for a large amount of branches. Your non-meraki VPN-Hub still needs to be configured to accept the session from all branches.

[cabricharme]

Sorry that I am not entirely following.

---

You configure the non-meraki VPN once, and any branch that is configured in the Availability option, will build an individual IPsec-tunnel. With that you have a very small config even for a large amount of branches.

---

Doesn't the idea of building individual tunnels to each branch contradict the idea of a "very small config"? I.e. could a set of 20+ individual VPN tunnels be called a "very small config" even if they're configured similarly?

(We are essentially asking the MSP to build and maintain a fairly large number of individual tunnels on their side - all because we on our side can't route single VPN tunnel traffic to/from our branches? That doesn't quite make sense to me.)

---

Your non-meraki VPN-Hub still needs to be configured to accept the session from all branches.

---

What is a "non-Meraki VPN-hub"? I've poked around searching for it, and not seeing much. Native Azure VPN gateway SKUs all seem to be site-to-site, i.e. there isn't a way to configure a single one to connect to multiple endpoints in a hub-like fashion., and you pay separately for each one you set up. Similarly, most other S2S VPN gateways seem to be set up in a similar fashion: separately configured individual tunnels vs. anything resembling a "hub".

P.S. It seems (to this VPN/networking rookie) that setting up one VPN tunnel from our HQ to the MSP using non-Meraki tech e.g. a standalone Aruba S2S appliance is all there should be to it:

• Meraki will see it as a direct-attached subnet, and thus allow to route traffic to/from it, including to/from Auto-VPN sites
• the MSP only has to maintain one tunnel
• we only have to maintain that one appliance and the associated tunnel with its routing and ACLs

(At least that's what I am seeing suggested on the interwebs when searching for "connect a non-Meraki VPN peer to Auto-VPN sites".)

P.P.S. Granted, the above (using a non-Meraki VPN appliance configured outside of Meraki) falls outside of the OP question scope:

---

What is the best practice to connect a non-Meraki VPN peer (e.g. our Azure or AWS services) to our auto-VPN sites (networks)?

---

... but then so does the vMX.

I.e. the answer to the OP question ("what is the best practice...") seems to be a "no, Meraki does not appear to offer a good, simple way to connect a non-Meraki VPN peer to auto-VPN sites, however the simplest way to do this is using a non-Meraki S2S VPN gateway - especially if the number of auto-VPN sites is large enough."

Thanks!

[KarstenI]

The "very small config" is based on the fact that you do *not* configure one tunnel per branch office. Four your 20 sites, you configure exactly one line in the dashboard. But by referencing 20, 50, 100 networks in the availability, the tunnel is setup on all these networks.

This is needed because on Meraki we *do not* have routing between non-Meraki and AutoVPN tunnels. 

The term "non-Meraki VPN-hub" is nothing official. It was meant to emphasise that the peer for these tunnels is not a Meraki Hub in the same dashboard org. Because in AutoVPN we would have full routing capabilities.

[cabricharme]

Thank you.

Is it safe to assume that the following is then the best (so far) answer to the original question?

I.e. the answer to the OP question ("what is the best practice...") seems to be a "no, Meraki does not appear to offer a good, simple way to connect a non-Meraki VPN peer to auto-VPN sites, however the simplest way to do this is using a non-Meraki S2S VPN gateway - especially if the number of auto-VPN sites is large enough."

---

[KarstenI]

I would skip the "especially" as it is basically the same work for 1, 10 or 100 networks. 

My best practice is typically to move these tunnels away from the MX to a different device because there are no inbound filters for these VPNs and the whole network is exposed to the peer.