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:

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

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

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

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

create_tgw

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.

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

connect_domain_1

Continuing from the above example, you can connect prod_domain to Shared_Service_Domain, as shown below.

connect_domain_2

Click the View page under AWS Transit Gateway Orchestrator and click each expandable circle to see what has been created, as shown below.

plan_view

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.

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.

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

transit_complete

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.

tgw_peer

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.

Deleting a Network Domain

This step deletes a network domain created in the Creating a New Network Domain section above.

Deleting an AWS TGW

This step deletes the AWS Transit Gateway.