Meraki MX65 - routing over VPN question

Here to help

Meraki MX65 - routing over VPN question

Hey Guys,


Nice to meet you all. This is my first post!


I've got an MX65 configured at Site1 to use a non-meraki-site-to-site VPN to an AWS host. I've configured allow rules and routing on the AWS side so traffic over the VPN can flow. That's working well and I can connect to devices in AWS over the VPN.


I've now added a 2nd MX65 to the Organisation at Site2.


I've set Site1 VPN to Hub (mesh) and Site2 VPN to Spoke and ticked allow local subnets to use the VPN. I can communicate between Site1 and Site2 over the VPN.


I've updated the allow rules and routing on the AWS side to include the Site2 subnets. However, I can't seem to get any traffic going from Site2 to AWS. I've disabled all firewall deny rules in case they were interfering.


I thought MX65 auto populate VPN routes to other MX65 peers. Is there some other route or rules I need to set in the MX's to allow traffic from Site2 to reach the AWS side over the non-meraki-vpn-to-AWS?


What do you guys think?

Kind of a big deal

Hey, and welcome!


The way you're trying to do this won't work. You won't be able to get the remote network from the non-Meraki VPN into the AutoVPN so Site2 has a route to AWS. You're better off to convert site 2 to a hub as well, and nail up a second non-Meraki VPN to AWS directly from there. 

Hey jdsilva, many thanks for your reply. 🙂


If I turn Site2 into hub as well, won't that mean the default route setting get's automatically enabled in the auto vpn so all traffic at Site2 will go through Site1's internet?


Also, if I add a 2x non-Meraki VPN into AWS, won't I get some routing mess/crossover between the two networks and AWS?

Kind of a big deal

Nope. Hubs, or spokes, are not directly related to default routes. As a hub you have to specify an "Exit Hub" for that hub to receive a default. If no exit hub is specified then it's a split tunnel:




Same with a spoke, if the default route box isn't checked then no default route there and it's a split tunnel:




On the AWS side you would specify the LAN subnet behind each MX in the VPN settings for that tunnel. So if site1 has on it, and site2 has 1892.168.2.0/24 on it, each VPN tunnel config would have only the network for that site configured in it.


That all make sense?

Ahh thank you yes, that makes sense. I'll discuss with my AWS guy and see if we can implement. Thanks for your help 🙂

Also, both MX65's are under the same Organisational dashboard, I'm assuming that's ok too and they don't need to be split into two Orgs?

Hey jdsilva,


Ok I've tested the settings you suggested and I'm getting a subnet error.

Here's what I've set:

Added a 2nd VPN connection to AWS for the 2nd site. Set AWS vpn1 to only include Site1 subnets. Set AWS vpn2 to only include Site2 subnets.

Set both MX65 to hub auto vpn mode (no exit hub).

Set Site1 non-meraki-vpn to AWS to only include Site1 subnets.


Next I tried to add the second non-meraki-vpn to AWS for Site2 with only Site2 subnets.

However, I get this error: There were errors in saving this configuration: The subnets on non-Meraki peers site1-non-meraki-vpn-to-aws ( and site2-non-meraki-vpn-to-aws-test vpn ( conflict.


It looks like I can't include the same AWS subnets in more than one VPN configuration? Could I use a default route of for both non-meraki vpn's instead? What are my options do you think?


Kind of a big deal

Yeh this is the confusing part about non-Meraki VPN. You don't need two entries on the VPN page. You'll notice the heading for this section  says the following:




Which means that every non-Meraki peer you configure will have a VPN connection attempt from every MX in your Org. You can control exactly which MXes this peer applies to through the availability field:




By default it's All Networks, but by using tags on your networks you can specify which tag, and therefore which network, this peer applies to. 


And you can only have one MX in a given network at a time, so by network I'm really meaning MX. 


So, you actually were all ready to go with just your single line, assuming you left the all networks tag in the availability field. The only thing you should have needed was your AWS guy to catch up with you 🙂

Oki so trying to get my head around what you mean. Apologies for my slow learning curve.


So, at the moment on the AWS side:

- The AWS Customer Gateway has the public IP address of Site1 MX65.

- The AWS VPN connection has the tunnel settings and static routes for which subnets can communicate over the vpn (Site1 MX65 subnets and AWS subnets) (ACL's and security groups are also set but probably don't need to go into that).


So what you're saying is, on Meraki dashboard, Site-to-site-VPN>Organization-wide settings> Add one non-meraki-vpn peer with the AWS vpn connection tunnel settings, then add all the "private subnets" we want to connect to on the AWS side, then for "availability" add "all networks" so both site1 and site2 MX's can communicate with AWS.


If that's right, what I don't understand is, how would AWS communicate with the public IP of the MX at Site2 for data flow to work to that MX? Or is that just assumed because it's global and both MX's are considered part of the same network?

Kind of a big deal

On the AWS side you will need to configure two distinct VPNs. One for each MX. 


Both MXes are part of the same Org (at least I'm assuming they are?), but not the same network. 

hey jdsilva,


In the end I created a case with Meraki support as I couldn't get it to work. They've told me running 2x VPN tunnels from AWS to 2x MX in One Organisation is not possible. The reason is, AWS creates a separate public IP for each tunnel and you can't link 1x non-meraki-vpn-peer to 2x public IP. You also can't create 2x non-meraki-vpn-peer that both contain the same private subnets. So, the solution is to either split into 2x Organisations, or deploy a vMX in AWS. I think for now we'll go with 2x Organisations.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.