What is Aviatrix CloudWAN?

Problem Statement

Enterprises are moving their data centers, workload, applications and even branches into the public cloud. They do not want to own and manage the physical infrastructure anymore.

The ground reality is that Enterprises have also invested millions of $$$ in the Branch, Access routers and entire WAN ecosystem.

  • These branch routers are deployed in Banks, ATM machines, retail store floor etc.
  • These branches could be deployed within a country, continent or across the globe.
  • In some cases they are owned by the enterprise and in other by partners or managed services providers.

The adoption of Cloud might not happen overnight for these enterprises. In the mean-time, these branches do need secure and efficient connectivity to the Cloud.

So how do we solve this challenge?

If you talk to device vendors, most likely they will push you to use one of the followings

1- SD-WAN (if they have one) solution or
2- Just create an IPSec tunnles to public cloud

Both of these have their own issues and problems. Let us examine them


  • Requires re-architecting your entire WAN
  • In almost all the cases, it requires you to purchase new hardware for all the branches
  • Usually the new SD-WAN hardware does not integrate or work with the existing branch hardware
  • So effectively you will be running two different WAN architectures in your enterprise for a long period of time
  • You are now talking about new compliance and audit approval for your entire WAN architecture
  • Come up with a new governance model
  • Train pretty much everyone who touches WAN or any WAN device
    • Although these SD-WAN vendors claim that it is zero-touch, reality is that it is not, when it comes to troubleshooting and debugging issues in the branch
  • Requires new operations model with new tools, associates learning curve and integration challenges
  • You might not want to keep physical presences in the long run. You might want to move majority of the branches in the Cloud, but SD-WAN kind of forces you to use another hardware device on-prem
  • And you know how painful and lengthy process it is 🙂

SD-WAN is not the answer to this challenge at least

IPSec Tunnel to Public Cloud

Another solution they will offer you to create an IPSec Tunnel to Public Cloud. This sounds simple but it is not. Let us examine it

  • Creating a simple IPSec tunnel is painful and require deep CLI and IPSec knowledge
  • If it is managed by partner or MSP, then it is another people, process cost discussion
  • For 5 to 10 branches, may be it ok to create IPSec Tunnels but what about for 100 and thousands of branches
  • These routers do not have any REST API or Terraform knowledge, so it is extremely hard to even automate the entire process
  • Lets assume that someone wrote the script for that, but then what about life-cycle management of routers and support-ability of scripted solution?
  • Connection to Cloud is beyond just creating a simple IPSec tunnel
    • You need BGP to exchange routes
    • Provide transit connection to other VPCs/vNETs
    • Provide secure connectivity to workload
    • Also maintain QoS and performance because what if a branch in Singapore trying to connect to workload in San Francisco VPC or in Virginia? The IPSec latency will just kill the application and it will be extremely bad use-experience. That could result in customer satisfaction issues and potentially revenue loss

Creating just an IPSec Tunnel is not the answer to this challenge either

Aviatrix CloudWAN Solution

In order to solve the challenges I described above, Aviatrix has launched a new solution called CloudWAN for Cisco Routers in Branch, Campus and other Access locations. The solution leverage the Aviatrix centralized management plane, Aviatrix Global Transit or AWS-TGW with native integration with AWS global accelerator.

Following are the highlights and advantages of Aviatrix CloudWAN solution

  • Manage and control Cisco routers in the branches from a centralized management (Aviatrix Controller) point, deployed in the public cloud of your choice (AWS, Azure, GCP etc.)
  • On-ramp branch routers without any rip and replace (investment $$$ protection)
  • Securely connect Cisco routers to public Cloud without any manual intervention or CLI interaction
    • Aviatrix provides simple, point-and-click UI workflow as well as REST API options
  • Manage life-cycle (config. changes, config diff, audit, etc.) of Cisco routers directly from public Cloud
  • Integrated with AWS Global Accelerator to provide optimal latency and QoS by routing traffic to AWS global backbone instead of hopping across multiple public ISPs
    • Branches get connected to the Cloud from the closest AWS point of presence using Anycast IP and attached to Aviatrix global transit to seamlessly reach any cloud provider in any region.
    • Branches can also reach enterprise data centers via direct connect or equivalent
  • Supports BGP to dynamically propagate routes from Cloud to branch locations and vice versa
  • Provide service insertion framework
    • For example when branches traffic is entering or leaving the Cloud, it can be inspected by Next Generation Firewall (such as Palo Alto Networks) for deeper packet inspection
  • Provides connectivity to multiple clouds by using Aviatrix Global Transit solution

