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.
When customers are migrating to Aviatrix Transit from AWS TGW, we would build BGP connectivity between AWS TGW with Aviatrix Transit. In the past, we have to use IPSec, which would be limited to 1.25G per tunnel connection speed, for customer’s that doesn’t require end to end encryption during the migration, with AWS TGW Connect, now we can build GRE tunnels between AWS TGW and Aviatrix Transit.
Many enterprises venture into clouds and find the landscape of cloud networking very different from on-prem. Multi-homed devices such as routers and firewalls when deploy to the cloud also are having challenges to insert themself into traffic path, particularly due the reasons listed below. This in turn slows down the enterprises adoption speed to the cloud. Let’s take a look what some of these challenges are: