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?
>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.
If you really need to heavily control what does and doesn't connect to your network, I'm another vote for 802.1x.
>.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.
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.
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?
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
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.
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."