How do you prevent rogue Meraki devices?

[Aaron_Wilson]

We are primarily a Cisco shop using MPLS for our locations, but we use some Meraki for non-MPLS locations where we need to bring the location into our network over a standard internet connection. Primarily most of these locations have a just a security appliance with no other Meraki gear behind them (small office or teleworker), and the security appliance has general internet access via the landlord or home owner.

For our MPLS locations (non-Meraki), all of their internet traffic goes back to a data center firewall (non-Meraki) for firewall inspection, and we do not allow ANY:ANY to reach the Meraki cloud (among many other destinations). This helps prevent rogue actors from bringing their own VPN devices (Meraki or otherwise) into the location and connecting a VPN tunnel outward.

I'm curious, for those who have Meraki devices behind your MX, how do prevent unwanted/rogue Meraki devices from gaining internet access, while allowing your own Meraki switches/APs/etc to access the internet?

I ask because if you do tunnel all on the remote MX, and then have the hub MX send all traffic to your core routers/firewalls for egress, then it would seem like there is not a good way to allow certain Meraki devices to reach the cloud without overly complex IP rules/mgmt.

The MX's will always use the WAN interface for direct internet access for Meraki cloud mgmt, which is great. The problem is everything behind the MX does not have this privilege. Do you have to create a non-VPN vlan on the remote MX, then tell the switch/AP to use that VLAN? Do non-VPN subnets egress the MX via the WAN interface?

[PhilipDAth]

>I'm curious, for those who have Meraki devices behind your MX, how do prevent unwanted/rogue Meraki devices from gaining internet access, while allowing your own Meraki switches/APs/etc to access the internet?

A lot of my clients have their users in a different VLAN.  If it bothered you a lot you could flip this and create an old style management VLAN for the Meraki devices.

BUT, my more security sensitive clients use 802.1x.  You can't simply plug a random device into the network.  It sounds like you should be considering doing this as well.

[Nash]

If you really need to heavily control what does and doesn't connect to your network, I'm another vote for 802.1x.

[Aaron_Wilson]

.1x isn't supported on every MX, so that blows that idea out of the water.

I just played around with a mgmt non-VPN vlan and setting the switch to use that vlan. It does break out the mgmt traffic to egress locally non-tunnel, so I guess that is a work around until Meraki gets something in place.

So no one is doing anything else fancy? They allow "any" to access the Meraki cloud across the board?

[PhilipDAth]

>.1x isn't supported on every MX, so that blows that idea out of the water.

Of the security conscious clients I have using 802.1x - none of them do it on the MX.  They all buy a Meraki switch to plug into the MX and do it there.

You could also consider using the additional security features like Dynamic ARP inspection as well then.

Back to 802.1x.  One of the reasons we use this at more security conscious clients is because it is the best way to identify who is connected to your network.  Lets say you have a breach.  You track it back to an account.  Having 802.1x lets you track it back further to the actual port on your network that was used, and frequently the machine because of that.

Some of my clients get audits - and the auditors specifically check that the customer is able to identify every device that is connected to their network.  802.1x is an instant tick.

[Aaron_Wilson]

I fully understand the importance of .1x, but this thread isn't about NAC. I was just curious what others have done to for edge sites to egress the mgmt traffic locally rather than going back to the hub.

[PhilipDAth]

Of all the ones I have done so far - we've replicated the security policy on the MX, and have not used full tunnel.  We implement the meraki firewall rules under "Help/Firewall Info" to allow the internal Meraki devices to connect out.

Yes, it does mean someone else could bring in another Meraki device and plug it in.

[jdsilva]

I'm another vote for solving this problem with .1x. 

[Aaron_Wilson]

Ok, i definitely phrased the question wrong. I'm not trying to prevent rogue devices.

When a hub DC blocks non-proxy traffic to the cloud, and a remote edge MX is the only device which can do WAN egress for cloud MGMT when in tunnel all mode, I was wondering what were the options.

I have confirmed a non-vpn mgmt vlan won't work. It does allow the Meraki devices to egress locally for cloud mgmt, but it breaks all radius. I guess I am waiting for split tunnel in future firmware.

[cmr]

If you have an SD-WAN setup with an mx concentrator at the DC with an edge device at the remote site, also set up as a hub, then only the networks advertised from the concentrator will route over the vpn.  Internet access will be local.

Or am I missing the question?

[Aaron_Wilson]

I'm running tunnel all, so all internet goes to data center. From there internet traffic is routed through global firewalls in the data center (0.0.0.0/0 points to firewalls). The only internet traffic which remains local at edge site is MX Meraki cloud traffic, because the MX always uses WAN interface for cloud mgmt, never the tunnel.

[cmr]

So, do you want to tunnel all but not tunnel other Meraki's that aren't yours?

[Aaron_Wilson]

Tunnel all, except Meraki cloud mgmt traffic 🙂

[cmr]

Can't you just block outbound traffic to the Meraki DC subnets on the remote MXs?  I think the MX itself would still be able to talk

[Aaron_Wilson]

Here is a basic drawing. The blue line from the MS is what I am most curious about. The desire is to not send this traffic to the DC/firewalls/VPN, but direct to internet.

[PhilipDAth]

Check out the 15.3 change log.

"Added firmware support for VPN exclusions, a new feature that allows the configuration of L3 rules for routing traffic to the local Internet uplink instead of toward the hub MX in the case where default points to the hub MX. This is available for closed beta testing only; it will not be a part of the MX 15 release and it is currently not being actively supported."

[Aaron_Wilson]

Oh, I didn't go that far back in the logs to see that!

I have actually been chatting with support, hoping to test this out.