IPsec Non-Meraki Peer

[RahulPrasadh]

We have two non-Meraki IPsec tunnels configured for our network. They are to separate remote peer IPs. And each peer will need a secondary tunnel configured and both primary & secondary tunnels configured with the proper local-IDs to specify which tunnel is supposed to come from the FIA and which from the coax.

Is there any supporting documentation to support the configuration.

[Mloraditch]

There is a new feature available to do some of what you want:

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

I don't believe however that you can bind the tunnels to specific wans.

[Tony-Sydney-AU]

Hi everyone!

@RahulPrasadh , I recommend you read and understand this document before reading the other one @Mloraditch mentioned.

@RahulPrasadh , regarding local-ID: this is only available if the VPN is using IKEv2; this is optional but if you don't specify then MX will send "real IP" configured on that WAN interface.

Example:

Suppose your MX has two WAN uplink interfaces and each one is connected to a ISP router that does NAT. So something like this:

-> WAN1 IP 192.168.0.11 (real IP) and Public IP 11.0.0.11

-> WAN2 IP 172.16.0.22 (real IP) and Public IP 22.0.0.22

-> VPN peer IP 3.3.3.3

In this example, If you don't configure local-ID then MX will send 11.0.0.11 over WAN1 and 172.16.0.22 over WAN2 to the VPN peer when negotiating IKEv2 tunnel.

You can learn more about all the non-Meraki settings here.

On another topic, IPsec over VPN is a really cool feature! Thanks for bringing this up, @Mloraditch ! This feature offers new network design opportunities and I was particularly waiting for it.

I say this because I used to work with AWS before and their VPN service always has two endpoints and then AWS used to generate a lot of emails warning customers that they don't have redundancy configured.

So it was only frustrating and time wasting since most customers already knew that and they also knew they couldn't configure the redundant tunnel because their device didn't support. As it used to be the case with Meraki.

But not anymore!😎 And linking to your comment, @Mloraditch , at the moment We can't bind the tunnels to specific WANs. What I mean is: this IPSec over VPN feature is designed to interconnect with non-Meraki VPNs; as such, non-Meraki VPN tunnels will obey Primary WAN preference. This behaviour is documented here.

However, I believe We can have a VPN tunnel traffic engineering feature in the future if enough people make a Feature Request. To your point @Mloraditch , this would allow VPN traffic to flow on a selected WAN.

I'm particularly excited by this possibility now that Meraki supports IPSec over VPN. In order to make VPN tunnel traffic engineering possible, first of all, We would need non-Meraki VPN supporting Active-Active VPN Load Balance so BGP sessions can exist within each WAN uplink. That would give us two egress interfaces.

Next, since We have two egress interfaces, then We could fine-tune BGP settings to have a better Local Preference on a specific tunnel and also advertise certain subnets/prefixes with AS-Path prepending to influence the return traffic to flow via the same tunnel. That would be so cool! 😎

Everyone can make a feature request by going to the bottom right corner of your Dashboard and sending the request through the "Give Feedback" bubble.

Once you sent your Feature Request using the "Give Feedback", our Internal Team will process your suggestion and eventually you'll have your feature in the future. Keep in mind there will be no estimated time to implement your suggestion/feature.

Hope this information is useful. Feel free to post here anytime if you have further questions / concerns.