Deployment Model Examples

The Aviatrix solution is extremely flexible and there could be many deployment models and design patterns available to enterprises based on their needs. Following shows just few examples of how an enterprise might deploy this CloudWAN solution with and without AWS Global Accelerator

Aviatrix CloudWAN without AWS Global Accelerator

This is the deployment model an organization could use if branches are in one region and there is no need for optimal latency path to Cloud.

In the example shown in the following diagram, access from branches will add extra latency because those physical branches will have to traverse multiple ISPs (internet hops with no QoS or SLA).

Aviatrix CloudWAN with AWS Global Accelerator

This is the best deployment model that allows optimal latency path from branch to Cloud. This is the model that is recommended for enterprises having presence in different AWS regions.

Here AWS Global Accelerator provides anycast IP (two by default for redundancy reasons). The branch connects to the closed AWS-Edge location (CloudFront POP) and then the traffic rides back onto the AWS expense backbone to reach to the destination.


Hammad Alam for contributing to this post.

GCP Transit Networking and Routing with Aviatrix

Aviatrix Transit Network in GCP is a powerful use-case for customers looking to design consistent transit architecture in GCP and in other clouds. This is neede to build a unified and consistent network forming the cloud core essentially.

This design also allows business to have full visibility into the traffic beyond what Cloud primitive options can provide.

GCP Transit Network Topology

We will be using a simple hub and spoke transit topology as depicted below. This topology can be extended to hundreds of VPCs and across multiple clouds without any compromises.

Create GCP VPCs Directly from Aviatrix Controller UI

This is very powerful deploy directly from the Aviatrix Controller UI. There is no need to learn different Cloud constructs as Aviatrix can speak all the “Cloud” languages.

Following example shows the output when all necessary VPCs were created to build the transit topology we showcased earlier.

Create GCP Transit Gateway from AVX-Ctrl UI

NOTE: AVX-Ctrl –> Aviatrix Controller

Create GCP Spoke Aviatrix Gateway-1

Create GCP Spoke Aviatrix Gateway-2

Following is the output when AVX-GW is created

GCP Transit (Hub) and Spoke GWs Deployed

At this point you have your HUB and Spoke GW deployed

Attach GCP Hub to Spoke-VPC1 and VPC2

Attachment Process

AVX-Ctrl creates the IPSec Tunnels / Firewall rules etc. to attach Spoke-VPC to Transit-VPC as shown below

Aviatrix Encrypted Peering Section

Encrypted Peering section will also show the following outcome

GCP Transit Networking Is Deployed Now

Testing GCP Transit

We deployed two test VMs in Spoke VPCs as follows

Test VM Properties

Enable GCP “OS Login” Feature to Login to VMs


OS Login allows you to use Compute Engine IAM roles to manage SSH access to Linux instances and is an alternative to manually managing instance access by adding and removing SSH keys in metadata.

To configure OS Login and connect to your instances, use the following process:

  1. Enable the OS Login feature on your project or on individual instances.
  2. Grant the necessary IAM roles to yourself, your project members, or your organization members.
  3. Optionally, complete any of the following steps:
    1. Set up two-factor authentication.
    2. Add custom SSH keys to user accounts for yourself, your project member, or organization members. Alternatively, Compute Engine can automatically generate these keys for you when you connect to instances.
    3. Modify user accounts using the Directory API.
    4. Grant instance access to users outside of your organization.
  4. Connect to instances.
  5. Review the expected login behaviors.

Install important Tools on both GCP VMs


# sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

Enable Aviatrix Connected Transit Feature

This feature allows VPCs to talk to each other. By default VPCs can only talk to Transit VPC. This is meant for SaaS based apps or for Service Providers for VPC isolation.

Testing Successful

At this point it is all good and working.

Aviatrix Multi-Cloud Oracle Cloud (OCI) Transit Network Setup with GCP

