After 100% success rate on installs, hit first road block

[IT_Magician]

After 100% success rate with Cisco Meraki installations, we have hit our first ever road block where Meraki isn’t working. It is a unique situation, and am really hoping someone here can provide some insight.

Here is the setup:

1. We are required to have a VPN tunnel with HQ.
2. HQ only allows a single VPN tunnel, it is their corporate policy, no exceptions.
3. We have no control/say/access over this network, but it is critical to the business.
4. We have two locations, both 100% Cisco Meraki stack (MX67 with M S120 switches)

Here is the issue:

1. We have the VPN tunnel between HQ and Site 1, works 100% no issue.
2. We have a Meraki Auto VPN between Site 1 and Site 2, works 100% no issue.
3. Site 2 needs to go across the VPN to Site 1, and then across the VPN tunnel to HQ. This is our issue.

Here are the things I have tried:

1. Setting a static route on site 2, Meraki doesn't allow this.
2. Settings site 2 as a spoke, with default route to site 1.
3. Called support, they said Meraki doesn't support this type of configuration.

Does anyone have a clever way to get around this? If we need to purchase more equipment or whatever it takes we will do it.

[GreenMan]

If Site 1 and Site 2 need to talk to each other, just use HQ as a Hub, serving sites 1 and 2 as Spokes - then traffic between Sites 1 and 2 will trombone via the Hub.   Why the need for direct tunnel between sites 1 and 2?

[ww]

@GreenMan i dont think the hq is meraki.  Or at least he is not managing it . And for some reason  only  1 vpn  tunnel is allowed. 

[GreenMan]

OK, that would do it...   Sounds like the approach of 'one tunnel only' is possibly short-sighted, to me...

[GIdenJoe]

And the documentation states that MX'es will not route traffic coming from AutoVPN to IPsec VPN and vice versa.

[IT_Magician]

It is short sided on both sides, but we are just happy to win the contract and have to play by their rules. Why does Meraki not make this possible? It is simply a routing table, why does it care? I'm sure Meraki didn't go out of their way and has a reason this is not possible.

We are going to purchase another firewall and make that the upstream WAN device and see if we can trick the Meraki. My hope is since Meraki will use it as the WAN anyway, once it its the upstream firewall it will be smart enough to route the traffic as needed.

[GIdenJoe]

True, there are alot and I mean ALOT of little playrules you have to follow for whatever reason to get something to work.

In your case you'll probably need a an extra router/firewall at one of the sites and static route from your MX device to that router and then make that route available through autovpn to the other MX site.

[PhilipDAth]

>Site 2 needs to go across the VPN to Site 1, and then across the VPN tunnel to HQ. This is our issue.

Non-Meraki VPN traffic is not allowed to traverse AutoVPN.

However, with some creativity, it can still be done.  You'll need an extra MX in its own network, not part of AutoVPN.  It should be plugged into the same LAN as an existing AutoVPN hub.

Build the site to site VPN to this additional standalone MX.  Create a static route pointing to your AutoVPN hub for all your remote subnets.

On your AutoVPN hub create a static route pointing to the standalone MX for the remote VPN subnet.  Redistribute this static route into AutoVPN.

[IT_Magician]

Awesome, thank you so much for the suggestion. I want to clarify, when you say AutoVPN hub, you just mean the MX?

[PhilipDAth]

I mean the MX which has AutoVPN enabled and is configured as the hub.

[IT_Magician]

Hi Phillip,

Thanks for your suggestions, the new MX came in and I am starting the configuration. I do have a question, can you double check this strategy is correct:

1. WAN 1 goes into New MX

2. I will build VPN tunnel on new MX to HQ

This is the part want to make sure I don't mess up....

On new MX I created 192.168.100.0/24 network, MX IP is 192.168.100.1. I will assign that to a port, and then that port will become the internet uplink of my existing MX? If that is the case, where do I program the static route? On the existing MX?

[GIdenJoe]

Hmm, normally it's better to have them next to each other and share the LAN subnet.
If you can spare another public IP, Put that IPsec VPN terminating MX on the public internet.

