vMX in Azure behind a FW

Solved
Chema-Spain
Getting noticed

vMX in Azure behind a FW

Hi, 

 

My only experience with vMX in Azure was a single vMX without defining AvZones (so basic public IP for the vMX). vMX is a also a FW and customer accepted to connect it directly to the internet.

 

Now I need to deploy an HA Pair in Azure and in this case my customer wants to sit it behind a vPalo_Alto cluster. They also want to deploy each vMX in a different AvZone in the Az Region.

 

I'm aware that by specifying AvZone in vMX deployment automatically makes them to use AZ Standard Public IPs instead of basic ones. From a previous Philip Dath's post I also know standard would make HA from primary vMX to the secondary one to need more convergence time in case primary one fails. 

 

My doubt is: 

 

Provided I deploy the vMX instances (they could share a single Meraki SDWAN subnet or run two SDWAN subnets) the vMXs would try to register into Meraki cloud directly (using Az internet access). Both vMX would send all their traffic towards reserved AZ IP for sdwan subnet DGw. How could I get they both to send their underlay traffic thru the PA cluster? Meraki AZ vMX deployment guide says RT are not needed for sdwan subnets, they could lead to packet loss. 

 

Or do you recommend sitting the fw behind the vMXs? At the end of the day the vMX FW function already protect themshelves. PA FW will serve as Client VPN access and would protect all Az resources but the vMXs.

 

Thanks for your help.

1 Accepted Solution
PhilipDAth
Kind of a big deal
Kind of a big deal

I would configure a port forward on the PA for each VMX, and statically configure that on the AutoVPN page.

 

Also check out this guide.  I have followed it a couple of times.  It has some serious errors in it, and is challenging to get going.
https://documentation.meraki.com/MX/Other_Topics/Deploying_Highly_Available_vMX_in_Azure 

 

Next time I have to do it, I am going to try this BGP approach instead.

https://documentation.meraki.com/MX/Deployment_Guides/vMX_and_Azure_Route_Server 

View solution in original post

4 Replies 4
PhilipDAth
Kind of a big deal
Kind of a big deal

I would configure a port forward on the PA for each VMX, and statically configure that on the AutoVPN page.

 

Also check out this guide.  I have followed it a couple of times.  It has some serious errors in it, and is challenging to get going.
https://documentation.meraki.com/MX/Other_Topics/Deploying_Highly_Available_vMX_in_Azure 

 

Next time I have to do it, I am going to try this BGP approach instead.

https://documentation.meraki.com/MX/Deployment_Guides/vMX_and_Azure_Route_Server 

Fletch
Meraki Employee
Meraki Employee

+1 on the Azure Route Server approach. Using Azure functions to adjust UDRs relies on successfully probing the primary vMX, it only fails-over if the probes fail. The probes are looking at the underlying VM state and an open-port test.

 

BGP IMO is a far better indicator of whether your primary vMX is functioning.

 

-- Fletch

Chema-Spain
Getting noticed

Thanks you both for your quick responses.

 

Totally agree with you dynamic routing using AZ Route Server would be much better than using Azure Functions. Unfortunately when I suggest using RS it was not accepted even when I pointed out the limitations with AZ Functions, posible false positives, etc.

Chema-Spain
Getting noticed

Thanks!

 

By configuring manual Port FWD for our vMX I believe we'll solve the issue with standard public IPs in Azure regarding vMX HA. Good Point.

 

Agree with you regarding Meraki's guide for HA. First picture shows a dedicated vnet for each vMX and second picture shows a common vnet for all resources... great!

 

I'll try changing the design to include the RS. I come from networking area so I'm highly more confortable with BGP instead of AZ Functions 🙂 

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels