TGW Plan
The AWS Transit Gateway (TGW) Orchestrator Plan is the first stage in deploying a AVX Transit Network using AWS Transit Gateway. This stage is performed on the TGW Orchestrator > Plan page in the Aviatrix Controller.
After you go through the Plan stage configuration, you can proceed to the Build stage to attach VPCs.
For background information, see the AWS Transit Gateway Orchestrator FAQ.
The plan stage consists of four sections:
-
Create AWS Transit Gateway. This is the only must-do section on the Plan page before you start to Build (attach VPCs). See the Creating an AWS TGW section below. In this section, an AWS Transit Gateway and three connected Network Domains are created.
-
Create Segmented Network (optional). In this section you Create a Network Domain and Build Domain Connection Policies. This section creates your own additional Network Domains and defines Connection policies. This section is entirely modular and you can modify at any time.
-
Create hybrid, multi-region or multicloud Connection (optional). In this section you Set up an Aviatrix Transit Gateway, Prepare the Aviatrix Transit Gateway for TGW Attachment, and Attach an Aviatrix Transit Gateway to TGW (as per the below sections). This section launches an Aviatrix Transit Gateway at the edge VPC, builds a hybrid connection to on-prem or another Aviatrix Transit gateway cluster, or deploys Transit DMZ. If you need hybrid connectivity, setting up an Aviatrix Transit Gateway, preparing an Aviatrix Transit GW for TGW Attachment, and attaching an Aviatrix Transit Gateway to AWS TGW must all be executed in sequence to complete this section. This section is entirely modular and you can modify at any time.
-
TGW Native Edge Connections (optional). In this section you configure TGW VPN, TGW DXGW and TGW Inter Region Peering. It consists of the steps described in the Setting up an AWS Transit Gateway VPN Connection and Downloading the VPN Configuration sections below.
In the planning stage, think about what network segmentation you need to achieve. For example, do you need to segment Dev/QA VPCs from your Prod VPCs, i.e., no connectivity is allowed between these VPCs in each group? The plan stage creates Transit Gateway and Transit Gateway route tables in AWS. There is no charge either by AWS or Aviatrix.
If you have not decided on network segmentation, proceed to build a full mesh network by using Default_Domain.
|
You can modify your plan at any time. Simply return to the Plan page and create network domains and change connection policies. |
The Transit Gateway Orchestrator Plan workflow provides step-by-step instructions to define and set up your policies.
Creating an AWS TGW
In order to use AWS Transit Gateway service, you must first create a AWS Transit Gateway.
This step creates a AWS Transit Gateway in a specified region with a specified AWS account. The Aviatrix Controller also automatically creates the Default_Domain, the Shared_Service_Domain and the Aviatrix_Edge_Domain and the corresponding AWS Transit Gateway route tables.
The three domains are connected, implying that if you attach a VPC to the Default Domain or Shared Service Domain, the VPCs can communicate with each other and can access on-prem through the Aviatrix Edge Domain.
| Setting | Value |
|---|---|
Account Name |
An Aviatrix account that corresponds to an IAM role or account in AWS. |
Region |
One of the AWS regions |
TGW Name |
The name of the AWS Transit Gateway |
AWS Side AS Number |
TGW ASN number. Default AS number is 64512. |
After the AWS Transit Gateway is created, you can validate by going to the View page and seeing what has been created.
This section includes creating a new network domain and building your domain connection policies to plan a segmented network.
Creating a New Network Domain
If you plan to build a default network (full mesh), skip this section.
You can make changes to your network segmentation at any time.
If you plan to build a segmented network, use this section to create a new Network Domain and set up connection policies.
In the example below, a new domain called prod_domain is created.
| Setting | Value |
|---|---|
TGW Name |
The name of the AWS Transit Gateway |
Network Domain Name |
Specify a unique domain name: for example, Dev_Domain. |
Aviatrix Firewall Domain |
Check this box if this domain is for Aviatrix FireNet. |
Native Egress Domain |
Check this box if this domain is for non-Aviatrix FireNet based central Internet bound traffic. Native Egress Domain is not recommended as it only supports an active-standby firewall deployment. |
Native Firewall Domain |
Check this box if this domain is for non-Aviatrix FireNet based firewall traffic inspection. Native Firewall Domain is not recommended as it only supports an active-standby firewall deployment. |
Building Your Domain Connection Policies
This step specifies the connection relationship of one domain to others. Two connected domains imply that VPCs in each domain can communicate with each other despite the fact that they are in different domains. The Aviatrix Controller takes care of both VPC route table and AWS Transit Gateway route table programming and updates.
Highlight a domain on the left panel and click Add, and the domain will appear on the right.
In the example shown below, the intention is to connect the newly created prod_domain in the Creating a New Network Domain section above to the Aviatrix_Edge_Domain so that VPCs in the prod_domain can communicate with on-prem servers and hosts.
Continuing from the above example, you can connect prod_domain to Shared_Service_Domain, as shown below.
Click the View page under AWS Transit Gateway Orchestrator and click each expandable circle to see what has been created, as shown below.
This section is for hybrid, multi-region or multicloud connections. It sets up connection to an on-prem data center over Direct Connect or the Internet.
Setting up an Aviatrix Transit GW
This section is about deploying Aviatrix Transit Gateways in a VPC and attaching the VPC to TGW. From the TGW point of view, this VPC is a Spoke VPC attached to TGW, however from Controller point of view, the Aviatrix Transit Gateway is the packet forwarding engine to on-prem or to another Aviatrix Transit Gateway. The direct attachment architecture allows the Aviatrix Transit Gateways to forward packets to TGW and Spoke VPCs at the rate of 50Mbps as specified by TGW.
The use case for this deployment is to use Aviatrix Transit Gateway to connect to on-prem or to peer with another Aviatrix Transit Gateway.
If you intend to use TGW DXGW to connect to on-prem, TGW VPN to connect to on-prem, or use native TGW peering to connect to regions, skip this section.
This section is modular. Return to this section anytime if your requirements change later.
|
We strongly recommend creating a new Transit VPC at Useful Tools → Create a VPC. Select Aviatrix Transit VPC. If you would like to use an existing VPC and its network CIDR is too small (not enough of /28 unused CIDR segments), use AWS Edit VPC CIDR feature to create a new /23 subnet to deploy the Aviatrix Transit Gateway in TGW use case. |
To deploy the Aviatrix Transit Gateways, take a detour and launch Transit and Spoke Gateways as per the Transit Network workflow. If you intend to use Aviatrix Transit Gateway to connect to on-prem, also attach Spoke to Transit on the same page.
When completed, return to this section and continue to the next step in this workflow to Enable Aviatrix Transit GW to TGW.
Preparing the Aviatrix Transit GW for TGW Attachment
The Aviatrix Transit GW created in the Setting up an Aviatrix Transit GW section above does not build an IPsec tunnel to an AWS Transit Gateway. The networking between AWS Transit Gateway and the Aviatrix Transit GW is via the AWS VPC infrastructure.
This step designates an Aviatrix Transit GW to be used in conjunction with the AWS Transit Gateway. It creates a second Ethernet interface eth1 on the Aviatrix Transit GW for sending and receiving packets from AWS Transit Gateway. It also creates two subnets, -tgw-ingress and -tgw-egress and two respective route tables in the edge VPC to route packets to and from AWS Transit Gateway.
| Setting | Value |
|---|---|
Cloud Type |
AWS or AWS Gov Cloud |
Aviatrix Transit Gateway Name |
Select a Transit GW from the dropdown menu. |
Attaching an Aviatrix Transit GW to TGW
This step attaches the Aviatrix Edge VPC to the AWS Transit Gateway and the Aviatrix Edge Domain, thus allowing the Aviatrix Transit GW to send and receive packets from AWS Transit Gateway.
In this step, route entries are added to the two created private subnet route tables as described in the table below.
| subnet | route table | route entry | description |
|---|---|---|---|
-tgw-egress (for eth1) |
-tgw-egress |
0.0.0.0/0 → TGW |
for traffic from Aviatrix Transit GW to TGW |
-tgw-ingress |
-tgw-ingress |
0.0.0.0/0 → eth1 |
for traffic from TGW to Aviatrix Transit GW |
|
There is no IPsec tunnel between AWS Transit Gateway and the Aviatrix Transit GW, the Aviatrix GW behaves as an EC2 instance in a Spoke VPC (The Aviatrix Edge VPC) attached to the AWS Transit Gateway, as shown in the diagram below. Such a setup allows Aviatrix edge VPC to leverage the high performance provided by AWS Transit Gateway. |
After you finish these steps, your hybrid connection using Aviatrix Transit Gateway for TGW setup is complete. In the above example, if you have any Spoke VPCs attached to the prod_domain, EC2 instances should be able to communicate with on-prem. (Make sure instance security groups and any on-prem firewalls are configured properly.)
This section consists of TGW native VPN, Direct Connect, and TGW Inter Region Peering functions.
Since TGW does not propagate learned routes from DXGW or VPN to Spoke VPCs, Aviatrix Controller solves this problem by periodically polling the TGW route table and programming the learned routes to attached Spoke VPCs.
Setup AWS Transit Gateway VPN Connection
Setting up a VPN Connection
This function configures a native TGW VPN. It takes two steps: first configure, then download the configuration.
This step creates a VPN connection from TGW in a selected Network Domain.
| Setting | Value |
|---|---|
AWS Transit Gateway Name |
The name of a TGW created here |
Connection Name |
A unique name for the VPN connection |
Remote Public IP |
Remote site public IP address |
Dynamic (BGP) or Static |
Use BGP to connect to remote site or static IP |
Remote CIDRs |
When Static is selected, enter a list of CIDRs separated by comma. |
Remote AS Number |
When Dynamic is selected, enter the AS number of the remote site. |
Network Domain Name |
Select a Network Domain to associate the VPN attachment with |
Learned CIDR Approval |
Select the option to enable Approval. This option applies to Dynamic (BGP) mode only. |
Global Acceleration |
Select the option to enable AWS Accelerated VPN |
Downloading the VPN Configuration
Refresh the screen to see the newly created VPN connection.
If Static VPN is configured, you must go to the AWS Console > VPC > Site-to-Site VPN Connections to download the configuration file.
If Dynamic VPN is configured, click Download to download the configuration.
Setting up AWS Transit Gateway Direct Connect
This section configures a native Direct Connect from TGW. This step can take more than 10 minutes for the connection to be ready.
Setting up Direct Connect
This step assumes that you have created Direct Connect Gateway and Transit Virtual Interface from AWS Console.
You may need to update the Controller IAM policies for this function.
| Setting | Value |
|---|---|
AWS Transit Gateway Name |
The name of a TGW created here |
Direct Connect Gateway Account Name |
The Aviatrix Access Account name that created AWS Direct Connect Gateway |
AWS Direct Connect Gateway |
The AWS Direct Connect Gateway you created from AWS Console |
Allowed Prefix |
A list of comma-separated CIDRs for DXGW to advertise to remote (on-prem) |
Network Domain Name |
Select a Network Domain to associate the VPN attachment with |
Learned CIDR Approval |
Select the option to enable Approval. This option applies to Dynamic (BGP) mode only. |
Updating Direct Connect Network Prefix
Use this step to update the Allowed Prefix to advertise to on-prem.
TGW Inter Region Peering
TGW inter-region peering is a feature where Controller orchestrates AWS TGW peering. In addition, the Controller programs and propagates network CIDR of Spoke VPCs and Edge Domains in a Network Domain to the remote TGW deployment, thus providing the end-to-end turnkey solution.
It takes two steps to connect two Network Domains in two regions.
|
Your Controller may not have the latest IAM policies to execute TGW peering, go to Accounts > Access Accounts. Select the account where TGW is deployed and click Update Policy. Do so for all TGW accounts if you wish to TGW build inter-region peering. |
Creating a TGW Peering Attachment
This step connects two TGWs in different regions using AWS native TGW Peering. It automatically creates two Network Domains associated with each TGW and respective attachment ID.
| Setting | Value |
|---|---|
Cloud Type 1 |
Select AWS or AWS GovCloud |
Region 1 |
Select a region where the one TGW is deployed |
AWS Transit Gateway Name 1 |
Select an AWS TGW created here |
Cloud Type 2 |
Select AWS or AWS GovCloud |
Region 2 |
Select a region where the peering TGW is deployed |
AWS Transit Gateway Name 2 |
Select an AWS TGW created here |
Inspecting Inter Region Traffic
The Network Domain associated with each TGW Peering attachment is available for user. The Network Domain has the name peering_<TGW NAME>. For example, for the TGW with name tgw-1, the peering Network Domain is peering_tgw-1.
You can specify a FireNet inspection policy on this Network Domain. When you do so, it implies that any cross-region traffic is inspected. Use TGW > Plan > Add/Modify Connection Policies to connect the peering domain with FireNet Domain.
| To avoid double inspections by two FireNet gateways associated with each TGW, configure the connection policy between peering domain and FireNet domain on only one TGW. |
Building Connection Policies
After step a is completed, go to Building Your Domain Connection Policies. Refresh the page. The peered TGW with its Security Domains should appear on Not Connected panel. Select one remote Security Domain and click Add. Repeat this step for all intended connections, as shown in the diagram below.
In the diagram above, Dev-1 Domain of TGW-1 has connection policy to Dev-2 Domain of TGW-2. Any VPCs in Dev-1 Domain can communicate with VPCs in Dev-2 Domain.
Similarly, Prod-1 Domain of TGW-1 has connection policy to Prod-2 Domain of TGW-2. Any VPCs in Prod-1 Domain can communicate with VPCs in Prod-2 Domain. However, Dev-1 cannot communicate with Prod-2 if there is no connection policy between them.
This section consists of delete functions.
|
To delete an Aviatrix Transit GW attached to a AWS Transit Gateway, go through the Setting up a VPN Connection and Updating Direct Connect Network Prefix sections below. Then, go to Controller Gateway page to terminate the gateway instance. |
Setting up AWS Transit Gateway Connect
Detaching Aviatrix Transit GW from TGW
This step is the opposite of the Attaching an Aviatrix Transit GW to TGW section above. It removes the private subnet route entries respectively.
Disabling Aviatrix Transit GW for TGW Function
This step deletes the eth1 interface and other resources associated with the Aviatrix Transit GW from AWS Transit Gateway Orchestrator.