Non-Meraki Peer Site-To-Site VPN and default route and 'In VPN' route

[Termont]

Hello,

           I am looking for clarifications on how the routing operates within the Meraki in regards to site-to-site vpns. There seems to be a difference between how routing occurs for client vpn and StS VPN.

We have deployed tablets that use LTE connections through a private APN. Our APN provider links his network to our LAN through StS VPN. Internet is blocked within the APN, so no split tunneling, and all traffic is fully tunneled to our Meraki.

I am trying to obtain Internet access for my StS vpn clients, the tablets. 

This article, although not fully related to my questions, confirms within the first phrases that the client vpn of the Meraki establishes only full tunnels. This is confirmed by checking my public ip while connected through VPN from my laptop.

https://documentation.meraki.com/MX/Client_VPN/Configuring_Split_Tunnel_Client_VPN

So, full VPN and Internet access through my Meraki ergo, it uses the route 0 of the meraki to access the internet from my client vpn subnet.

This is not the behavior for the StS vpn. I do NOT get Internet.

How come the StS vpn client do not get access to the Internet by accessing route 0 from my firewall?

In order to circomvent this issue, we added a static route 0 through the admin panel Security / SD-WAN / Addressing & VLANs / Static Routes.

Once route 0.0.0.0/0 is Enabled and 'IN VPN' is checked, our StS vpn client now obtain Internet access.

This in fact duplicates the 0.0.0.0/0 route as can be seen in in the general routing table in Security / SD-WAN / Route Table.

There, 0.0.0.0/0 route shows subnet, name etc. and  via shows '2 routes', one using the WAN uplink and the other created manually using the next hop specified in the manual creation.

Now, here is the kicker, from the static route creation panel, we configured that route to be Active "While next hop responds to ping" and configuring a non responding IP thus, logically, rendering that route inactive. From what I was told by our provider, this does render the route inactive in the routing table but makes it visible to the StS vpn clients by just by checking the box 'In VPN'.

How does the routing occur to the real 0.0.0.0/0 route then? This article seems to answer the question.

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

Route Priority

"traffic destined for an address for which multiple routes exist will be routed in the order of priority above"

Overlapping Routes are routed by route priority it seems, thus giving access to route 0 to my site-to-site VPN, am I understanding this correctly?

Not only that, when enabling or disabling that route, our StS vpn client seem to lose communication with some of the VLANs they should have access to. It was suggested that we should down the StS ipsec tunnel and up it again to trigger the full sync of the routing configuration from meraki cloud to the appliance. Does this make sens?

So to recap the questions:

How come the StS vpn client do not get access to the Internet by default by accessing route 0 from my firewall?

Does Meraki Route priority explains why my static route 0 'In VPN' works?

How is my static route 0 working with StS vpn client if it is not meeting the active condition?

Would downing/upping the ipsec tunnel actually do anything and if yes, is there an enable/disable feature or do I actually need to delete the tunnel and recreate it to obtain the desired effect?

Thank you all for your answers.

[Termont]

Shoot. One last thing.

What as precedence or how are the two linked:

the 'In VPN' feature when creating a static route and the VPN Settings found under Security / SD-WAN / Site-To-Site VPN.

There, you can configure yes/no for 'Use VPN' under local networks.

Isn't that kinda redundant?

[PhilipDAth]

I can understand why your provider has it provisioned that way, but that is not a normal use case for the MX.  I'm surprised you got it working at all.  Typically site to site VPNs are only used to access local VLANs in the Meraki MX world, and not remote networks (like the Internet).

When I have done this previously I have used a little Cisco router (like a 1111-4P) and terminated the APN VPN on that.

https://www.cisco.com/c/en/us/products/collateral/routers/1000-series-integrated-services-routers-is...

You would then add a default route on that pointing to your MX and a route for your APN on the MX pointing to the router.

Another option would be to use a second MX (it would have to be in a different network), and terminate the APN VPN on that, and have its default route pointing to your primary MX, and your primary MX would have a route for the APN pointing back to it.

You could also consider asking the provider to connect the APN to the Internet and use something like Cisco Umbrella on the mobile devices to provide the protection.  Then a lot of the complexity dissappears.

This document talks about routing behaviour.  It only partially covers your case.

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

[Termont]

Thank you very much PhilipDAth, I will look into Cisco Umbrella for sure.

Once we provide our clients with Internet, we definitely do need some ACL and content-filtering to be applied. Right now, we are exploring the old school route with squid/e2guardian.

I understand what you are suggesting. We actually do have another similar setup to what you are suggesting with another provider for redundancy. With the other provider however, we use GRE over Ipsec and the GRE endpoint is actually on another appliance, a Cisco 4321. The GRE tunnel points to another IPsec tunnel on our Meraki but, everything coming out on the 4321 that is destined to the Internet does so by using the default route to our Meraki and then the Internet. Quite a more efficient setup. The 4321 is actually in a DMZ vlan that is solely used to create tunnels. This has the benefit of being able to apply content-filtering directly on the Meraki as it can only be applied to vlans it seems and not directly to the traffic coming out of the IPsec tunnel.

Nonetheless, for our primary uplink to our APN with the first provider, we are stuck with the current configuration. As a matter of curiosity and knowledge of the product, I am still pursuing answers in regards to our problematic setup.

Thank you for your answer,

Have a nice day!

[Coupe2112]

I've got a similar situation to this but am landing the non-Meraki vpn tunnel on an MX that has an additional non-Meraki tunnel as well as about 40 auto-vpn tunnels.  I only want the full tunnel on the new non-Meraki tunnel and am wondering how, in particular, the auto-vpns will act if I add a static default route and add it to the vpn.  Will the prefer their local default route (what I'd want) or the learned?  It seems logical to me that the local default route would be preferred over one learned via vpn.

I'm planning on doing a test tomorrow.  I'll update with my results.

[Coupe2112]

This morning I created a new vlan on the hub MX for one of it's two WAN connections then created a static default route and added it to the VPN routing table.

The hub MX seemed fine and I was still able to ping the gateway address of the network in question via the non-Meraki vpn I'm trying to run as full tunnel. I had no way to test from a client given that I was remote from that network during the test.

When I checked the routing table of a Meraki vpn peer, I saw both it's local default route as well as the injected statically created default route from the hub MX. Question, when I look at the new route table view, are the routes listed in order of priority? I saw them both and the vpn learned route was listed above the local default route.

When I did a traceroute from the remote site's MX to the internet (from it's 'internet' port) it went directly out the local internet connection (meaning it did not use the vpn tunnel). However, devices downstream from the MX (i.e. the switch) lost connection to the Meraki cloud and a traceroute from a client device at a Meraki vpn site to the internet failed at it's network gateway address. Meaning once the traffic hit the MX it died, I suspect because it was trying to route via the hub MX and failing.  As soon as I removed the hub MX static default route everything returned to normal.

I did not troubleshoot the switch (and downstream device) routing failure because it isn't really what I wanted. I expect I could add static default routes (excluded from the vpn) on each remote MX but that's an undesirable answer.

I think it boils down to the less than full ability to weight and manipulate routes as you would have in a full function network device due to the nature of the cloud managed solution.

I still have a couple of alternatives for my particular use case but not having this ability is disappointing.