In the previous blog post, we performed the initial OCI on-boarding and Transit VPC setup. Here we will build Multi-Cloud transit network connecting OCI and GCP together. The GCP multi-cloud transit network is already built using the Aviatrix Controller. This is the common cloud architecture that Aviatrix provide across all major Clouds such as AWS, Azure, GCP and OCI. This common cloud architecture provide consistent operational tools and visibility into different Cloud Networks.

Business Requirement to Consume Services from GCP and OCI

A customer has already deployed production workload in GCP to utilize GCP’s ML/AI/Analytics services. A new business requirement emerged to consume database service offered in Oracle (OCI) Cloud.

From the network architecture point of view, this business requirement can easily be fulfilled by building an Aviatrix based transit architecture in OCI; the same transit network architecture that was built in GCP. Eventually these two Cloud architectures will be connected together using Aviatrix encrypted peering.

Multi-Cloud Common Architecture in GCP and OCI
Multi-Cloud Common Architecture in GCP and OCI

Aviatrix Transit Gateway in OCI Transit VCN

As first step, we logged into the controller and launched the workflow to deploy the Aviatrix Transit VCN Gateway (OCI calls VPC as VCN: Virtual Cloud Network). The VCNs were build in the previous blog.

Notice the ease of deploying it in the region of your choice with the instance size that your business require. Also notice that Public Subnet was automatically created by Aviatrix and one does not need to worry about creating it from scratch.

Launch Aviatrix Gateway (AVX-Transit-GW) in OCI VCN
Launch Aviatrix Gateway (AVX-Transit-GW) in OCI VCN

Once you hit create button, the Aviatrix Controller will communicate with the OCI and will deploy the Aviatrix Gateway. Following output shows the process of creating this transit gateway.

Aviatrix Controller Deploying Transit Gateway in OCI

[21:42:57] Starting to create OCI GW OCI-Transit-GW-Ashburn.
[21:42:58] Connected to Oracle OCI.
[21:42:58] Deploying virtual machine…
[21:44:32] Deploy virtual machine done.
[21:44:32] Configure virtual machine.
[21:44:33] License check is complete.
[21:44:33] Added GW info to Database.
[21:44:35] OCI-Transit-GW-Ashburn AVX SQS Queue created.
[21:44:35] Create message queue done.
[21:44:35] Initializing GW…..
[21:45:06] Copy configuration to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy new software to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy /etc/cloudx/cloudx_code_file.json.enc to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy /etc/cloudx/cloudx_code_key_file.txt to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy scripts to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy sdk to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Copy libraries to GW OCI-Transit-GW-Ashburn done.
[21:45:06] Installing software ….
[21:45:06] Issuing certificates….
[21:45:06] Issue certificates done
[21:45:15] GW software started.
[21:45:29] Software Installation done.

You can now login to OCI console and notice the Aviatrix Transit GW instance deployed in the Finance Compartment or Department.

Aviatrix Transit Gateway Deployed in OCI
Aviatrix Transit Gateway Deployed in OCI

Following output shows the instance detail and other information directly gathered from the OCI console.

Instance Information
Availability Domain: RGRl:US-ASHBURN-AD-2
Image: Published Image: aviatrix_gateway_0415_1017_20190820
Fault Domain: FAULT-DOMAIN-2
OCID: …dsmska ShowCopy
Region: iad
Launched: Thu, 17 Oct 2019 04:43:00 UTC
Shape: VM.Standard2.2
Compartment: shahzadali (root)/Finance-Compartment
Virtual Cloud Network: OCI-Transit-VCN-Ashburn
Launch Mode: NATIVE
Maintenance Reboot: –
Primary VNIC Information
Private IP Address:
Internal FQDN: av-gw-oci-transit-gw-ashburn…ShowCopy
Public IP Address:
Subnet: OCI-Transit-VCN-Ashburn-public-subnet
Network Security Groups: aviatrix-security-group This instance’s traffic is controlled by its firewall rules in addition to the associated Subnet’s security lists and the VNIC’s network security groups. Launch Options
NIC Attachment Type: VFIO
Firmware: UEFI_64

Aviatrix Transit Gateway Instance Details in OCI
Aviatrix Transit Gateway Instance Details in OCI

Important point we would like to highlight that in order to get all that information, one does not really need to login to OCI console. All this information is also available from the Aviatrix Controller UI itself. This is great operational benefit because now operators don’t need to worry about learning different clouds and their constructs.

