Understanding Transit Gateway Peering over the Internet with Insane Mode on GCP

Aviatrix Insane Mode over the internet builds high-performance encryption (HPE) tunnels over public IP addresses between two inter-cloud transit peering gateways (cloud network layer).

Aviatrix Insane Mode HPE over the internet throughput performance is dependent on the number of HPE tunnels that are configured.

Insane Mode over the internet for GCP transit gateway peering configuration differs from other CSPs because GCP Ethernet interface supports only one public IP address per VPC.

In this document I’ll explore how multi cloud transit network with insane mode over Internet with GCP works. The topology I’m going to use is shown in the diagram below:

Aviatrix version 6.7 or later is required for Transit Gateway Peering over the Internet with Insane Mode on GCP

FireNet Deployment

FireNet deployment is covered on the following blogs:




Transit Gateway Peering Configuration

Create the Transit GW Peering by navigating to Transit Network > Transit Peering > Add New. I’m peering an azure transit (az-eastus-transit) to a gcp transit (avx-us-central1-transit):

Because both Transit GWs were built with Insane the advanced options is displayed, allowing us to choose between private or internet with insane mode:

  • Peering over Private Network: This option only appears and applies to when the two Multi-Cloud Transit Gateways is each launched in Insane Mode and each is in a different cloud type.
  • Insane mode Encryption over Internet: This option only appears and applies to when the two Multi-Cloud Transit Gateways is each launched in Insane Mode. It peers transit gateways across the internet by using Aviatrix Insane Mode encryption tunneling.

By default, the gateways create 4 x tunnels. The supported range is 2 to 20 HPE tunnels for each transit gateway but depends on the instance size. Odd tunnel numbers are supported without penalty.

If number of tunnels need to be changed later, the peering would have to be detached first and then re-attached

Instance Size x Tunnels

The maximum number of tunnels supported between a GCP transit gw and another CSP is the number of tunnels supported by the other CSP transit gateway instance but caped to the maximum of 20 tunnels at this time.


  • 8 tunnels: Standard_D3_v2, Standard_DS3_v2
  • 32 tunnels: Standard_D4_v2: 32, Standard_D5_v2,Standard_DS4_v2, Standard_DS5_v2, Standard_D4_v3, Standard_D8_v3, Standard_D16_v3, Standard_D32_v3, Standard_D8s_v3, Standard_D16s_v3, Standard_D32s_v3, Standard_D8_v4, Standard_D16_v4, Standard_D32_v4, Standard_D8s_v4, Standard_D16s_v4, Standard_D32s_v4, Standard_F8, Standard_F8s_v2, Standard_F16s_v2, Standard_F16, Standard_F32s_v2
  • 48 tunnels: Standard_D48_v3,Standard_D64_v3, Standard_D48s_v3, Standard_D64s_v3, Standard_D48_v4, Standard_D64_v4, Standard_D48s_v4, Standard_D64s_v4, Standard_F48s_v2, Standard_F64s_v2, Standard_F72s_v2


  • 15 tunnels: n1-highcpu-4, n2-highcpu-4, c2-standard-4
  • 30 tunnels: n1-highcpu-8, n1-highcpu-16, n2-highcpu-8, highcpu-16,
  • 50 tunnels: n1-highcpu-32, n2-highcpu-32, c2-standard-30, c2-standard-60


Once the transit peering configuration finishes, we can check the status of the connection:

Azure gateway is a D64s v3 machine that supports up to 48 tunnels:

We can see the number of tunnels checking the GW routing table:

  • there are 20 tunnels between av-gw-az-eastus-transit and avx-us-central1-transit
  • Tunnels point to the same public ip ( that is associated to the NIC0 and private ip

Inspecting the gcp gw we have:

  • 20 tunnels but pointing to different public IP addresses, those are aliases (secondary) on eth0:
  • we can see 50 private ips were allocated but only 20 were associated to a PIP.

Resizing Gateways

I resized the Azure gateways to DS3_v2 machines:

If I try to peer using 20 tunnels as before I got an error message:

A DS3_v2 machine supports 8 tunnels:

Checking the gateway routing table we see 8 tunnels:




Leave a Reply