Meraki

Aaron_Wilson · ‎Sep 11 2020

All is working fine with static route in place. Time now to see why the Z3 keeps freaking out. Thanks all!

Aaron_Wilson · ‎Sep 10 2020

I have made further progress today. I finally got things to connect after I switch my testing from a Z3 and MX67 to a MX67 and MX65. The Z3 was NOT happy with the VPN to the MX67 for who knows why. Either there was something wrong with the hardware or the auto vpn was getting seriously screwed up. Yea, I was hoping for layer 2 bridging, but I'd be OK with a single static entry. Here is what I have working so far: -Company A configured as hub using 192.168.10.0/24 for vlan and injecting into VPN -Company B configured as single arm spoke, has 192.168.1.70 from 192.168.1.0/24 range -Company A can ping Company B 192.168.1.70 over VPN -Company B can ping Company A VLAN IP 192.168.10.1 -Company A devices can ping Company B 192.168.1.70 As soon as I get Company B to enter a static route for 192.168.10.0/24 via 192.168.1.70 I think that will get things to work! *fingers crossed*

Aaron_Wilson · ‎Sep 9 2020

KRobert - Company B is spoke, in single arm mode. Regarding making a LAN port a L3 interface, how do you define the gateway/next hop? If I create a VLAN on the MX at Company B of 192.168.0.0/24 and give the MX an IP of 192.168.10.2, how do I tell it and Company A to use 192.168.10.1 (the actual Company B router) for everything? Karstenl - Maybe it is a NAT issue. The spoke works fine when in dual-arm mode, but flip to single-arm and it gets all kind of angry. To me it would seem weird that the VPN can establish in dual-arm mode but not establish in single arm mode. Also, my testing is with just the WAN port connected, I didn't move beyond that because of the lack of VPN connection. I can't place it in a DMZ because A) one may not exist and B) trying to make this as low config as possible. The desire was to just drop a single-arm Meraki into an office to bring in the tunnel. Then with just a static route on their network for return traffic (192.168.0.0/24 via MX LAN IP) the Company A location could access their entire 192.168.10.0/24 network. My goal is to not require separate internet or DMZ for the outside interface terminating the VPN. Trying to go with a cookie cutter method for unknown networks. It's a funky setup I know, but just trying out something new.

Aaron_Wilson · ‎Sep 9 2020

Stick with me on this one, it's an odd request..... Lets say I have two companies, A & B. A is 192.168.0.0/24 B is 192.168.10.0/24 Company A has a normal MX hub, nothing special. For arguments sake, dual-arm with public IP on WAN interface. Company A buys Company B (again argument sake, no legal concerns) and wants to access their network for whatever reason (again, this is all technical). I have been trying to lab this out but am failing. My thought was to slap a MX on Company B network in single arm mode. Company B MX would receive 192.168.10.10 IP address and access internet from existing local network connection. Company B adds static route of 192.168.0.0/24 via 192.168.10.10 Company A learns of 192.168.10.0/24 via VPN route table For the most part the Meraki gear seems to accept this configuration. The part which doesn't work is the AutoVPN between spoke and hub. It sees the peer but has red indicators showing it's not established. I know this is reverse of your typical deployment, but I am trying to work around the fact you cannot create a L3 interface on a MX of the local LAN.

Aaron_Wilson · ‎Aug 20 2020

An update, if anyone cares. Support is saying the VPN exclusion is meant to override the default route checkbox, but not routes learned via VPN. Which in my mind is pointless. If a certain route is learned from a hub, but you need to exclude that route at a branch so it goes via the NAT interface, that is what the option should (also) allow.

Aaron_Wilson · ‎Aug 3 2020