Aviatrix Spoke VCN Deployment in OCI

At this point the OCI Transit GW is deployed. The next step is to create an OCI VCN and then deploy Spoke GW inside the Spoke-VCN.

Once again Aviatrix Controller is used to deploy these constructs. Following screen shot shows the VCN (shown as VPC) creation in the region of your choice with the CIDR that you planned for this VCN.

Aviatrix Spoke Gateway Deployment in OCI

After the Spoke-VCN was created, simplified controller UI is used to deploy the Aviatrix Spoke GW as shown in the screen shot below.

Following output from Aviatrix Controller shows the process of deploying the Aviatrix Spoke GW inside the Spoke-VCN

[21:58:12] Starting to create OCI GW OCI-Spoke-GW1-Ashburn.
[21:58:12] Connected to Oracle OCI.
[21:58:12] Deploying virtual machine…
[21:59:46] Deploy virtual machine done.
[21:59:46] Configure virtual machine.
[21:59:47] License check is complete.
[21:59:47] Added GW info to Database.
[21:59:49] OCI-Spoke-GW1-Ashburn AVX SQS Queue created.
[21:59:49] Create message queue done.
[21:59:49] Initializing GW…..
[22:00:20] Copy configuration to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy new software to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy /etc/cloudx/cloudx_code_file.json.enc to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy /etc/cloudx/cloudx_code_key_file.txt to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy scripts to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy sdk to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Copy libraries to GW OCI-Spoke-GW1-Ashburn done.
[22:00:20] Installing software ….
[22:00:21] Issuing certificates….
[22:00:21] Issue certificates done
[22:00:28] GW software started.
[22:00:42] Software Installation done.

Enable Aviatrix ActiveMesh For Aviatrix OCI Transit and Spoke Gateways

It is best practice to enable Aviatrix ActiveMesh on the Transit and Spoke Gateway. ActiveMesh greatly enhances the availability and performance of the Network inside the Cloud.

Go to Gateway section in the Aviatrix Controller (AVX-CTRL) to enable it.

AVX-CTRL –> Gateway –> Enable ActiveMesh Mode Info

Attach AVX-Spoke GW to AVX-Transit GW

At this point the Aviatrix Transit and Spoke GWs are deployed in this respective VCNs. Here we will attach the Spoke GW to Transit GW. This step will build an encrypted tunnel between these two gateway. It is extremly simple and one click operations without operators worrying about knowing the source/dest IP, IPSec protocols or IKE details. All of this is automatically done by the Aviatrix Controller with just a single click.

OCI Transit VCN and Transit GW Routing Tables

One of the great advantages of using Aviatrix is that one does not need to login to OCI, AWS or GCP Cloud Consoles to gather this information. The Aviatrix Controller will also provide the relevant information that greatly improves the day2 operations.

Following screen shots show the routing tables from VCNs and inside the Aviatrix Transit and Spoke Gateways.

OCI Transit Gatewyay showing state is up and connected to OCI-Spoke GW. Notice the ActiveMesh HA mode which shows that all the Transit and Spoke GWs are running in Active/Active mode with ECMP enabled between them.
The OCI Transit VPC Route Table is Empty because all routing is done by the Transit-GW
This outout show the Transit Gateway routing table. Notice that the Spoke routes are automatically added and pointing towards the OCI-Spoke-GW tunnel.

OCI Spoke VCN and Spoke GW Routing Tables

Here we can see the routing table details from the Spoke VCN and Spoke GW point of view.

Spoke Gateway tunnel us up. It also shows the CIDRs it is advertising to Transit/Hub GW for end-to-end routing purposes.
This is the Spoke-VCN private routing table. Aviatrx controller created two routing tables inside the VCN. One is private (wihtout the default route) and second is default route table (shown in the next screen shot with the default route in there). Aviatrix controller also added RFC1918 routes pointing towards the OCI-Spoke-GW1.
This is the default routing table that has route in it to route traffic towards Internet. This route is needed to build the tunnle between Transit and Spoke GWs
Spoke GW routing table
Spoke GW routing table

At this point the OCI setup is complete. In the next step we will peer OCI and GCP transit networks to establish connectivity between multiple clouds.

Transit Peering Between OCI and GCP Transit Gateways

