Meraki

Aaron_Wilson · ‎Sep 9 2019

If it's detecting objects being used in a threatening manner I would also want to see a video showing something other than a gun. Going one step further, if the scripts could detect *any object*, then the reality is we don't need to detect the object but the behavior itself since the object (assuming there is one) is not of importance.

Aaron_Wilson · ‎Sep 6 2019

Tunnel all, except Meraki cloud mgmt traffic 🙂

Aaron_Wilson · ‎Sep 6 2019

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.

Aaron_Wilson · ‎Sep 6 2019

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.

Aaron_Wilson · ‎Sep 6 2019

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.

Aaron_Wilson · ‎Sep 6 2019

.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?

Aaron_Wilson · ‎Sep 6 2019

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?

Aaron_Wilson · ‎Sep 5 2019

A good reason to have more than one org admin and a read-only admin as well. All should be tied to company owned email addresses.

Aaron_Wilson · ‎Aug 24 2019

MX68W has wired ports too 😉

Aaron_Wilson · ‎Aug 23 2019

Was that a MX68 or 68W?

Aaron_Wilson · ‎Aug 12 2019

Just a heads up. I tested port security on my MX68W and it was horrible. Countless errors in the dashboard and the MX rebooted every couple hours. Had to roll back to 14.x to make it "normal" again.

Aaron_Wilson · ‎Aug 7 2019

My coworker has the same issue. Just 8.8.8.8, but the catch is his VPN tunnel is also unstable. 1.1.1.1 and other IPs do not have the same loss/latency, but the VPN is extremely unstable.

Aaron_Wilson · ‎Aug 2 2019

I agree, the MX100s are WAY too loud. I had bought a set for a portable rig and regretted it. What's funny is the MX400 isn't anywhere near as loud. When I was setting up the MX100s in my basement, I could hear them on the second floor!

Aaron_Wilson · ‎Aug 2 2019

@FoozGrind - based on the above, I think you should setup your Z1/Z3's with RADIUS hybrid auth. This would mean all the ports require some form of RADIUS auth. Hybrid would allow you to do .1x for users/machines and then MAB for phones. I have this enabled on all my "home" based Merakis, which means if anyone's account is disabled it breaks wireless and wired. There would be a delay on the phone side as phone accounts required CUCM sync to disable the accounts. I will warn you that getting hybrid auth to work with ISE was a bear, so FYI in case you are an ISE shop.

Aaron_Wilson · ‎Aug 2 2019

Setting up radius auth on the ports would certainly help. It would not disable the Meraki, just the devices tied to the user. The catch is, if you enable MAB as well for radius (which you would need for phones, etc) those devices would remain active.

Aaron_Wilson · ‎Aug 2 2019

What Fooz is asking for, how to tie the Z1/3 to a user so that if that person identity record is disabled then their Meraki is disabled as well. This is certainly a gap I dont think Meraki has a solution for. There is nothing in the networks which ties a device to a person record, so there is no way to automate the deactivation of a Meraki. It would be sweet if you could add a ldap account to a Z1/3 network where it only allows the tunnel to connect if the ldap account is active. The check could occur on the hub side during the AutoVPN phase.

Aaron_Wilson · ‎Jul 31 2019

Verizon now supports the MX68?

Aaron_Wilson · ‎Jul 30 2019

@PhilipDAth wrote: Any chance the MX is in passthrough mode (rather than NAT mode) and bridging the WAN to the LAN, and their is another router/CPE behind it? https://documentation.meraki.com/MX/Networks_and_Routing/Passthrough_Mode_on_the_MX_Security_Appliance_and_Z-series_Teleworker_Gateway I second this. Have them send a screenshot showing the NAT/passthrough config.

Aaron_Wilson · ‎Jul 21 2019

Understood, but thats not the question at hand. Also, it's not just printers, the printer was just a simplistic example. The ask really is how to tunnel all traffic except specific subnets which should go WAN uplink, the exact same feature the Cisco AnyConnect client can do. Meraki defaults to WAN uplink if tunnel all is disabled and nothing in the route table matches, so how do you accomplish this when tunnel all is enabled or a larger supernet route exists (ignoring the specific use cases)?

Aaron_Wilson · ‎Jul 21 2019

They are plugged into the home network, hence the issue when enabling default route for the Z3 🙂

Aaron_Wilson · ‎Jul 21 2019

The NAT exception option? If so, I couldn't quite figure it out.

Aaron_Wilson · ‎Jul 20 2019

Scenario is Z3 at home (10.10.0.0), plugged into home router (192.168.1.1/24). AutoVPN has default route enabled so all traffic is tunneled back to data center for proper inspection/internet egress. Is there a way to add the 192.168.1.1/24 route to a tunnel exception so home personal printers may be used from the Meraki subnet (10.10.0.0)? Essentially, a static route with next hop being WAN uplink. If you remove default route for the Z3 VPN to the DC hub it works perfect with home printer, but then *all* internet traffic egresses locally from home ISP, not via the DC. As soon as you enable default route on the VPN all internet traffic goes to the DC and you lose home printing.

Aaron_Wilson · ‎Jul 16 2019

I'm curious how you have .1x auth on a MX68. My MX68W does not have .1x/MAB auth on the ports, neither in 14.x or 15.x firmware....

Aaron_Wilson · ‎Jul 13 2019

Major feature gap in my opinion. Not sure why.....

Aaron_Wilson · ‎Jul 12 2019

MX68 is sort of a MX65 replacement, still missing features like port security.

About Aaron_Wilson

Aaron_Wilson

Community Record

Badges