Dual tunnel VPN from AWS to Meraki

[Azy1]

AWS provides dual tunnel per VPN but we can't create both the tunnels from the dashboard as both will point to the same private IP of the VPC. 

been followng this guide below and was able to create dual VPNs however unable to connect to AWS servers after setting up both the tunnels.

https://documentation.meraki.com/MX/Site-to-site_VPN/Tag-Based_IPsec_VPN_Failover

couple of questions:

1. what should be the private IP on the dashboard when setting up based on this guide - should it be 0.0.0.0/0 or VPC CIDR?

2. The network tags seem to get removed on one connection in the dashboard while the second tunnel defaults to no networks ? any advice  please.

[PhilipDAth]

That is a relatively complex configuration.

Your remote encryption domain should be the VPC supernet.  Your peer IP address should be the public IP address of the Amazon AWS VPN gateway.

I've done something equally complex using dual VMX.

https://www.ifm.net.nz/cookbooks/meraki-ha-vmx-amazon-aws.html 

[Azy1]

Thank you Philip!

have you implemented the python script and got it working as the VMX looks expensive to just get the second tunnel up.

I have tried the same script on another meraki to AWS VPN connection and can't get it working although the python script successfully outputs every 30 second that its checking for the primary link is up.

Cheers

[Azy1]

@PhilipDAth 

I'm thinking of connecting an RV325 or some other firewall as a gateway device to the MX84 which supports route-based VPN. what are your thoughts on this approach?

[PhilipDAth]

I think it will be quite complicated to integrate into the environment.

[Tom_Shelton]

Hi @Azy1 

If it were me, I would take the following approach:

1) Use the CIDR of the VPC, unless you want to tunnel all of your traffic out of AWS(?)

2) The KB you are looking at shows some tools that you can use to monitor the performance/stability of that VPN and alter the VPN preference accordingly. If you are struggling, I would focus on getting the primary up and running first and verify connectivity. Worry about the failover afterwards 🙂

Tom