Aviatrix provides a common cloud architecture and operaions cabalities that allows operators and architects to build multi-cloud archtecture without worrrying about the underlying constructs.

In order to achieve the initial business objective, now we will peer OCI and GCO together. This will allow applications in either side of the cloud to have true multi-cloud connectivity.

Login to Aviatrix controller and under “Transit Peering” select the Transit Gateways in both Clouds respectively and then connect.

Following output shows that both Clouds are connected in true multi-cloud fashion within a minute.

After about a minutes the transit peering comes UP

Multi-Cloud Connectivty Testing

We have deployed following topology for the multi-cloud connectivity. We will perform a ping test from source Test-VM in GCP towards Test-VM in OCI behind Spoke-VCN-GW

  • gcp-vm –
  • gcp-spoke
  • gcp-transit-gw
  • oci-transit-gw
  • oci-spoke
  • oci-vm –
Traceroute from GCP Test VM to OCI-Test VM
Ping from GCP Test VM to OCI-Test VM


Aviatrix allows a common network topology across multiple clouds. This makes the enterprise network and security deployments seamless. There are no surprises and IT admins/operators does not need to know the underlying artifacts of various clouds.

Aviatrix Oracle Cloud (OCI) On-Boarding and Initial Configuration


Aviatrix controller makes it extremely simple to on-board Oracle OCI. Take a look at the screen shots here and follow along.

If you are new to OCI and OCI terminologies, it is strongly recommended to read this article before moving forward.

The Aviatrix Controller is multi cloud, multi subscription, multi account and multi region capable appliance/VM/instance. Launching the Controller in any public cloud will also enable you to deploy and manage networking and security in any other public cloud.

In our setup, Aviatrix Controller is already deployed and running in AWS. Bill for using Aviatrix services will still be billed to AWS billing account. One has to pay for the utilization of OCI resources in the OCI billing system.

On the controller UI

1- Click on-boarding option
2- Select Oracle Cloud Infrastructure (OCI) option

Oralce Cloud Onboarding Process

After step#2, you are presented with the following screen.

OCI Account , Tenancy and Compartment Details

The purpose of on-boarding is to help you setup an account on the Aviatrix Controller (AVX-CTRL) that corresponds to an OCI account with compartment policies, so that the Aviatrix Controller can launch Aviatrix GWs using OCI APIs. For on-boarding the OCI account in the AVX-CTRL, we need following four pieces of information from OCI console.

  • User OCID
  • Tenancy OCID
  • Compartment OCID
  • API Private Key File



User OCID information is collected from Identity section.

Tenancy OCID

Tenancy OCID information is collected by navigating in the OCI Console’s Administration section (OCI Console –> Administration –>Tenancy Details)

Compartment OCID

Compartment or department OCID can be gathered by navigating in the Identity section of OCI console ( OCI Console –> Identity –>Compartments)

Generate Public and Private Keys

The commands here are valid for Mac and Linux OS. For Windows, you need to install “Git bash for Windows”

$ openssl genrsa -out oci_api_private_key.pem 2048
$ chmod go-rwx oci_api_private_key.pem
$ openssl rsa -pubout -in oci_api_private_key.pem -out oci_api_public_key.pem
$ cat oci_api_private_key.pem | pbcopy

Refer to following doc for detailed steps


OCI Onboarded

At this point OCI is on-boarded. Notice that beside OCI, we have AWS, Azure and GCP on-boarded under the same controller as well.

OCI Account Onboarded

Create Transit VPC

To make sure the connectivity is established between Aviatrix Controller and OCI, we will create a OCI Transit VCN (VCN is equivalent to VPC in AWS) directly from Aviatrix Controller UI. This Transit VCN will also be used in the subsequent testing.

OCI VCN Created From Aviatrix Controller
OCI VCN Created From Aviatrix Controller

Following screen shot taken from OCI console shows that VCN was successfully created from Aviatrix Controller.

VCN Created in Finance Compartment. This is the one we provided during account on-boarding

Also notice that beside creating the simple VCN, Aviatrix Controller also creates following

  • Public and Private subnets inside the VCN
    • These subnets are created and managed for private and public routing tables
  • Private and Public Routing tables
  • Internet Gateway
VCN details show that AVX-CTRL created the VCN and Public and Private Subnets as well

