Site-to-Site VPN Between Two Different Organizations

[Twitch]

Hey gang - what is the best practice for configuring a site-to-site VPN between two different organizations, for example, between our company organization and the organization of the parent company who just purchased us?

Both sides have Meraki MXs at the edge. Based on reading that I have done, it looks like the site-to-site will need to be established as non-Meraki peers since two different organizations are involved. If that's the case, the docs also state (if I'm understanding it correctly), that route information will not be shared between the non-Meraki peers, which presents a problem of reachability for remote networks on both sides. 

Thoughts and/or clarifications would be greatly appreciated.

Cheers!

Twitch

[Inderdeep]

@Twitch : Is that what you are looking for two different Orgs, yes they are non-meraki Peer

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

[DarrenOC]

Hi @Twitch , you’re reading and understanding is correct.

You’ll be running as two separate Orgs using non-Meraki peers.

Trying to figure out if you can do anything quirky for your home users!

[Inderdeep]

@Twitch :

[Twitch]

@Inderdeep @DarrenOC  - Thanks for the replies. You both have confirmed my suspicions about how the VPN would have to be setup.

@Inderdeep- That first bullet item causes me to wonder if the route advertisements will work with L3 switching enabled on our switch stack. We no longer have any subnets that are local to the MX, only static routes that point down to the stack. I'm thinking the static routes will still be advertised, since most of the routes have the "In VPN" box selected to advertise the static route to other VPN peers, which should work just fine for the non-Meraki peer VPN connection as well.

[Inderdeep]

@Twitch : Check this specifically Multiple Overlapping Routes in below link.

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior

[Bruce]

@Twitch I don’t believe there is a way to advertise the remote routes across each organisation’s AutoVPN without adding some additional hardware to the network. 

One answer could be for the parent company to put a VPN concentrator (part of their Meraki organisation) as a spoke into your network. You can then create static routes from your MX to point to this, and advertise those static routes into your AutoVPN. They then create local subnets on the MX concentrator to match your network subnets, which then get advertised into their AutoVPN.

[cmr]

@Twitch why not combine the two organisations?

[Twitch]

@cmr- That is the other option on the table. I have not started digging into that one yet. Hopefully Meraki has some documentation on how to do that.

Without having to go into too much detail, how complicated is it to combine organizations?

[Bruce]

@Twitch How much work it is to combine organisations depends on how big they are. Moving devices is easy, moving licenses is easy to (although requires support’s help if you’re in co-termination licensing mode), the hard part is moving the configuration. Depending how many networks and how complex they are it could be easy or hard.

[Twitch]

@cmr- If I am correctly reading this document:

https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Best_Practices_fo...

Merging the organizations involves completely dismantling all of our networks and rebuilding them from scratch in the new merged organization. From what I am gathering, nothing is transferable except the devices and the licenses - the configuration and all settings would be toast and have to be rebuilt from scratch.

That does not sound like a fun weekend...

[cmr]

@Twitch it is a big job if you have a lot of devices, but the APIs can be used to make a lot of it less bad...

[Twitch]

@Bruce- Interesting idea. That almost makes my head hurt just reading it. 🤣 I can see how that would work, though.

[Greenberet]

I wrote a script a while ago which will connect 2 meraki organizations over VPN.

Maybe this will help you: https://github.com/coreGreenberet/meraki_scripts/tree/master/v1/org2orgVPN

It will automatically configure all remote subnets for each VPN endpoint/Network.

You can filter the networks based on network tags.

You must have an API key which has access to both organizations!

usage: org2orgVPN.py [-h] -o1 ORGANIZATION1 -o2 ORGANIZATION2
                     [-t1 TAGS1 [TAGS1 ...]] [-t2 TAGS2 [TAGS2 ...]] [-p PSK]
                     [--ike-version IKE_VERSION]

This script will create/update the VPN connection between two meraki
organizations

optional arguments:
  -h, --help            show this help message and exit
  -o1 ORGANIZATION1, --organization1 ORGANIZATION1
                        the name/id of the first organization
  -o2 ORGANIZATION2, --organization2 ORGANIZATION2
                        the name/id of the second organization
  -t1 TAGS1 [TAGS1 ...], --tags1 TAGS1 [TAGS1 ...]
                        the tags from the first organization to grab the vpn
                        networks and remote IPs. Leave Empty for all
  -t2 TAGS2 [TAGS2 ...], --tags2 TAGS2 [TAGS2 ...]
                        the tags from the second organization to grab the vpn
                        networks and remote IPs. Leave Empty for all
  -p PSK, --psk PSK     the psk for the vpn connection. Use "random" to
                        generate a random key
  --ike-version IKE_VERSION
                        the IKE version. Must be 1 or 2

[Twitch]

@Greenberet- Thanks for sharing that! We will definitely check that out. Fortunately, my boss is a Code Monkey. 

Much appreciated. 

[PhilipDAth]

Choose a transit site (data centre, head office, etc).

Put an MX from one org there, and a second MX in VPN concentrator mode from the other org.  Configure static routes between them for the other orgs sites and redistribute these into AutoVPN (for both orgs).

Voila.  Both orgs can now talk to all sites.

[Twitch]

@PhilipDAth Interesting idea.

Provided that we use our office as the transit site, I assume we can use our existing MX100? With regard to the 2nd MX in VPN concentrator mode, would that also be located at our office, with it's own separate internet connection? Or could it share the existing connection with our MX100?

For the static routes, you're referring to adding static routes that point to the other orgs internal subnets, with their public IP as the next hop, correct? For example, 10.10.0.0/24 --> 2.2.2.1, with In VPN = Yes. Same on the other MX from the parent org with static routes pointing to our internal network?

[PhilipDAth]

>I assume we can use our existing MX100? 

Yes.  The 2nd MX would go behind your existing MX100 and use the same Internet connection.

You would give it a dedicated Internet connection if you wanted but that is not a requirement.

For your MX100, the static routes to the remote org would be via the private IP on the MX running in VPN concentrator mode sitting behind your MX100.

So if your MX had a LAN IP of 192.168.100.1, and the unit in the other org was 192.168.100.2, your static routes would be via 192.168.100.2.

Yes, you would include the static routes in VPN.

Yes, the other org would do exactly the same thing as you, but mirrored.

[Twitch]

Thanks @PhilipDAth -

That all makes sense. The one caveat is that we are running layer 3 switching on our switch stack, so I would assume I am going to add the static route to the other org there so it can be propagated via OSPF to our other sites that are currently on the VPLS? Our MX would then have a static route that points to the MX in concentrator mode for the other org so all traffic destined for the other org would be passed up from the switch stack and then routed over to the concentrator MX.

We are currently running a mix of Auto-VPN and VPLS. The Auto-VPN will be going away (except for one frustrating site that can't connect to the VPLS), and we will be routing via OSPF between all sites. So, Auto-VPN will handle connectivity via some sites, and OSPF for others, but regardless of the method, I can see how this will work.