Hub-Spoke Quickie

[Str8Outta127001]

Hey hey -

New to the community but long-time Meraki fan. Quick and easy question regarding hub and spoke.

Let's say I have 5 branch sites and 1 HQ site. Some branches have MXs while others are third party until I get around to converting them. HQ is an MX. All 5 branch sites use the same local subnet template. HQ uses a different and unique subnet.

If I want all 5 branches to talk to HQ, but not with each other, hub-spoke is the way to go, right? With the hub being HQ of course. Additionally, when using hub-spoke, will I need to call Meraki to enable VPN Translation?

(I'm unsure if I need VPN translation if the hub and the spoke have different subnets - but each spoke has the same subnet.)

Any other apparent issues with this config? Thanks!

[amabt]

If I understand it correctly.

1. Each site has the exact same subnet

2. You only want site to talk to the Hub. But not talk to each other.

3. Some site will not have MX util a later date.

For (1) You are going to have issues. Best get through the pain now and resubnet the sites to unique subnets.

For (2) Meraki Auto VPN will take care of the VPN (that what you are paying for). Then simply have Firewall rules to allow / deny traffic as needed.

For (3) If the 3rd party devices can do IPSec then you can do an IPsec tunnel from those sites to Meraki. Then replace them with MerakiVPN when they get an MX.

[Str8Outta127001]

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?

[alemabrahao]

Why do you have the same subnet configured on the spokes?

[Str8Outta127001]

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.

[alemabrahao]

I believe other community members will agree with me, but if I were you I would avoid this setup.

In the future you will never know a new need that may arise, and I would also avoid working with NAT for the simple fact that it facilitates future troubleshooting.

What do you think about this @PhilipDAth ?

[PhilipDAth · Accepted solution]

I agree @alemabrahao , I would give all the sites unique addresses.  Note that you can still use a template and do this, and you can still use DHCP.  In the template, select the option to use "unique" addresses.

https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_... 

[cmr]

@Str8Outta127001 I would definitely avoid having all spoke sites with the same subnet and also avoid 192.168.1.0/24 as if you ever have homeworkers this is likely to be their local IP.

The templating should be able to assign a unique subnet per templated site.  Are you planning on having a lot of sites?  I ask as templating has limitations that could be avoided if you only have 5 remote sites.  Personally I'd say anything less than 10-15 remote sites are easier to configure separately.

[Str8Outta127001]

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.

[amabt]

Confuses with your comment on you are not supposed to do certain things?? If you are the guy that need to make this work. Then you do what needs to be done. If you have someone more senior then they should be doing this work.

We have the same setup to allow our spoke sites to access central resources and practically no site to site comms.

Everyone has mentioned all the points I was going to say. I'll just add a couple of things / rephrase some things if it may help with your understanding.

Best to assign a supernet IP range (example 10.123.0.0/16)  that you add to your template. Then set the template to auto generate unique IP address range per site (on creating new site and binding it to the template).

To keep thing simple, maybe best that you "clone" your current template.To do this make a dummy network out of current template. Then create a a new template by cloning off this dummy network. Now you have a new template based on the old template.

After that make the changes like adding the supernet to this new template etc. That way you don't disrupt your live site operation (still using the old template) while you live change the template settings. Make sure to set the unique address as per previous reply by @PhilipDAth 

Re template limitations: If you can strictly stick to what the template can provide and let you change. It it a huge time saver. If down the track you find that tempalte is not cutting it (can't make certain changes). You can unbind a network from the template and it will keep all the settings it has at the point. Then change setting as required as now template restriciton no longer apply.

Also, you can create and bind a new site to a template, to grab the initial config (like let it assing a unique ip range) then imediately unbind it from the template.

Then migrate each site, aka move Meraki devices into newly created network (using the new template) during your outage window.

Once you do the above. Then you will be in a much better position. This should have been done on the get go when those site were put on Meraki.

Edit: Fix spellings!

[Str8Outta127001]

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.

[cmr]

@Str8Outta127001 please remember that we are all end users (in my case) or consultants (in the case of @PhilipDAth at least) and not Cisco employees.  In terms of hub-spoke it isn't necessarily a bad idea and in fact we use a mix of mesh (where sites need to communicate with each other) and spokes for the sites where they don't.  For instance our venues are all in a mesh, but our homeworkers are on spokes as they have Z3s which are much less capable.

Regarding the translation, I always follow the adage of keeping it simple.  If you imagine a packet traversing a VPN that is simply routed and equate that with, for example, 5 processing cyles, then a NATed packet would take many more, perhaps an equivalent of 20.  This means for each conversation going over the VPN tunnel, there will be a significantly higher processing overhead.  You could compensate for this by installing larger MXs, but it is still more prone to failure than having directly routable address ranges.

[Str8Outta127001]

Thank you! I appreciate that explanation!