Finish our conversion to Meraki. 11-ish of 30 sites complete in 2024, now it's time to finish the rest! And, of course, it's a huge goal to win some free Meraki glasses. ... View more

Thank you! I appreciate that explanation! ... View more

Not sure what you mean in your first statement about "not supposed to do things"? I don't see anywhere that I typed I am not supposed to do certain things, or wouldn't do "what needs to be done"? Maybe a miscommunication?   But anyway... thanks for your feedback. I have read the documentation that @PhilipDAth posted along with a lot of other documentation and I think I understand better now.   I have opted to create a supernet and have DHCP issue smaller useable subnets using unique assignment. I was sure to include a large enough supernet that it can create plenty of subnets for all my networks, per the documentation.   I think I have sorted out how it will work and will opt for the Meraki auto-vpn in a HUB mesh configuration rather than hub and spoke, and then as recommended, use firewall rules to block comms between networks. I am still lacking some understanding on why a hub-spoke model is a "bad" idea. Nobody in their responses went into detail about why using identical subnets at spoke sites with VPN translation enabled wouldn't work, or even work well. Nobody elaborated on what, if any, problems might come up because of it, or what deficiencies might arise from a network built in that fashion. Nevertheless, after reading more about auto-VPN, meshed HUB, etc. I really like the idea and will go that route.   Thanks to everybody who chimed in. ... View more

Thanks @cmr    The 192.168.1.0/24 is just an example. All of the data in this thread is by way of example, including the 5 branch sites.   I actually have 26 branch sites, and we are adding more. Each of which vary in size by wide margins. Some sites will have as few as 100 nodes and some as many as 1,000 nodes. If the best and recommended approach is to build a single IP scheme and then uniquely subnet each site, I can definitely look at doing that. I am not opposed to it. Unfortunately, nobody has explained why that is the best approach and I think I am looking for some clarity. Can you help explain the potential issues with the hub-spoke model I outlined?   For context, our sole purpose for site-to-site VPN is so each branch can reach a couple cloud hosted resources, and a couple resources at HQ. The branches have no need to speak to each other, and for compliance, should not be able to do so under any circumstances. Knowing this, does redoing the IP configuration for the entire network make the most sense - and if so, why?   Thanks for bringing me along and trying to help me understand. ... View more

Thank you for your response!   1) Correct - each site has the same local subnet. This is due in part to keep sites uniform, but also the MX sites have a template with DHCP configured. So each site is getting the same DHCP settings. I have two questions on this. A) If I widen the subnet to make all sites unique, do I need to take the DHCP settings out of my template and configure it a different way? B) You mentioned that I will have issues. Can you elaborate on what that means? Which issues might I expect to see? 2) For clarity, you are suggesting that instead of isolating subnets through spokes, I should use auto-vpn to create a mesh and then simply put firewall rules in place to block access between sites?   3) Definitely the plan for the non-MXs. They can do IPSec tunnels no problem and I am sure I will keep them that way until I can get them on an MX. That said, if I have two sites using this configuration, and each site has an identical subnet behind it, do you know if I need to submit a ticket to Merkai to enable VPN translation for me? ... View more

Thanks for asking this. I have built an MX template that I assign to my branch sites in order to keep the configuration uniform. In that template, I have built VLANs and have configured DHCP. So each branch site with the template gets the same DHCP settings as other branch sites. This has never been an issue because branch sites don't ever talk with each other. Ideally, I would like to keep this configuration and simply have each branch site talk back to HQ with a site-to-site IPSEC tunnel. If HQ acts as a hub, and each branch site is a spoke, I thought I could achieve that. Is that incorrect? And is this a poor way of doing site-to-site VPN?   Crude example: Branch site 1 - MX: 192.168.1.0/24 - Configure as a spoke Branch site 2 - MX: 192.168.1.0/24 - Configure as a spoke Branch site 3 - Not Meraki: 192.168.1.0/24 - Configure as a "spoke" - really just an IPSEC tunnel? HQ: 10.10.10.0/24 - Configure as a hub. Have Meraki enable VPN translation so that the hub knows which branch site to communicate back with since all branch sites share an identical subnet. ... View more