Following screen shot shows the routing tables created by Aviatrix Controller.

Route Tables created by AVX-CTRL automation


Internet Gateway (IGW) was also created by AVX-CTRL at the time of VCN creation
AVX-CTRL associates Public subnet to a Public Route Table
AVX-CTRL associates Public subnet to a Public Route Table
This public route table has a default route that points to OCI IGW for Internet Traffic


This initial configuration shows the OCI account on-boarding and deployment of one Transit VPC with associated subnets and route table. The AVX-CTRL makes it easy and seamless to deploy multi-clouds with the same look and feel and without worrying about underneath constructs.

Multi-Cloud Transit Design: Interworking with On-Prem and/or Cloud Devices/Services

Aviatrix solution can take care of networking, security and network segmentation for workloads deployed in public clouds by deploying transit networking solution using Aviatrix transit and spoke gateways. It is a standard and stamp-out (copy/paste and repeat) design that is applicable to any public cloud (e.g AWS, GCP, Azure and OCI).

There are situation when there is a need to connect to 3rd party devices or services to exchange routes or to provide additional connectivity. These services and devices could be in the Public Cloud or On-Premise. In those situation the Aviatrix transit can also connect to those devices and services in secure and encrypted fashion (e.g using L3 IPSec).

Customer Scenario

Following topology demonstrate a scenario where a business is using Cisco CSR (could be any service or instance from any vendor that supports IPSec) in the Cloud to terminate LISP. By virtue of using LISP, the business is forced into a sub-optimal design where an additional hop is necessary.

Aviatrix Setup

For this setup we are assuming that you have already deployed Cisco CSR from AWS marketplace

  • Created Transit VPC and Spoke VPC directly from Aviatrix Controller UI (no need to login to AWS console)
  • Deployed AVX Transit GW and AVX Spoke GW in their respective VPCs using the Aviatrix Controller UI
  • Follow the Aviatrix Transit Networking workflow to connect to external 3rd party device (e.g Cisco CSR)
    • For external connectivity eBGP is the preferred option and this is what we are using here
    • If you want to connect via static route to external device, it is also possible but then you have to enable “ActiveMesh” on Aviatrix Transit and Spoke Gateways first
  • Attached Spoke-VPC to Transit-VPC

Build the IPSec Tunnel From Aviatrix Transit Gateway to Cisco CSR

Configure Aviatrix Controller as shown below

Notice we are using the default IPSec Algorithms. My recommendation is to start with the default and change after if needed

After you have done the setup as above, you will notice an entry in the Site2Cloud (S2C) section of AVX-Controller automatically (The screenshot shows tunnel UP which is not correct. The tunnel will be in the down state at this time)

Click on the Name above and download the IPSec config.

Use Generic as vendor.
Aviatrix Site2Cloud configuration. 
 This connection has a single IPsec tunnel between customer  gateway and Aviatrix gateway in the cloud.
 Tunnel #1
1: Internet Key Exchange Configuration
 Configure the IKE SA as follows
 Version                  : 1
 Authentication Method    : Pre-Shared Key 
 Pre-Shared Key           : Aviatrix1!
 Encryption Algorithm     : AES-256-CBC
 Authentication Algorithm : SHA-1
 Lifetime                 : 28800 seconds
 Phase 1 Negotiation Mode : main
 Perfect Forward Secrecy  : Diffie-Hellman Group 2
 DPD threshold            : 10 seconds
 DPD retry interval       : 3 seconds
 DPD retry count          : 3 
2: IPSec Configuration
 Configure the IPSec SA as follows:
 Protocol                 : esp
 Authentication Algorithm : hmac-sha1
 Encryption Algorithm     : AES-256-CBC
 Authentication Algorithm : HMAC-SHA-1
 Lifetime                 : 28800 seconds
 Mode                     : tunnel
 Perfect Forward Secrecy  : Diffie-Hellman Group 2 
IPSec ESP (Encapsulating Security Payload) inserts additional
 headers to transmit packets. These headers require additional space, which reduces the amount of space available to transmit application data.To limit the impact of this behavior, we recommend the following configuration on your Customer Gateway:

 TCP MSS Adjustment       : 1387 bytes
 Clear Don't Fragment Bit : enabled
 Fragmentation            : Before encryption 
