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.

Notice that 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.

Oralce Cloud Onboarding Process

The Aviatrix Controller is multi cloud, multi subscription 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.

What do you need to gather for onboarding OCI account in Aviatrix Controller?

The purpose of onboarding 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:

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


Tenancy OCID

OCI Console –> Administration –>Tenancy Details

Compartment OCID

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

OCI Account Onboarded
OCI VCN Created From Aviatrix Controller

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

VCN details show that AVX-CTRL created the VCN and Public and Private Subnets as well

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
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.


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