Skip to content

Centralized Azure FW with Aviatrix

I’ve been asked recently about Aviatrix integration with Azure firewall as Firenet. Aviatrix Firenet as most of you probably know is a 3rd party service insertion in Transit. Currently Aviatrix supports the following firenet options:

  • Aviatrix itself
  • Palo Alto
  • Checkpoint
  • Fortigate


So definitely there is a choice of your own preference. For all who use Azure a lot, there is one big benefit of using Native Azure Firewall – Service TAGs.

Bummer … no Az FW support in transit yet.
However there is still hope 🙂

Lets do centralized Spoke egress with Az FW. 

General overview

What do we have here? With MCNA approach we have:

  • multi-cloud environment (here only 2 clouds: 1st spoke – AZ and 2nd in AWS)
  • Azure native Firewall in spoke 1
  • Internal Load Balancer (with backend pool of Aviatrix spoke 1 GWs)
  • dedicated UDRs in spoke1 

I had to use customized UDRs for both directions

1. Egress – spoke1_avx_udr
This UDR  sends all traffic exiting spoke GW to FW, I can’t just use 0/0 route as I would cut off my spoke completely. We still need to contact Controller (should have added Copilot as well) + transit GWs and both spokes need to talk to each other = Active Mesh.

2. Ingress – spoke1_fw_udr
This UDR is for return traffic. We need to point all RFC1918 to LB’s FEIP so it can go to both spokes. We want HA right? 


We could add a few more important routes there. My controller is located in AWS and to make peering work (between spoke and transit) –   “*”  is needed. Controller uses SQS for GW communication so we need to allow that, but instead of redirecting all of that to Internet lets allow it on FW.

Customize Spoke Advertised VPC CIDRs

We need to force all traffic from other spokes to go via our FW – let’s inject 0/0 route. To do that we will utilize this feature. Here is a brief summary what it does in new 6.6 code where BGP on spoke is supported.


First let’s see what public IP we have assigned to FW

For testing purpose rules are very simple.

  • allow DNS in network rules collection
  • allow SQS services + (testing) + – all in app rule collection
  • implicit deny
Key Learnings
  • we can utilize native Azure Firewall in a centralized way and extend that to other clouds with help of Aviatrix – real MCNA approach
  • we need to use spoke for that as Spoke GW can be deployed in an existing VNET where we can do manual UDR manipulation. 
  • for spoke-transit peering – AWS SQS service communication is needed as well (I learned that hard way as I couldn’t figure out why it is not coming up)
  • Customize Spoke Advertised VPC CIDRs” – we know we can inject routes from spokes into the whole MCNA infrastructure
Infrastructure as Code

This time everything was done with TF which I love about IaC. 

Leave a Reply

Your email address will not be published. Required fields are marked *