3: Tunnel Interface Configuration
 Your Customer Gateway must be configured with a tunnel interface that is associated with the IPSec tunnel. Traffic that should go through the tunnel should be specified by following your gateway's configuration guide, using the information below.
Gateway IP addresses:
 Customer Gateway                :
 Aviatrix Gateway Public IP      :
 Aviatrix Gateway Private IP     : 
 Customer Network(s)             : N/A for transit network
 Cloud Networks(s)               : N/A for transit network 
Tunnel Inside IP addresses:
 Customer Gateway                :
 Aviatrix Gateway                : 
Configure your tunnel to fragment at the optimal size:
 Tunnel interface MTU     : 1436 bytes 
4. Border Gateway Protocol (BGP) Configuration:
 The Border Gateway Protocol (BGPv4) is used to exchange routes from the VPC to on-prem network. Each BGP router has an Autonomous System Number (ASN).
BGP Configuration:
 BGP Mode                        : true
 Customer Gateway ASN            : 65002
 Aviatrix Gateway ASN            : 65003 
Configure BGP to receive routes from on-prem network. Aviatrix Transit gateway will announce prefixes to your on-prem  gateway based upon the spokes you have attached. For vendor specific instructions, please go to the following URL:

Cisco CSR Configuration

This is how the above template translates into a Cisco CSR Config.

ip-10-60-0-89#sh run 
Building configuration...

Current configuration : 7936 bytes
! Last configuration change at 16:30:21 UTC Fri Oct 4 2019 by ec2-user
version 16.12
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
platform console virtual
hostname ip-10-60-0-89
vrf definition GS
 rd 100:100
 address-family ipv4
logging persistent size 1000000 filesize 8192 immediate
no aaa new-model
login on-success log
subscriber templating
multilink bundle-name authenticated
license udi pid CSR1000V sn 91V3AHTVAJ1
diagnostic bootup level minimal
memory free low-watermark processor 72406
spanning-tree extend system-id
username ec2-user privilege 15
crypto keyring mykey
! local-address is the private IP address of this CSR
  pre-shared-key address key Aviatrix1!
! is the public IP address of Avaitrix 
crypto isakmp policy 10
 encryption aes 256
 authentication pre-share
 group 2
 lifetime 28800
crypto isakmp keepalive 10 3 periodic
crypto isakmp profile myprofile
   keyring mykey
   self-identity address
   match identity address 
crypto ipsec transform-set myset esp-aes 256 esp-sha-hmac 
 mode tunnel
crypto ipsec df-bit clear
crypto ipsec profile ipsec_profile
 set security-association lifetime seconds 28800
 set transform-set myset 
 set pfs group2
interface Loopback0
 ip address
interface Tunnel0
 ip address
 ip tcp adjust-mss 1387
 tunnel source
 tunnel mode ipsec ipv4
 tunnel destination
 tunnel protection ipsec profile ipsec_profile
interface VirtualPortGroup0
 vrf forwarding GS
 ip address
 ip nat inside
 no mop enabled
 no mop sysid
interface GigabitEthernet1
 ip address dhcp
 ip nat outside
 negotiation auto
 no mop enabled
 no mop sysid
router bgp 65002
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 65003
 neighbor timers 10 30 30
 address-family vpnv4
  neighbor activate
  neighbor send-community extended
ip forward-protocol nd
ip tcp mss 1387
ip tcp window-size 8192
ip http server
ip http authentication local
ip http secure-server
ip nat inside source list GS_NAT_ACL interface GigabitEthernet1 vrf GS overload
ip route vrf GS GigabitEthernet1 global
ip ssh rsa keypair-name ssh-key
ip ssh version 2
ip ssh pubkey-chain
  username ec2-user
   key-hash ssh-rsa BF29B2896E9286C9B44DD472EF3397DA ec2-user
ip scp server enable
ip access-list standard GS_NAT_ACL
 10 permit
 20 permit
line con 0
 stopbits 1
line vty 0 4
 login local
 transport input ssh
line vty 5 20
 login local
 transport input ssh
app-hosting appid guestshell
 app-vnic gateway1 virtualportgroup 0 guest-interface 0
  guest-ipaddress netmask
 app-default-gateway guest-interface 0


BGP Working Config. with address-family ipv4

The configuration above uses the vpn4 as address family. You can also make it work with ipv4 address family

