MX VPN with non meraki peer overlapping subnets

[leadtheway]

so not sure what I can do here.  Basically this is the setup.  Have an asa at corp site, with a bunch of asa's at other sites and just now using MX at a few new sites.  Network is like this each site has 3 networks, one for data, voice and wireless...data goes 10.0.site number.0   voice  172.17.site number.0  wireless is whatever.  so in this example two sites

10.0.60.0/24

172.17.60.0/24

10.0.70.0/24

172.17.70.0/24

both advertised in vpn, but the remote subnet of the meraki peer have private subnets being written as summarized.  so 

10.0.0.0/15

172.17.0.0/16

when i try to save the config on the MX i get this:

The changes you requested require confirmation. Please review the following list

• The VLAN subnet 172.17.70.0/24 overlaps with a remote VPN subnet on the non-Meraki peer Corp00 (172.17.0.0/16). IP traffic will be routed to the smallest subnet that contains the IP address.
• The subnet on the non-Meraki peer Corp (172.17.0.0/16) overlaps with a subnet on the network 60 LOC - appliance (172.17.60.0/24). IP traffic will be routed to the smallest subnet that contains the IP address.

it won't save but  I can still ping across.  Is there a way to do this so that the voice can talk to what it needs to?

[MarcP]

Yeah, I have this message always, when setting up a new device for Site-To-Site-VPN or changing something on a existing.

I get this message for each network in the organization.

While setting this up last year, the MerakiSE said, this is normal and ok.

So I always confirm it, it never made any problem. Its just a summary.

In my case it is regarding to the "non meraki vpn peer" and the configued private subnet 0.0.0.0/0 As this is in all networks configured.

[BrechtSchamp]

It shouldn't stop you from saving the configuration I think. You need to "Confirm changes" though.

Basically it's telling you two things:

• That the MX is smart enough to route traffic destined for its own subnet (172.17.70.0/24) to itself and traffic destined for the rest out to the tunnel.
• That some of the subnets (e.g. 172.17.60.0/24) in the autoVPN also overlap with the summarized subnet. It will route the traffic to those via autoVPN because the autoVPN subnets are smaller than the summarized subnet from the 3d party tunnel.

[leadtheway]

yeah I confirm it as well, but the save changes button is always active and not grayed out indicating something needs saved

[PhilipDAth]

I would adopt a different approach.

Put an MX at HQ in VPN concentrator mode behind the ASA.  Terminate your MX spokes onto this using AutoVPN.  Then just use simple static routing between the ASA and the MX at HQ.

Your life will be much simpler if you do this.