Meraki

DurgaPrasad_DP · ‎Jul 19 2023

Hi, Did you have in place as suggested by Pugmeister - 1. A route table in VNET 2 pointing to the LAN IP of the vMX in VNET 1? Azure takes care of getting traffic between the VNET's but the route table gets traffic to anything outside Azure 2. Did you add the VNET 2 subnet as a local subnet on the vMX in addition to your Layer 8 issue 🙂 ? Thanks/DP

PhilipDAth · ‎Feb 28 2022

You could deploy the Umbrella virtual appliances on-premise if you would like to keep the same functionality. But it doesn't sound like you really have an issue. You can just use Umbrella for enforcement and tracking of the users, rather than the MX.

Mohit_Chauhan · ‎Feb 1 2022

Few clarifcations on your point Phil, 1. are you suggesting we can use the same existing subnet where servers are hosted so when when the vMX comes up online, it will pick up one of the ip range from the same pool? In my case, I have only one /24 subnet available in the server vnet beside the server subnet. However, I am planing to use that for the VPN users, will this be OK? 2. The other alternative was, can I use /25 as the subnet for the vMX. So far when I have tried its giving me "conflict error" on Azure in building up the VM for this vMX. I have logged a case with Azure on that and waiting for the feedback. Thanks in advance. Mo

Pugmiester · ‎Feb 25 2021

Hi all, just to confirm if anyone runs across this question in the future. Yes, you can switch the Auto-VPN to using BGP without having to immediately configure any external BGP peers. The Auto-VPN reconfigures itself and although Meraki support suggested there may be some outage time while that happened, with our 25 site mesh we didn't even drop a packet as far as I could tell.

Vittoriusly · ‎Nov 16 2020

I would like to implement something like that. I found this AWS document https://aws.amazon.com/blogs/apn/exploring-architectures-with-cisco-sd-wan-and-aws-transit-gateway/ Maybe it could be usefull. Best.

Pugmiester · ‎Jul 8 2020

One option you could look at, is using a secondary MX at your hub site (Main-MX location) to manage the ASA VPN link. That way, you can add a static route onto the Main-MX pointing to the VPN MX and that will allow you to publish the remote ASA subnets into SD-WAN. There's a great example walk through of this by Aaron Willette https://www.willette.works/merging-meraki-vpns/ We use this approach to bring in a couple of third party locations that need to reach services on site but are not part of our Meraki deployment.

Pugmiester · ‎Jun 16 2020

I thought I would add one final update for anyone stumbling across this post in the future. There's a Meraki support document for the SD-WAN that clearly lists the ports needed for connections to both the dashboard and Auto-VPN peers. Somehow, all of my Googling never brought me to this page so I'm including the details plus the link below for future reference. Ports used to contact the VPN registry: Source UDP port range 32768-61000 Destination UDP port 9350 Ports used for IPsec tunneling: Source UDP port range 32768-61000 Destination UDP port range 32768-61000 https://documentation.meraki.com/MX/Site-to-site_VPN/Meraki_Auto_VPN

GeorgeFrendl · ‎Apr 22 2020

Nice!

Pugmiester · ‎Apr 9 2020

Ironically, the setup we did in Azure to test came up almost straight away. Untangling the right options and getting things in the right NSG to start with is more of a challenge there and as you can't change the vMX appliance once it's deployed it meant we had to tear it down and rebuild it again but once we had that done it was up and running.

BlakeRichardson · ‎Nov 18 2019

@Pugmiester we run exactly what you are wanting multiple MX on the same ISP subnet with different LANS.

PhilipDAth · ‎Nov 11 2019

The built int "whitelist" policy can also be applied to a client to bypass all restrictions.

RJordan-CCS · ‎Oct 23 2019

Done. The magnet sculpture would look smashing next to my collection of hard drive magnets...

Hussam-Bay · ‎Jul 12 2019

Also you can't configure IPSec vpn between two MX if the WAN ports have private IPs. The MX will not negotiate IPSec unless the port has internet connection, the port status will show failure until it gets internet connection. Hence, if you have two sites connected via MPLS then you can't have VPN between them since the WAN ports don't have internet connection.

MeredithW · ‎Jun 3 2019

Congratulations to our contest winners, @Franzman and @nbentsendk!👏👏👏🎉

Cmiller · ‎Apr 17 2019

correct

MeredithW · ‎Mar 7 2019

In recent community housekeeping efforts, we are started this new board for introductions.

MerakiDave · ‎Feb 6 2019

Agree with previous posts, you're in the Meraki green, no worries! Just wanted to add one thought. We have had customers with small stacks of 3 or 4 pieces of equipment like that right on top of one another, but NOT in an air-conditioned or even well ventilated room. For US$8 they purchased a USB flexible fan stick and plugged it into the USB port of the MX64, and coiled/pointed it to pass air between the equipment. Worked great, and the before/after was a difference of over 30 degrees F.

Pugmiester · ‎Nov 13 2018

We're on shard n145 but everything seems to be back to normal. We've not had issues previously, I think this is the first issue with dashboard access in the last couple of years.

Pugmiester · ‎Oct 31 2018

Hi @jdsilva Thanks for the pointer. I hadn't realised the best practice guide had been updated. I've stripped out the HA dedicated patch cable and together with dual connections from each MX to each switch, everything is looking rock solid. I think we have a winner.

Pugmiester · ‎Jul 6 2018

Thanks jdsilva, that was where I was heading. It's been a long week. 😞 Last night we rolled back to our old firewalls and disconnected the MX's completely from the LAN to be certain we could regain a stable connection for work being completed remotely over the weekend. Not 10 minutes after I finished, one of the links dropped again proving that the MX's have noting to do with the problem. I never believed they did but it was the only change I'd made. I've a solution in place for now using the interface IP addresses in place of the HSRP ones so we're stable but lacking failover. The business is happy with stable for now. I'll close off this question though as we're now 100% certain it's not Meraki related. Thanks everyone for your help pointing me in the right direction.

Meraki

Community

About Pugmiester

Pugmiester

Community Record

Badges

Re: Azure Vmx peering

Re: Meraki MX Firewall with FQDN

Re: vMX and Azure VNET peering

Re: Activating BGP without configuring a peer yet

Re: Meraki integration with AWS Tranist Gateway

Re: Non-Meraki VPN network reachability

Re: AWS vMX has lost all site-to-site VPN link

Re: Revealing the Meraki Community All-Stars!

Re: Cannot get a vMX alive in AWS

Re: Multiple MX's in different networks but the same organisation on the sa...

Re: Bypass URL filtering for a single client IP address

Re: Time for a survey — and another chance to snag swag!

Re: MX Limitation

Re: [CONTEST CLOSED] Wi-Fi 6: tell us your hopes and dreams!

Re: Enabling multi factor authentication after admins are created

Re: Please introduce yourself

Re: Standing MS and MX hardware on top of each other

Re: Dashboard Page Unavailable

Re: Hot standby MX64 LAN side failure not working as expected

Re: New MX firewalls seem to be affecting other routers on the LAN

Re: Azure Vmx peering

Re: Activating BGP without configuring a peer yet

Re: AWS vMX has lost all site-to-site VPN link

Re: Dashboard Page Unavailable

Re: Hot standby MX64 LAN side failure not working as expected

Re: New MX firewalls seem to be affecting other routers on the LAN

Re: Azure Vmx peering

Re: Non-Meraki VPN network reachability

Re: AWS vMX has lost all site-to-site VPN link

Re: Revealing the Meraki Community All-Stars!

Re: Activating BGP without configuring a peer yet