Providing Scalability and Availability for Site-2-Cloud VPN with Overlapping IP addresses

Aviatrix supports policy-based and route-based VPNs and those can be configured on standalone, spoke, and transit gateways. The workflow for configuration can be found at https://docs.aviatrix.com/HowTos/site2cloud.html. The focus of this blog are designs where the VPN is deployed on its own spoke or using spoke gateways or a combination of standalone and spoke gateways as described later on. Those configurations are done using the SITE2CLOUD menu: One-to-one mapping is supported: the Remote and Local Subnet fields can contain multiple values comma separated. The maximum number of CIDRs for Site2Cloud network maps is 32. If the Local Subnet field is outside … Continue reading Providing Scalability and Availability for Site-2-Cloud VPN with Overlapping IP addresses

Deploying an Aviatrix Firenet on Azure with CheckPoint CloudGuard (Single GWs)

Aviatrix Transit FireNet allows the deployment of 3rd party firewalls onto the Aviatrix transit architecture. Transit FireNet works the same way as the Firewall Network where traffic in and out of the specified Spoke is forwarded to the firewall instances for inspection or policy application. The diagram below shows the Aviatrix Firenet design for Azure. When a transit gateway is deployed with the firenet option checked, the Aviatrix controller will: create subnets create UDRs create an internal NLB configure the internal NLB (front end, back-end, healtch check) Aviatrix deploys and configures the Internal Load Balancers for a Firenet. If you … Continue reading Deploying an Aviatrix Firenet on Azure with CheckPoint CloudGuard (Single GWs)

Micro-Segmentation Cloud Architecture with Aviatrix

Architects and engineers are confronted with the criteria on how to create segments when designing segmentation for Aviatrix and how segments communicates among themselves. Today Aviatrix supports Region, Account Name, Subnets , VPC/VNets, and CSP tags as segmentation criteria: In a fabric with a “network” centric design the app domains are aligned to network constructs (vpc/vnet/subnet). For example: 1 subnet = 1 app domain or 1 vpc = 1 app domain. Usually communication is allowed unrestricted as those domains contains multiple apps. It is called an app centric design when the app domain constructs are aligned to the application and … Continue reading Micro-Segmentation Cloud Architecture with Aviatrix

Aviatrix useg: multiple app membership

In this document I’m going to experiment with multiple app domain membership: a VM belongs to more than on app domain. If you are not familiar with the feature, please visit my previous blog on useg to get started: Test Deployment I have a small environment with two spokes (spoke30 and spoke40) where I deployed three test VMs: spoke30-useg-vm1 spoke40-useg-vm1 spoke40-useg-vm2 Each one has a tag with its own VM name. App Domain “appdomain-blue”: The two VMs matches the logical OR condition and are correctly classified as belonging to the “appdomain-blue”: App Domain “appdomain-green”: The two VMs matches the logical … Continue reading Aviatrix useg: multiple app membership

Networking Snowflake on GCP with Aviatrix

Snowflake is a cloud based Software as a Service data platform. Snowflake’s architecture consists of three key layers: Database Storage: When data is loaded into Snowflake, Snowflake reorganizes that data into its internal optimized, compressed, columnar format. Snowflake stores this optimized data in cloud storage. Query Processing: Query execution is performed in the processing layer. Snowflake processes queries using “virtual warehouses”. Each virtual warehouse is an MPP compute cluster composed of multiple compute nodes allocated by Snowflake from a cloud provider. Cloud Services: a collection of services that coordinate activities across Snowflake. Services managed in this layer include: Authentication Infrastructure … Continue reading Networking Snowflake on GCP with Aviatrix

Aviatrix useg: intra app domain policies

In this document I’m going to experiment with intra app domain policies: intra policy deny intra policy allow custom intra policies Aviatrix useg implementation is extremely flexible to allow any of the configurations above. Aviatrix useg is in Public Preview mode at this time (Aviatrix version 6.7b): Public preview mode feature options, performance, and scalability may be limited compared to the final feature. If you are not familiar with the feature, please visit my previous blog on useg to get started: Test Deployment I have a small environment with two spokes (spoke30 and spoke40) where I deployed two test VMs: … Continue reading Aviatrix useg: intra app domain policies

Providing Secure Cloud Networking for Google Vertex AI with Aviatrix

Using Aviatrix to secure cloud networking Vertex AI has several advantages such as: In this blog I show how to combine Vertex AI with a cloud network managed by Aviatrix. Aviatrix Overview Aviatrix is a cloud network platform that brings multi-cloud networking, security, and operational visibility capabilities that go beyond what any cloud service provider offers. Aviatrix software leverages AWS, Azure, GCP and Oracle Cloud APIs to interact with and directly program native cloud networking constructs, abstracting the unique complexities of each cloud to form one network data plane, and adds advanced networking, security and operational features enterprises require. FireNet … Continue reading Providing Secure Cloud Networking for Google Vertex AI with Aviatrix

Networking Google Cloud Build with Aviatrix

From Google Cloud Build overview documentation, Cloud Build executes builds (a build contains instructions for Cloud Build to perform tasks) as a series of build steps, where each build step is run in a Docker container. Executing build steps is analogous to executing commands in a script. Private pools Cloud Build by default runs in a secure, hosted environment with access to the public internet. Each build runs on its own worker and is isolated from other workloads. Private pools are dedicated pools of workers that can access resources in a private network. Private pools are hosted in a Google-owned … Continue reading Networking Google Cloud Build with Aviatrix

Hybrid Google Cloud DNS Connectivity with Aviatrix

The following services are offered by gcp for name resolution: Internal DNS (169.254.169.254) is a service that automatically creates DNS names for virtual machines and internal load balancers on Compute Engine. Cloud DNS is a service providing DNS zone serving. Zones Cloud DNS supports public and private zones: Private zones have the following options: forward queries to another server DNS peering Manage reserve lookup zone Use a service directory namespace Cloud Networking Reference Architecture The Aviatrix FireNet reference architecture is described below: Hybrid approach with two authoritative DNS systems For hybrid environments there are a few options but the recommended … Continue reading Hybrid Google Cloud DNS Connectivity with Aviatrix