router bgp 65002
 bgp log-neighbor-changes
 neighbor remote-as 65003
 neighbor timers 10 30 30
 neighbor remote-as 65001
 neighbor timers 10 30 30
 address-family ipv4
  ! is being advertised by Cisco CSR
  redistribute connected
  neighbor activate
  neighbor activate
Aviatrix Transit GW receives advertised by Cisco CSR


Aviatrix Transit Gateway workflow allows direct connectivity from Transit Gateway to 3rd party devices. The standard IPSec protocols allows Aviatrix Transit Gateway to connect to any devices supporting IPSec. These devices could be in the same Public Cloud, a different Public Cloud or to the On-Prem devices.

The workflow based implementation allows ease of use and reduces time to market.

Design and Feature Requirement for a User-VPN Solution

If you are building a new or re-architecting a User-VPN (aka SSL VPN or Client to Site VPN) based solution, then you should consider at least following design ingredients in your solution

  • Built on OpenVPN® and is compatible with all OpenVPN® client software
  • Provide certificate based SSL VPN user authentication
  • LDAP/AD Integration
  • Support multi factor authentication (MFA) methods such as Google, DUO, Okta, SAML and LDAP
  • You should also be able to combine various authentication and authorization components to add extra level of security for the interaction. For instance the solution first authenticate from a corporate LDAP entity and then consult with DUO for MFA
  • Authenticate a VPN user directly from the VPN client to any IDP via SAML protocol. The SAML protocol and a client with SAML support must be the key requirement
  • Supports external PKI for OpenVPN Certificates
  • The solution must provide a Profile Based Access Control so that beyond the authentication and autharization that was discussed above, one should also control the access right at the IP Address, CIDR or Subnet level (aka Profile Based Network Segmentation)

The Aviatrix solution has all the above mentioned design ingredients. On top of that it has features such as Geo-Location based connectivity to the closest VPN GW (or Concentrator) with support for both TCP and UDP based load-balancing

Look at this Clara customer case-study (Clara is part of SoFI now) for reference


Direct Connect Gateway

Direct Connect Gateway is getting popularity. With large networks and deployment across regions, it is evident that customers are picking Direct Connect Gateway to provide high-availability across regions. One should remember that even with the Direct Connect GW in picture, data path still goes through the physical connection. It means that for regions that are far apart, one might notice some latency/delays.

Managing and automating Direct Connect (DX) Gateway could be challenging. Aviatrix is the platform that can orchestrate a DX Gateway that is serving as a bridge between two Transit Gateways across regions provided there is no VGW in the datapath and the DX Gateway is attached to the TGWs via the default security domain (Security Domain is Aviatrix construct to provide network segmentation between VPCs/vNETs)

Aviatrix will orchestrating the Multi-Region architecture with DX Gateway and will handle all the route propagation. In addition, it will deliver the following additional capabilities to the network:

  • Full HA Capabilities with no single point of failure in the network with High Performance Encryption between Regions @ 5Gbps
    • IPSec VPN could also be used as a Backup to the DX Gateway
  • Centralized Firewall Management
  • Multi-Cloud Connectivity

SAML Based User-VPN / Open-VPN in Public Cloud

All major Cloud providers like AWS, Azure and GCP provide User-VPN (aka SSL/TLS VPN) services to allow remote users to connect to Cloud resources, instances and VMs.

This functionality is missing the support for SAML /SSO. SAML/SSO is extremely popular today but it is not supported by any major Cloud (AWS, Azure, GCP) yet.

This is where Aviatrix User-VPN solution has an edge. It provides a policy based framework which works nicely with the SAML and supported with IdP providers like OneLogin, Okta and DUO.

Network Joints

Networking and Networks have transformed over period of time. Enterprises have realized that public cloud is the strategic direction for their IT infrastructure and applications. The service providers like Amazon, Google and Microsoft are extremely efficient at providing networking, security, compute and storage capabilities in their respective public cloud such as AWS, GCP and Azure.

“All Clouds are not created equally”. In order to get the best of each and every cloud, there is a need to create seamless joints between those clouds which should, like human body joints, work in conjunction with each others. They should work in harmony, in an orchestrated fashion. This joining and marriage has given birth to a new Networking Architecture, what we call “Multi-Cloud” today.