Has anyone tested this? It's not working for me. I have a spoke site with the default route box checked, so all traffic goes back to the main head-end. I also have a 0.0.0.0/0 route advertised from the hub to the spoke sites. I added ANY 1.1.1.1/32. If I try to ping from the spoke site Meraki (vlan, default, or internet) it does not work. Doing a trace from a device connected to the Meraki shows it's still following default route. Do we know if routes advertised from the main hub have a higher priority than the VPN exclusion? Now, if I use trace route on the Meraki this uses ONLY the WAN interface rule and bypasses all settings/rules/routes. Works just fine, but this is expected.

Aaron_Wilson · ‎Apr 27 2020

I guess someone wasn't happy with the behind the scenes view and/or association with the specific American only non-round ball league 😉

Aaron_Wilson · ‎Apr 25 2020

Nice! Though, all that money and tech and I see a table top projector....with serious keystone. Hilarious!

Aaron_Wilson · ‎Apr 12 2020

Nice!

Aaron_Wilson · ‎Apr 2 2020

At the remote site, you have the default route box unchecked on the VPN connection?

Aaron_Wilson · ‎Mar 31 2020

You'll notice Merkai support didn't mention the higher cost hardware and license 😉 FYI, my (10) Z3s finally shipped, just a slight delay.

Aaron_Wilson · ‎Mar 31 2020

Yup. Running hybrid auth on the Meraki port and pointing to ISE for radius auth.

Aaron_Wilson · ‎Mar 31 2020

@Khue- you will need to go to the 15.x train. It became stable for me after some more recent code versions, I'm on 15.27 right now.

Aaron_Wilson · ‎Mar 20 2020

Yea, MX64 will bite you in upfront and renewal costs. And no PoE port. When mine ship I'll let you know. They were a ETA of today.

Aaron_Wilson · ‎Mar 18 2020

Just placed an order for (10) Z3s. ETA is 3 days.

Aaron_Wilson · ‎Mar 18 2020

You could get the MX64W, but it's roughly 3x the price, with almost no value to the end-user for typical home work use. This is coming from someone who deployed a bunch of home MX units and was glad when the Z3 line was released.

Aaron_Wilson · ‎Mar 4 2020

Yup, easy as pie. We have our APs either use local Meraki DHCP or external DHCP, then radius is handled by separate external servers. The only real core requirement is for the tunnel to be up to hit the external servers.

Aaron_Wilson · ‎Feb 1 2020

If all on the MS, just set the ports to a unique vlan. No MX config required. Just make sure you add that new vlan to the trunks. I do this at hotels all the time. They never make L3 changes, just add some made up vlan to the ports I need and trunk it for me

Aaron_Wilson · ‎Jan 19 2020

Sounds like the non-Meraki device connected to the Meraki needs licensing. Not the Meraki switch.

Aaron_Wilson · ‎Jan 9 2020

Did you buy a 10 year license or something? 3.5 years left on some that was EOS in 2016 is a long time. Honestly, this is partly why it's better to go with shorter license durations than longer. We had a similar issue with a 5 year contract with Cisco and they released "free" features, but that was only for people on a newer contract. Had we done 3 tears we would have been able to leverage those features, at a lower cost!

Aaron_Wilson · ‎Jan 6 2020

If you do a HA pair, I believe you could have two ISPs on one MX, then a third on the backup MX.

Aaron_Wilson · ‎Jan 4 2020

So Microsoft a few months ago started advertising how they had just a couple summaries that covered their entire suite of O365, etc. It was a fairly large range, but I was calling Bullock's on it since there was little documentation on it and their articles with the smaller summaries were not updated. Now I can't find anything on those small summaries, so maybe they retracted it.

Aaron_Wilson · ‎Dec 2 2019

Sorry, but I have to... So what is the problem you are having? I'm not seeing the issue 😉 lol

Aaron_Wilson · ‎Nov 29 2019

Packet captures can be done on almost every device, if not all. I just checked some of my networks and everything had the option (Z3 included): security appliances, wireless, switches, cameras.

Aaron_Wilson · ‎Nov 28 2019

Can't do BGP with dual arm mode.

About Aaron_Wilson

Aaron_Wilson

Community Record

Badges