I am having a strange issue here where an MX appliance at a (all our) remote site sends traffic that should be routed to the WAN over the VPN.
Clients cannot reach hosts from 172.217.* (which are hosts from Google). I even cannot ping those hosts from the appliance. After some reverse engineering, I've found out, that the MX is routing this traffic into the VPN to our main site instead of routing it over the local WAN uplink at the remote site.
This is the setup:
From my point of view, this is a bug, because of the routing table, the traffic should be routed to the WAN. Or am I overlooking something?
Solved! Go to solution.
OK, just to inform you and without further explanation here is what I had to do to fix the issue.
Simply changing the mask to /12 did not work. And beware of this if you think it will work in your case: Doing so will reassign new random subnets to your bound networks!!!
Quite a lot of work, but the API did the trick 🙂
AND, of course: Create a copy of your template first. Test, if you are using a script!
Could you share a screenshot from your routing table on the branch and the vpn config on that same site?
The routing table looks like below.
I've cutted off most of the other remote sites, because there are about ~100 more of them.
There's only one default route?
Because if you configure default route via S2S VPN you should see a second entry 0.0.0.0/0 Meraki VPN: VLAN.
Only in that case should the traffic be sent through the tunnel towards unknown destinations.
And you haven't found any other summary route where the google routes fall under?
@GIdenJoe wrote:
Because if you configure default route via S2S VPN you should see a second entry 0.0.0.0/0 Meraki VPN: VLAN.
Only in that case should the traffic be sent through the tunnel towards unknown destinations.
Yes, there is only this one default route and there is also absolutely no other summary route that catches the 172.217.x.x-addresses.
..and that's why I am wondering about the MX sending the traffic into the VPN - because based on the routing table it should definitely NOT do that...
Yes, the box is unchecked in the template for all remote sites...
I've opened a case with Meraki and it seems, that this behaviour is caused by this "Addressing- and VLANs"-setting in the template for our remote sites:
Obviously, AutoVPN thinks, everything in 172.0.0.0/8 should be routed via VPN because the local subnets (which are only /24) are out of 172.0.0.0/8
If so, I think this is very, very, VERY dumb logic!
Ah I see, I didn't know the templates would have effect on that.
However I do see an error in your own part in your last screenshot.
You are actually taking the entire 172.0.0.0/8 space as "private" space to carve out. While alot of that space is public, as the issue you are experiencing.
You should only include 172.16.0.0/12 in that template space.
I agree that they are using this "optimization" by violating standard routing rules (longest match).
I guess someone thought it would be a great idea to aggregate all possible VPN routes when using templates for Branches. And yes you wouldn't have noticed any problem if you originally used the /12.
But the fact is that even when optimizing, never ever violate standards because sooner or later you will have cases like this one exactly.
Just here to bang the "follow the standards" drum too. Using the most specific path is so standard that I would not, frankly, ever expect to see a supernet given priority.
Not even a special supernet like the one used for templates.
The 172.0.0.0/8 prefix is wrong. It should be 172.16.0.0/12.
Nope PhilipDAth, it's 172.16.0.0/12 😉 But I already informed him of that and he realizes it.
OK, just to inform you and without further explanation here is what I had to do to fix the issue.
Simply changing the mask to /12 did not work. And beware of this if you think it will work in your case: Doing so will reassign new random subnets to your bound networks!!!
Quite a lot of work, but the API did the trick 🙂
AND, of course: Create a copy of your template first. Test, if you are using a script!