Aviatrix developed Migration Toolkit to help customer migrate from existing AWS/ Azure environment to Aviatrix Transit and Spoke Multi-Cloud Networking Architecture (MCNA). I have discussed the process in blog: Migrate from Azure vNet hub and spoke architecture to Aviatrix Transit. The AWS migration process is similar, where the toolkit make copies of existing route tables, when Aviatrix Spoke is attached to Aviatrix Transit, we are using these copied route tables, hence no traffic interruption would happen. During the traffic switching phrase, subnets will be associated with the copied route table, and in TGW we disable the migrating VPC router advertisement, so the traffic would swing over to Aviatrix Spoke/Transit.
Some of our customers are using CloudFormation to manage the deployment of their environment, while Aviatrix Controller will handle bulk of the work such as populating RFC1918 and/or default route in the route table and/or non-RFC1918 routes from External connections, they still would like to have the ability to continue to use CloudFormation to manage endpoint routes. This created a split brain scenario, how do we handle this?
One of our customers approached Aviatrix in search of a high-performance encryption solution for their on-premise data centers and AWS. They were impressed with Aviatrix’s features, including visibility, a dedicated data plane, high-throughput encryption, and Terraform capability. However, they also had sister business entities still using AWS TGW, and didn’t want to spend too much time trying to convince them to switch to Aviatrix. That’s when they turned to us for a hybrid architecture solution.
Recently we were helping customer to launch Spoke Gateways in their AWS account, after 10 minutes launching the gateway, the gateway creation were reverted and following errors generated
Error: [AVXERR-TRANSIT-0119] Failed to launch gateway test. Instance i-0005da0797da40ae8 could not be started. Delete the gateway test to clean up resources and try again. It is possible that gateway size t3.small is not supported in the region us-east-1 or EBS encryption KMS CMK Key policy Key administrators and users are not updated with your Aviatrix APP role and Aviatrix EC2 role.
In AWS, subnet that doesn’t have default 0.0.0.0/0 point to Internet Gateway (IGW) is considered as private subnet. Where subnet that have default 0.0.0.0/0 point to IGW is considered as public subnet. Instances running on private subnet still need to access Internet to download patches, packages etc. You may use AWS NAT Gateway on public subnet to provide this connectivity. NAT Gateway cost $0.045 USD per hour plus $0.045 per GB data processed.
If you already have Aviatrix Spoke Gateway deployed, and need internet access (egress) from private subnet, also you don’t need any fancy egress control, then you may reuse the existing Aviatrix Spoke Gateway as Egress Gateway by using SNAT rule.
If you need better control and traffic inspection, you should consider Aviatrix FQDN egress gateway for L7 egress control based on Fully Qualified Domain Name eg: allow https://github.com deny https://youtube.com. Or if deep packet inspection using Next Generation Firewall (NGFW) is required, then you may consider Aviatrix FireNet with NGFW integration.
In the last two blog posts, we discussed two methods for connecting on-premises to Aviatrix Transit via Direct Connect:
Option 1: Use detached Virtual Private Gateway (VGW) to build BGP over IPSec tunnels with Aviatrix Transit. This solution has following constrains: 1.25Gbps per IPSec tunnel, max 100 prefixes between on-premise and cloud, also potential exposure to the man in the middle attack.
Option 2: Use attached VGW to build underlay connectivity between on-premise router/firewall and Aviatrix Transit VPC, then use GRE tunnels to build overlay connectivity between on-premise router/firewall to Aviatrix Transit. This solution would provide 5Gbps per GRE tunnel, and bypass the 100 prefixes limitation. However this solution only works with AWS, and still have potential exposure to the man in the middle attack.
Today, more and more enterprises are going into multiple cloud service providers (CSPs). Some due to merger and acquisitions, or partner/ vendor preferences, or simply one CSP provides superior products that are not offered by other CSPs.
Is there a solution that can standardize networking architecture across all CSPs, and provide necessary securities and bandwidths, and more importantly provide enterprise grade features, and also help enterprise obtain day 2 operational excellencies?
In my last blog post, I have covered one option to connect On-Premise data center to Aviatrix Transit via Direct Connect, it’s easy to implement however with following draw backs:
Each IPSec tunnel between Aviatrix Transit and AWS Virtual Private Gateway (VGW) is limited to 1.25Gbps of throughput, and we can only have 4 tunnels which limits the aggregated throughput to 5Gbps. For customer want to have higher throughput, this won’t be viable.
Private Virtual Interface support up to 100 BGP routes, BGP session will go DOWN when more routes been advertised
Between On-Premise to VGW, traffic maybe protected by MACSec, but still expose to man in the middle attack. Reference article: Securing your network connection to the cloud: MACSec vs. IPSec
How do we overcome these constrains? Let me take you through the second option connecting to Aviatrix Transit via Direct connect.
Aviatrix Controller isn’t In data path, controller down will affect ability to change currently configuration, or to monitor gateway status to make changes to route tables, or to authenticate new VPN user connection request.
To make sure Aviatrix controller in AWS highly available by avoiding single AZ failure, Aviatrix has developed a CloudFormation template that utilizes Auto Scaling Group and Lambda function to automatically monitor controller failure, redeploy controller and restore configuration.
Here’s a case where customer wants to create BGP over GRE tunnels between Palo Alto Firewall and Aviatrix Transit Gateways. Palo Alto have some articles but not very clear, this blog will serve as a reminder how this is done. Credit to Pranay for helping out the BGP peering part on Palo.
This is the first of the three articles. It will be the easiest to accomplish but with following requirements, and constrains highlighted.
Virtual Private Gateway (VGW) has to be created in the same region as the Direct Connect Private Virtual Interface (VIF).
Each VIF is dedicated to one VGW.
VGW is NOT attached to the VPC
Aviatrix orchestrate Customer Gateways and VPN Connections, building 2x IPSec/BGP tunnels per Aviatrix Transit Gateway.
Each IPSec tunnel have 1.25G throughput limit
Private Virtual Interface support up to 100 BGP routes, BGP session will go DOWN when more routes been advertised. In layman’s term when this happens, Cloud won’t see OnPrem routes, and OnPrem won’t see Cloud routes, connectivity between Cloud and OnPrem will be LOST. You must summarize advertised routes on both ends to be lower than 100 to get around this limit.