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.