Spoke VPNs to have only specific VLANs visible to them

[PentagonSystems]

Hello,

I am not sure if this is a feature request, but the Meraki site-to-site VPN does not work the way i hoped it would.  My architecture is to have several MX appliances acting as hubs across geographic regions.  These hubs reside in our datacenters and I do want them to be able to communicate with each other with all VLANs that I configure.  However I have several MX appliances at remote office locations, which i am configuring as spokes.  These spoke MXs should only have access to one or two of the vlans that the hubs have.  There doesn't appear to be any way to restrict what vlans appear in a spoke vpn connection.  Currently I am restricting the traffic using deny policies on the firewall, but this doesn't seem clean to me, because the remote offices are getting routes added to their network that will be blocked.  I'd prefer the routes not be advertised to them at all.

here's an depiction of how i would like this to work:

1. hub 1.  vlans 1,2,3,4,5,6,7,8 in vpn

2. hub 2. vlans 1,2,3,4,5,6,7,8 in vpn (hub 1 and 2 can talk to each other on any vlan)

3. spoke 1. vlan 3 only in vpn

4. spoke 2. vlan 4 and 5 in vpn.

Easiest GUI implementation i can think of for this would be in the 'spoke' configuration page, i would be able to configure what vlans from the hubs I would accept.  perhaps a little better would be to have the vlan delegation on the hub page, perhaps with a text box next to the 'use vpn' toggle where you can choose the devices to share.  The latter would be better if someone wanted to give RO rights to an admin at that remote office.

I'll 'make a wish' with this request, but if someone could point out how i could already do this with the existing mx functionality i'd appreciate it greatly

[DCooper]

I’m not sure I completely follow the logic, however there are circumstances where you can’t restrict the tunnel but you can restrict the subnets via firewall rules. This is what I would recommend, using site to site firewall rules.

Would there be a reason this approach wouldn’t work?

[PentagonSystems]

yes, firewalls rules work as far as access restriction, but the issue there is that the routing table of the remote office has networks that are going to be inaccessible via the vpn. for example:

1.MX HUB has vlans 1 (192.168.1.0/24) and 2 (10.10.10.0/24) in vpn.

2. MX HUB has firewall rule restricting MX spoke network (192.168.2.1) from vlan 1 in vpn (192.168.1.0/24)

3.MX Spoke sees vlans 1 and 2 and adds them to routing table

4. Client wants to reach 192.168.1.10.  routing table directs him to the MX vpn, and then FW blocks him.

This works and is how i'm doing it today, however here is the problem:  suppose this remote office wants to use the 192.168.1.0/24 or a smaller subnet in that /24.  Without static routes they cannot.  It would be better if the MX HUB never told them that the 192.168.1.0/24 network is routable though it, rather than advertising that it is and then blocking them.

That's the functional problem, but there's also a little security problem.  Suppose i didn't want to give the users in the remote office any more information about the network than they need to know.  The implementation with all the vlans in vpn and firewall rules preventing it gives a remote office user the visibility of all the networks i'm using, which is going to include all of the other remote offices.  You might say 'who cares, the FW prevents them from accessing it anyway', but I'd rather not give a bad actor any information about my network unless absolutely necessary.

Does that make more sense now?  Let me know if not and i'll clarify further

[DCooper]

I am still not following. Maybe you could write up a detailed Visio? 

you lost me here:

MX HUB has firewall rule restricting MX spoke network (192.168.2.1) from vlan 1 in vpn (192.168.1.0/24)

 *we only enforce firewall rules on outbound/egress traffic. If your applying policy on a Hub formspoke traffic the rules don’t apply.

Are all firewalls in NAT mode? 

Is this split or full tunnel (is the default route button checked on the spoke)? 

When you say”in vpn” Are you referring to the yes no toggle button for that sites subnets? Keep in mind this is what adds the subnet to the “crypto map” so it is routable or not.

[PentagonSystems]

Hope this crude diagram helps.  the general idea is that i want office 1 to only see the routes for what applies to office 1, e.g. not the office 2 network or the network where office 2 servers at the data center reside.  with firewall rules i can prevent access, but their meraki are still seeing the prefixes that they should not have access to and therefore creating routes.  I don't want this to happen.

To answer your questions, I am using NAT transversal.  The spokes are operating in split tunnel mode. And yes when i refer to 'in vpn' i am referring to the yes/no toggle for if a subnet should be included in the site-to-site vpn.

[DavidB]

Please open a case with Meraki Support and explain the need to disable spoke-to-spoke auto VPN routing, as this is a feature which can only be disabled from the Support-end. I'd also recommend providing the topology diagram to make things more clear.

[DCooper]

@DavidB Did you miss the diagram above? This feature won’t work. Split tunnel mode is being used. Policy is the only method to restrict the requested setup.

[PentagonSystems]

Hi, did my diagram clarify any confusion?  do you have any suggestions, or if you understand my situation, could you please inquire with your engineering team on if this is a feature request or something that is possible with the current stable firmware?

[DCooper]

@PentagonSystems Want to make sure you got my last post that someone in support wasn’t happy with? 

[PentagonSystems]

@DCooper: Yes, I did get your suggestion and I do appreciate it.  Unfortunately I think for my specific case it's not the right feature, but I definitely can see that being the preferred behavior.  That should definitely be added in as an option checkbox. 

The reason it wont work for me because I may actually want to have two spokes be able to communicate with each other potentially, but that part is still irrelevant to the real issue, which is that any route that i enable in the vpn is seen by all spokes, hubs, or any member of the organization.  My issue isn't specifically that Spoke A can route to Spoke B, as much as Spoke A can see the resources that Hub A may want to provide only to Spoke B. 

Unless I have the ability to select what routes I share with each spoke individually, I have to do what I can to make the meraki organization a 'black box'.  I think architecturally i can hide these routes from everything in the office networks easily, and any routers they may have they will just have to create static routes for, and then use the firewall to block the access as you originally described.  Although I'd much prefer to be able to designate the vpn routes that each spoke should see, I can manage without this.