There are times when we need to build connectivity between Aviatrix Transit and Azure VPN Gateways. I’ve created a terraform module for a quick lab demonstrate how this can be done.

• Aviatrix Transit Gateways establish two IPSec tunnels with Azure VPN Gateway, both tunnels are active and Equal Cost Multi-Path (ECMP).
• Aviatrix Spoke CIDR will be propagate to bottom right Spoke vNet, via the BGP/IPSec tunnels between VNG and Aviatrix Transit.
• Spoke vNet and vNG vNet CIDR gets propagated to Aviatrix Transit via the IPSec tunnels with VNG
• Spoke vNet peering with VNG vNet while specifying use remote virtual network’s gateway
• VNG vNet peering with Spoke vNet while specifying use this virtual network’s gateway

Note: Both Express Route Gateway and VPN Gateway can be called VNET Gateway (VNG), this interchange of terms sometimes may cause confusion. When communicating, please make sure clarify VNG refer to either Express Route Gateway (ERGW) or VPN Gateway (VPNGW). In this article, VNG refer to Azure VPN Gateway.

Azure Portal – Configuration Details

VPN Gateway Config

• Active – active selected
• BGP Enabled
• ASN assigned
• Custom Azure APIPA BGP IP Address (equals to Aviatrix Tunnel IPs) configured for both IP Configurations

Local Network Gateways

• Local network gateways as similar to AWS Customer Gateway, it tells Azure what remote gateway’s public IP, ASN number, and Tunnel IP are. However, each local network gateway can only point to a single tunnel IP.

• For Aviatrix Transit Primary Gateway and HA Gateway, I’ve created one local gateway for each, note the BGP peer IP is in the same /30 range as the ones on VPN Gateway. Also note that I’m using 169.254.21.* and 169.254.22.* in following examples.

Connections

• Connections defines the IPSec tunnels with Aviatrix Transit Gateways
• Enable BGP and use IKE V2
• Modified IPSec / IKE policy to match Aviatrix default settings
• Set connections to be responder only, as Aviatrix Transit Gateways are protected by Network Security Group, won’t accept incoming IKE/IPSec by default

vNet Peering

Spoke vNet to VNG vNet

Use the remote virtual network’s gateway or Route Server is selected

VNG vNet to Spoke vNet

Use this virtual network’s gateway or Router Server is selected

Effective Route

test VM in VNG vNet

Note it learned Aviatrix Spoke CIDR and point to VNG’s two IPs

test VM in Spoke vNet

Note it also learned Aviatrix Spoke CIDR and point to VNG’s two IPs

Aviatrix – Configuration Detail

Multi-Cloud Transit -> External Device

Topology view

Aviatrix sees everything it manages up to the Site to Cloud connection to the VNG

From Aviatrix Spoke Gateway, run trace route to the test VM in spoke vNet peered with VNG vNet

CoPilot -> Cloud Routes

Site 2 Cloud

BGP Info

Note it learned CIDR from VNG vNet, also learned CIDR from the spoke vNet peered with VNG vNet, when spoke vNet specify to use remote network’s gateway

Note Aviatrix transit advertise it’s attached spoke routes to VNG

---

Note: Why are we building only two tunnels? According to Microsoft article, it’s possible to build full mesh with remote gateways. However, when building BGP over IPSec tunnels, from Aviatrix’s point of view:

If you have followed my previous post: Aviatrix Site to Cloud Connection demystified, in option 3, when building a full mesh IPSec connections, you will need to select Enable Remote Gateway HA, and use /30 for tunnel IPs. Azure VPN Gateway requires 169.254.21.* and 169.254.22.*

Local Tunnel IP: 169.254.21.2/30,169.254.21.6/30
Remote Tunnel IP: 169.254.21.1/30, 169.254.21.5/30
Local Tunnel IP (Backup): 169.254.21.10/30,169.254.21.14/30
Remote Tunnel IP (Backup): 169.254.21.9/30, 169.254.21.13/30

From Azure VPN Gateway’s prospective, it uses Local Network Gateway build connection. If we follow the same IP Schema:

You can see that only these two groups of IPs can form neighbours:

169.254.21.1/30 and 169.254.21.2/30
169.254.21.13/30 and 169.254.21.14/30

Since we can only form two BGP peers, it would make sense to create only two tunnels instead.