This article by Aaron Wilette has a great example:
https://www.willette.works/merging-meraki-vpns/

[IT_Magician]

I am going to read this article you sent. I got it 100% working, but then 24 hours later we have an issue. DNS traffic will not route! No idea why, but if I remove the second MX which is handling our non-meraki VPN peers from the local LAN where the primary auto-vpn MX lives, the problem goes away.

Meraki support believes we have a traffic leak somewhere - wanted to see if anyone had any insight?

When I say DNS traffic can't pass, Google DNS, Cloud Flare, OpenDNS all fail to resolve DNS. I can ping 1.1.1.1 but no DNS traffic will work on either WAN 1 or WAN 2.

[IT_Magician]

Ok 100% confirmed this is what is happening:

• We have auto-vpn MX
• We have a second non-meraki VPN MX
• The moment we plug the non-meraki VPN mx either directly into MX, or directly into Meraki switch, we get about 90% dropped DNS traffic. This is same result on WAN 1 or WAN 2.
• From Meraki dashboard it can pass traffic, but something is getting messed up once the second MX is plugged into the same LAN as the primary non-meraki MX.

Any thoughts?

[IT_Magician]

Long story short, when the second MX is on the same LAN nothing works. Meraki has suggested we put all locations in their own organization. If that doesn't work I am out of ideas and will have to get a different unit. Very frustrated right now with all of this.

[PhilipDAth]

The second MX needs to be in its own network.

For non-Meraki site to site VPNs you want a public IP on the MX.  Assuming that you only have a single static public IP address:

• Configure Meraki connected to the Internet circuit directly for the non-Meraki site to site VPNs.  This MX should not be part of Auto VPN.  Create static routes for your remote AutoVPN spokes to point to the MX below.
• Configure the MX behind it to be in an in VPN concentrator mode (so it only uses a single interface).  Create a static route for the non-Meraki site to site VPN on the above MX to go via that MX.  Redistribute this static route into AutoVPN.

[PhilipDAth]

>Meraki has suggested we put all locations in their own organization.

Use one org, but separate networks.

[GIdenJoe]

Allright, how about a recap of what is essential.

So your two original MX'es need to be in the main Meraki Dashboard org so they can do autoVPN where one is a Hub and the other can be a spoke pointing to the Hub.  If you want local internet traffic breakout (do not enable default route checkbox on the spoke).

The other MX has to be in a completely separate Dashboard org because you'll otherwise include that MX in AutoVPN and you cannot have the same subnets behind two different NAT mode MX'es unless they are an HA pair.

Example:
Imagine the following addressing:
IPsec remote LAN subnet: 10.0.1.0/24

Hub site internet subnet: 198.51.0.0/24, upstream router .1, MX AutoVPN hub .101, MX IPsec VPN .201
Hub site client LAN: 10.1.1.0/24
Hub site transit between AutoVPN Hub MX and IPsec VPN MX 10.1.255.0/30 where AutoVPN Hub is .1 and IPsec VPN is .2

AutoVPN spoke site client LAN: 10.2.1.0/24

The AutoVPN spoke is the easiest to configure: just have the local VLAN with subnet: 10.2.1.0/24 included in autoVPN and make sure you connect to the Hub site MX as a spoke.

The AutoVPN hub has the two VLANs defined 10.1.1.0/24 and 10.1.255.0/24 and you need to add a static route towards 10.0.1.0/24 via 10.1.255.2.  The local VLAN 10.1.1.0/24 and the static route to 10.0.1.0/24 must be included as the local AutoVPN subnets.

The IPsec VPN has a single local VLAN with subnet 10.1.255.0/24 with itself as .2 and needs static routes towards 10.1.1.0/24 and 10.2.1.0/24 via 10.1.255.1.  You will need to put that MX as a Hub and include the static routes as local VPN subnets and then create that org wide's IPsec config towards the remote site where the remote subnet is 10.0.1.0/24.

Then you should be golden.  You'll have to make sure not to mix IP's between the orgs.  You could of course use the supernets 10.1.0.0/16 and 10.2.0.0/16 instead of the /24's as long as there are no overlaps because that is where you could get weird behavior.