This document explains how to launch an Aviatrix Gateway from the Aviatrix Controller.

Launching a Gateway

To launch a new gateway in your Controller, click Gateway > New on the left sidebar. To launch a gateway with OpenVPN® capability, refer to this link.

Subnet Information

Aviatrix Gateways are launched in a public subnet in AWS, GCP, and OCI. A public subnet in AWS VPC is defined as a subnet whose associated route table has a default route entry that points to IGW. To learn more about VPC and subnets, open this link.

If you do not have a VPC/VCN with public subnet in AWS, GCP, or OCI, you can use our “Create a VPC” tool to create a VPC with fully populated public and private subnet in each AZ.

Select Gateway Size

When selecting the gateway size, note the following guidelines of IPsec performance based on IPERF tests conducted between two gateways of the same size:

AWS Performance Numbers:

AWS Instance Size Expected Throughput
T2 series Not guaranteed; it can burst up to 130Mbps
c5.2xlarge, c5.4xlarge 2Gbps - 2.5Gbps
c5n.4xlarge 25Gbps (with InsaneMode)
c5n.9xlarge 70Gbps (with InsaneMode)
c5n.18xlarge 70Gbps (with InsaneMode)

Azure Performance Numbers (without Insane mode):

Azure Instance Size Expected Throughput
B series Not guaranteed; it can burst up to 260Mbps
D/Ds series 480Mbps - 1.2Gbps
F Series approximately 450Mbps - 1.2Gbps

GCP Performance Numbers (without Insane mode):

GCP Instance Size Expected Throughput
n1-standard-1, n1-standard-2, n1-highcpu-2 1.0 - 1.2 Gbps
n1-standard-4, n1-highcpu-2 2.3 - 2.5 Gbps

OCI Expected Throughput Numbers:

OCI Instance Shape Throughput with Active Mesh Throughput without Active Mesh
VM.Standard2.2 or larger 1.8G 900 Mbps

With OCI you can choose a flexible shape to modify the Oracle CPU (OCPU) and memory configurations of your shape after it is deployed.

OCI Flex Shape OCPU and RAM
FLEX4.16 E3 4 OCPU 8G RAM
FLEX8.32 E3 8 OCPU 32G RAM
FLEX16.32 E3 16 OCPU 32G RAM

Note

If you need IPsec performance beyond 2Gbps, refer to Aviatrix Insane Mode.

Specifying a Reachable DNS Server IP Address

Aviatrix gateways are launched with a default public DNS server IP address 8.8.8.8 to ensure the gateway has access to Cloud Service Provider public resources such as SQS for Controller and gateway communication. If you want to change to a different DNS server, mark the Specify a Reachable DNS Server IP Address checkbox to enter an alternative DNS IP address.

Enabling NAT

The Aviatrix Gateway performs Source NAT (SNAT) function when this option is selected. All VPC/VCN routing tables for private subnets in AWS, GCP, and OCI are automatically programmed with 0.0.0.0/0 points to the gateway.

The function can be enabled at gateway launch time, or any time afterwards.

For example, you may already have a NAT gateway configured for the VPC in AWS. To minimize downtime, follow the steps below:

  1. Launch a gateway without the SNAT option selected.
  2. Go to your AWS console to remove the existing 0.0.0.0/0 route entry from the route table.
  3. Go to the Gateway page, highlight the desired gateway, click Edit > scroll down to SNAT > click Enable.

Enabling BGP

Select this option to enable the Aviatrix Spoke Gateway with BGP. In the current release (6.6), BGP must be enabled at the creation of the Spoke gateway. Spoke Gateways created pre-6.6 cannot be enabled with BGP. A Spoke Gateway enabled with BGP has a few restrictions compared to a non-BGP Spoke. See `Aviatrix Spoke Gateway to External Devices (BGP-Enabled Spoke) <https://docs.aviatrix.com/HowTos/spokegw_external.html>`_for information about restrictions.

Allocating a New EIP in AWS

Select this option to have the Aviatrix Gateway allocate a new EIP for the gateway from AWS. When the Aviatrix Gateway is deleted, the Controller will release this EIP. If this option is unchecked, the gateway will be allocated an unassociated EIP from the AWS account from which the gateway is launched. When the Aviatrix Gateway is deleted, the Controller will return this EIP to your AWS account without releasing it.

VPN Access

When this option is selected, the Aviatrix Gateway will used for SSL VPN termination. It supports OpenVPN® client and Aviatrix SAML client. For more details, check out this link.

Enabling SAML

When SAML is enabled, a VPN client/user authenticates to an identity provider (IDP) directly, instead of the gateway doing it on behalf of the user.

In this case, you must use Aviatrix VPN Clients.

Check out the details on how to configure and use Aviatrix VPN Clients for SAML.

VPN CIDR Block

When a VPN user connects to the VPN gateway, the user will be assigned a virtual IP address from a pool of IP addresses. This pool of IP addresses is defined as the VPN CIDR Block. The default IP address pool is 192.168.43.0/24.

The only reason you would want to change this address pool is if 192.168.43.0/24 overlaps with your desktop or laptop network address range. For example, if you are on a LAN with a network CIDR 10.0.0.0/24, your desktop IP address will never conflict with your VPN virtual IP address. On the other hand, if your desktop is on a LAN with a network CIDR 192.168.20.0/16, your VPN virtual IP address might conflict with your LAN address. In this case, change the VPN CIDR Block to a different address range, for example, 10.10.0.0/24.

Note a /24 VPN CIDR block supports about 64 simultaneous VPN clients. This is because for each connected VPN client, VPN gateways reserves 3 virtual addresses. For larger number of clients per VPN gateway, consider making the VPN CIDR block to a /22 or /20 network.

MFA Authentication

You can select either Duo or Okta for the VPN gateway to authenticate to these two services on behalf of a VPN user.

When either option is selected, you can use native OpenVPN® client software such as Tunnelblick for iOS and OpenVPN for Windows.

To configure Duo, see How to configure Duo.

To configure Okta, see How to configure Okta.

Max Connections

Maximum number of active VPN users allowed to be connected to this gateway. The default is 100.

When you change this address, make sure the number is smaller than the VPN CIDR block. The OpenVPN® VPN CIDR Block allocates 4 IP addresses for each connected VPN user; when the VPN CIDR Block is a /24 network, it supports about 60 users.

Split Tunnel Mode

Split Tunnel Mode is enabled by default. When Split Tunnel mode is enabled, only traffic that is destined to the VPC/VNet CIDR where the VPN gateway is deployed is going into the VPN tunnel when a user is connected to the VPN gateway.

When Split Tunnel Mode is disabled (Full Tunnel Mode), all laptop traffic, including Internet traffic (such as a visit to www.google.com), is going through the VPN tunnel when a user is connected to the VPN gateway.

Disabling Split Tunnel Mode should be a deliberate decision. You will be charged for all Internet traffic as they are considered egress traffic by the Cloud Service Provider (AWS/Azure/GCP/OCI).

Additional CIDRs

This is an optional parameter. The VPC/VNet CIDR where the VPN gateway is deployed is the default CIDR that VPN gateway pushes to the VPN client. Leave it blank if you do not need it.

When Split Tunnel Mode is enabled, the Additional CIDRs specifies a list of destination CIDR ranges that will also go through the VPN tunnel.

This is a useful field when you have multiple VPC/VNets that the VPN user needs to access.

Enter all network ranges in CIDR blocks separated by commas, as shown below:

additional_cidr

Nameservers (Optional)

This is an optional parameter. Leave it blank if you do not need it.

When Split Tunnel Mode is enabled, you can instruct the VPN gateway to push down a list of DNS servers to your desktop, so that a VPN user is connected, it will use these DNS servers to resolve domain names.

Search Domains (Optional)

This is an optional parameter. Leave it blank if you do not need it.

When Split Tunnel Mode is enabled, Search Domains let you specify a list of domain names that will use the Nameserver when a specific name is not in the destination.

Enable ELB

“Enable ELB” is turned on by default.

When ELB is enabled, the domain name of the CSP’s load balancer (ELB/ALB/CLB), will be the connection IP address when a VPN user connects to the VPN gateway. This connection IP address is part of the .ovpn cert file the Controller sends to the VPN client. Even when you delete all VPN gateways, you can re-launch them without having to reissue a new .ovpn cert file. This helps reduce friction to VPN users.

When the ELB option is enabled, you can launch multiple VPN gateways behind ELB, thus achieving a scale out VPN solution.

ELB Name

The ELB Name is generated automatically if it is left blank. If it is left blank and there is already a load balancer in the specified VPC/VNet, the system uses that load balancer’s name.

You can set the ELB name if there is no existing ELB in the specified VPC/VNet.

VPN Protocol

When the TCP checkbox is marked, the VPN gateway will accept the VPN TCP connection only. If the UDP checkbox is marked, only the VPN UDP connection is allowed. These options are only available on the AWS. For all cloud types, the VPN protocol is TCP by default if ELB is enabled. If the ELB is disabled, the VPN protocol is always UDP.

Enable Client Certificate Sharing

This setting is disabled by default.

By enabling the client certificate sharing, all VPN users share one .ovpn file. You must have MFA (such as SAML, DUO + LDAP) configured to make VPN access secure.

Enable Duplicate Connections

This option was introduced in Controller version 4.3. This setting controls whether users sharing the same common name can connect at the same time to the VPN Gateway. If this is disabled, when a user attempts to connect to the gateway through a different device, his existing VPN connection from the current device gets disconnected.

Note that the users can still land on different VPN Gateways under a load balancer, even though the feature is enabled.

Prior to 4.3, this setting was coupled with Client Certificate Sharing.

VPN NAT

This feature was introduced in Controller version 4.6 . This controls whether the VPN connection uses NAT (Network Address Translation) while the VPN traffic leaves the Aviatrix VPN Gateway.

VPN NAT is enabled by default. If you want to disable it, you can do so from OpenVPN > Edit Config > VPN NAT.

If NAT is disabled, the traffic would appear to originate from the virtual IP of the VPN user rather than the VPN Gateway itself. Note that you would need to open up the security groups of the target instance to the VPN CIDR for the traffic to flow through. Any peering connection to this VPN gateway would additionally require traffic for the VPN CIDR to be forwarded to the gateway as well.

If you have multiple gateways under the load balancer, you would also need to ensure that the VPN CIDR of the gateways do not overlap, so that the traffic can be routed back to the respective gateway.

Enable Policy Based Routing (PBR)

PBR enables you to route VPN traffic to a different subnet with its default gateway.

By default, all VPN traffic is NATed and sent to VPN gateway’s eth0 interface. If you want to force the VPN traffic to go out on a different subnet other than VPN gateway eth0 subnet, you can specify a PBR Subnet in the VPC and the PBR Default gateway.

One use case for this feature is Anonymous Internet Surfing.

Enable LDAP

When LDAP authentication is enabled, the VPN gateway will act as a LDAP client on behalf of the VPN user to authenticate the VPN user to the LDAP server.

Set a minimum Aviatrix VPN client software version that is allowed to connect successfully. To configure, go to OpenVPN > Edit Config > MINIMUM VPN CLIENT VERSION to set the Aviatrix VPN client version.

Available for Aviatrix VPN client only.

Add/Edit Tags

The Aviatrix Gateway is launched with a default tag name avx-gateway@private-ip-address-of-the-gateway. This option allows you to add additional AWS/Azure tags at gateway launch time that you can use for automation scripts.

Designated Gateway

If a gateway is launched with the Designated Gateway feature enabled, the Aviatrix Controller will insert an entry for each address space defined by RFC1918:

  • 10.0.0.0/8,
  • 192.168.0.0/16, and
  • 172.16.0.0/12

The target of each of these entries will point to the Aviatrix Gateway instance.

Once enabled, Transit VPC, Site2Cloud, and Encrypted Peering connections will no longer add additional route entries to the route table if the destination range is within one of these RFC1918 ranges. Instead, the Aviatrix Gateway will maintain the route table internally and will handle routing for these ranges.

Note

The Designated Gateway feature is automatically enabled on Spoke Gateways created by the Transit Network workflow.

Starting with release 3.3, you can configure the CIDR range(s) inserted by the Aviatrix Controller when the Designated Gateway feature is enabled. To do this, follow these steps:

  1. Log in to your Aviatrix Controller.

  2. Go to the Gateway page.

  3. Select the designated gateway to modify from the list and click Edit.

    Note

    You must enable the Designated Gateway feature at the gateway creation time.

  4. Scroll down to the section labeled Edit Designated Gateway.

  5. Enter the list of CIDR range(s) (separate multiple values with a comma) in the Additional CIDRs field.

  6. Click Save.

edit-designated-gateway

Once complete, your route table(s) will be updated with the CIDR range(s) provided.

Security Policy

Starting Release 3.0, gateway security policy page has been moved Security > Stateful Firewall. See this guide.

High Availability

There are 3 types of high availability on Aviatrix: “Gateway for High Availability,” “Gateway for High Availability Peering,” and Single AZ HA.

Gateway for High Availability

This feature has been deprecated. It is listed here for backward compatibility reasons.

When this option is selected, a backup gateway instance will be deployed in a different AZ if available. This backup gateway keeps its configuration in sync with the primary gateway, but the configuration does not take effect until the primary gateway fails over to the backup gateway.

When using Terraform, this option is described by parameter "ha_subnet" by resource gateway.

Gateway for High Availability Peering

When this option is selected, a backup gateway instance will be deployed in a different AZ if available.

If you have built Aviatrix Encrypted Peering and need HA function for tunnel down fail over, you can select this option. This backup gateway keeps backup VPN tunnels up, ready for fail over.

If you use Aviatrix Gateway for Egress Control function and need HA function, you should select this option. This option will try to load balance the traffic from different route tables to primary and backup gateways.

If you consider deploying Aviatrix Transit Network, high availability is built into the workflow. You do not need to come to this page.

When using Terraform, this option is described by parameter "peering_ha_subnet" by resource gateway.

Gateway Single AZ HA

When enabled, the Controller monitors the health of the gateway and restart the gateway if it becomes unreachable. No secondary gateway is launched in this case.

When using Terraform, this option is described by parameter "single_az_ha" by resource gateway.

Gateway Resize

You can change Gateway Size if needed to change gateway throughput. The gateway will restart with a different instance size.

To configure, click Gateway on the left navigation panel, select the desired gateway, and click Edit. Scroll down to Gateway Resize and in the dropdown menu, select the new gateway instance size. Click Change. The gateway instance will be stopped and restarted again with the new instance size. o

If you use Availability Set when launching Azure gateways, different classes of VM sizes can be resized interchangeably.

Source NAT

You can enable and disable NAT function after a gateway is launched. NAT function enables instances on private subnets in AWS, GCP, or OCI to access the Internet. When NAT is enabled, all route tables for private subnets in the VPC/VNet are programmed with a route entry that points the gateway as the target for route entry 0.0.0.0/0.

Three modes of Source NAT are supported:

1. Single IP

When Single IP is selected, the gateway’s primary IP address is used as source address for source NAT function. This is the simplest and default mode when you enable NAT at gateway launch time.

2. Multiple IPs

When Multiple IPs is selected, the gateway translates the source address to the pool of the multiple IPs in a round robin fashion. The multiple IPs are the secondary IP addresses of the gateway that you need to setup first.

3. Customized SNAT

When Customized SNAT is selected, the gateway can translate source IP address ranges to different SNAT address and ports, as shown below. Check out this link for an example configuration.

SNAT-customize

Sync to HA Gateway feature is an option to help users automatically duplicating NAT rules to HA peer gateway. By default, this function is disabled on Customized SNAT meaning users need to configure NAT rules manually on HA peer gateway even NAT rules are same.

Field Value
SRC CIDR This is a qualifier condition that specifies a source IP address range where the rule applies. When left blank, this field is not used.
SRC PORT This is a qualifier condition that specifies a source port that the rule applies. When left blank, this field is not used.
DST CIDR This is a qualifier condition that specifies a destination IP address range where the rule applies. When left blank, this field is not used and a default route 0.0.0.0/0 pointing to Aviatrix Gateway will be programmed into Cloud platform routing table.
DST PORT This is a qualifier condition that specifies a destination port where the rule applies. When left blank, this field is not used.
PROTOCOL This is a qualifier condition that specifies a destination port protocol where the rule applies. When left blank, this field is not used.
INTERFACE This is a qualifier condition that specifies output interface where the rule applies. When left blank, this field is not used.
CONNECTION This is a qualifier condition that specifies output connection where the rule applies. When left blank, this field is not used.
MARK This is a qualifier condition that specifies a tag or mark of a TCP session where the rule applies. When left blank, this field is not used.
SNAT IPS This is a rule field that specifies the changed source IP address when all specified qualifier conditions meet. When left blank, this field is not used. One of the rule fields must be specified for this rule to take effect. Multiple translated source IP addresses are supported, they are specified as a range, for example, 100.100.1.5 - 100.100.1.10
SNAT PORT This is a rule field that specifies the changed source port when all specified qualifier conditions meet.. When left blank, this field is not used. One of the rule fields must be specified for this rule to take effect.
APPLY ROUTE ENTRY This is an option to program the route entry “DST CIDR pointing to Aviatrix Gateway” into Cloud platform routing table.
EXCLUDE ROUTE TABLE This field specifies which VPC private route table will not be programmed with the default route entry. Users can combine this with APPLY ROUTE ENTRY enabled.

Destination NAT

Destination NAT (DNAT) allow you to change the destination to a virtual address range.

There are multiple optional parameters you can configure to meet your requirement. Follow this example to see how DNAT can be used, as shown below:

dnat-port-mapping

Sync to HA Gateway feature is an option to help users automatically duplicating NAT rules to HA peer gateway. By default, this function is enabled on DNAT.

Field Value
SRC CIDR This is a qualifier condition that specifies a source IP address range where the rule applies. When left blank, this field is not used.
SRC PORT This is a qualifier condition that specifies a source port that the rule applies. When left blank, this field is not used.
DST CIDR This is a qualifier condition that specifies a destination IP address range where the rule applies. When left blank, this field is not used and a default route 0.0.0.0/0 pointing to Aviatrix Gateway will be programmed into Cloud platform routing table.
DST PORT This is a qualifier condition that specifies a destination port where the rule applies. When left blank, this field is not used.
PROTOCOL This is a qualifier condition that specifies a destination port protocol where the rule applies. When left blank, this field is not used.
INTERFACE This is a qualifier condition that specifies output interface where the rule applies. When left blank, this field is not used.
CONNECTION This is a qualifier condition that specifies output connection where the rule applies. When left blank, this field is not used.
MARK This is a rule field that specifies a tag or mark of a TCP session when all qualifier conditions meet. When left blank, this field is not used.
DNAT IPS This is a rule field that specifies the translated destination IP address when all specified qualifier conditions meet. When left blank, this field is not used. One of the rule field must be specified for this rule to take effect. Multiple translated source IP addresses are supported, they are specified as a range, for example, 100.101.2.5 - 100.101.2.10
DNAT PORT This is a rule field that specifies the translated destination port when all specified qualifier conditions meet. When left blank, this field is not used. One of the rule field must be specified for this rule to take effect.
APPLY ROUTE ENTRY This is an option to program the route entry “DST CIDR pointing to Aviatrix Gateway” into Cloud platform routing table.
EXCLUDE ROUTE TABLE This field specifies which VPC private route table will not be programmed with the default route entry. Users can combine this with APPLY ROUTE ENTRY enabled.

Monitor Gateway Subnet

This feature allows you to enforce that no unauthorized virtual machine (EC2/VM/GCE) instances are being launched on the gateway subnet. Since an Aviatrix gateway must be launched on a public subnet in AWS, GCP, or OCI, if you have policies that no virtual machine instances can be launched on public subnets, this feature addresses that concern.

When it is enabled, the Controller periodically monitors the selected subnet where gateway is launched from. If it detects virtual machine instances being launched, the Controller sends an alert email to admin and immediately stops the instance(s).

You can exclude certain instances by entering instance IDs separated by commas.

To configure:

  1. Go to the Gateway page.
  2. Highlight a gateway and click Edit.
  3. Scroll down to Monitor Gateway Subnet.
  4. Click Enable and then optionally enter excluding instance ID(s). Click OK when finished.

Click Disable to remove all excluding instance ID(s).

Gateway State

Gateway state is dictated by the following factors.

  • State of the gateway as reported by the cloud provider.
  • Connectivity between Controller and gateway over HTTPS (TCP port 443).
  • Status of critical services running on the gateway.

An Aviatrix Gateway could be in any of the following states over its lifetime.

WAITING: This is the initial state of a gateway immediately after the launch. The gateway will transition to UP state when the controller starts receiving keepalive messages from the newly launched gateway.

UP: The gateway is fully functional. All critical services running on the gateway are up and the gateway and the controller are able to exchange messages with each other.

DOWN: A gateway can be down under the following circumstances.

  • The Gateway and the Controller could not communicate with each other over HTTPS (443).
  • The Gateway instance (VM) is not in running state.
  • Critical services are down on the gateway.

CHECK: The Controller did not receive expected number of keepalive messages from the gateway during a health check. This is usually caused by the controller security group port 443 not being open to the gateway’s EIP.

UPGRADE-FAIL: The gateway could not be upgraded due to some failure encountered during the upgrade process. To upgrade the gateway again, go to the section “FORCE UPGRADE” which can be found here.

Troubleshoot > Diagnostics > Gateway

CONFIG-FAIL: Gateway could not process a configuration command from the Controller successfully. Please open a support ticket at Aviatrix Support Portal for assistance.

If a gateway is not in UP state, please perform the following steps.

  • Examine the security policy of the Aviatrix Controller instance and make sure TCP port 443 is opened to traffic originating from gateway public IP address.
  • Examine the security policy of the gateway and make sure that TCP port 443 is opened to traffic originating from controller public IP address. This rule is inserted by the Aviatrix Controller during gateway creation. Please restore it if was removed for some reason.
  • Make sure network ACLs or other firewall rules are not configured to block traffic between controller and gateway over TCP port 443.

Gateway Keepalives

As mentioned in the previous section, the gateway sends periodic keepalive messages to the Controller. The following templates can be used to control how frequently gateways send keepalives and how often the Controller processes these messages, which in turn will determine how quickly the Controller can detect gateway state changes.

Template name Gateway sends keepalive Controller runs health checks
Fast every 3 seconds every 7 seconds
Medium every 12 seconds every 1 minute
Slow every 1 minute every 5 minute

Medium is the default configuration.

A gateway is considered to be in UP state if controller receives at least 2 (out of a possible 5) messages from that gateway between two consecutive health checks.

For Fast configuration, the Controller determines the gateway state on 2 samples, so the gateway failure detection time is between 7 seconds and 14 seconds.

For example, with medium setting, gateway down detection time is between 1 minute plus 36 seconds to 2 minutes.

The keepalive template is a global configuration on the Controller for all gateways. To change the keep alive template, go to:

Settings > Advanced > Keepalive.

In the dropdown menu, select the desired template.

Edit Secondary IPs (for AWS)

This feature allows you to add secondary IP addresses to gateway instances for AWS. The format to enter the field is, for example,

172.32.0.20 (for single secondary IP address)
172.32.0.20-172.32.0.22 (for a multiple consecutive secondary IP addresses)

The main use case for this feature is to enable you to configure source NAT function that maps to multiple IP addresses, instead of a single one. When used for this purpose, you need to go to AWS console to first allocate an EIP, then associate each secondary IP with an EIP to complete the function.

This feature is currently available for AWS.

Use VPC/VNet DNS Server

When enabled, this feature removes the default DNS server for the Aviatrix Gateway and instructs the gateway to use the VPC/VNet DNS server configured in VPC/VNet DHCP option.

When disabled, the Aviatrix Gateway will revert to use its built-in (default) DNS server.

Here is one example use case to enable this feature:

If you enable Logging on the Aviatrix Controller, all Aviatrix Gateways forward their log information to the configured log server. But if the log server is deployed on-prem with a private DNS name, the Aviatrix gateway’s default DNS server cannot resolve the domain name of the private log server. By enabling the VPC/VNet DNS server, the gateway will start to use the VPC/VNet DNS server which should resolve the private DNS name of the log server.

Note

When enabling this feature, we check to make sure the gateway can indeed reach the VPC/VNet DNS server; if not, this command will return an error.

A caveat is noted when this feature is applied to a Transit Network.

Insane Mode Encryption

When this option is selected, the Aviatrix Controller will look for a spare /26 subnet segment to create a new public subnet “-insane” and launch the gateway on this subnet. The instance sizes that support Insane Mode are c5 series and m5 series.

Insane Mode encryption is an Aviatrix technology that enables 10Gbps and higher IPsec performance between two single Aviatrix Gateway instances or between a single Aviatrix Gateway instance and on-prem Aviatrix appliance.

For more info, read this document to learn all about Aviatrix Insane Mode for high performance Transit Network.

Encrypt EBS Volume (for AWS)

This feature only applies to AWS gateway. When enabled, the gateway EBS volume is encrypted. To configure, go to Gateway page, select the gateway, and click Edit. Scroll down to Encrypt Volume and click Encrypt. Note the encrypting action takes up to 15 minutes. For more details, open this link

Customize Spoke VPC Routes

This feature allows you to customize Spoke VPC/VNet route table entry by specifying a list of comma separated CIDRs. When a CIDR is inserted in this field, automatic route propagation to the Spoke(s) VPC/VNet will be disabled, overriding propagated CIDRs from other spokes, transit gateways and on-prem network. One use case of this feature is for a Spoke VPC/VNet that is customer facing and your customer is propagating routes that may conflict with your on-prem routes.

When this is enabled on an Aviatrix Transit Gateway, all Spoke VPC/VNets route tables are customized.

When it is enabled on an Spoke Gateway, only that gateway VPC/VNet route table is applied. This feature does not apply to AWS Transit Gateway (TGW) attached Spoke VPCs.

To disable this feature, empty the field and click Save. The on-prem learned routes will be propagated in to the Spoke VPC/VNet routes.

Filter Learned Routes to Spoke VPC/VNet

This feature allows you to filter on-prem network CIDRs to Spoke VPC/VNet route table entry. The unwanted list of CIDRs should be entered as input. This list of CIDRs should be comma separated. One use case of this feature is for a Spoke VPC/VNet that is customer facing and you do not wish your customer to access all your on-prem network CIDRs.

The list of the filtered out CIDRs can be a super set of on-prem learned routes. For example, if the on-prem learned routes are 100.10.0.0/24 and 100.10.1.0/24, you can enter 100.10.0.0/16 to filter out both routes.

If the filtered out CIDR is a subnet of on-prem learned CIDR, the filtered CIDR won’t work.

When it is applied to the Aviatrix Transit Gateway, all attached Spoke VPC/VNets will filter on the configured routes.

When it is applied to a specific Spoke VPC/VNet, only the Spoke VPC/VNet route table is affected. This feature does not apply to AWS Transit Gateway (TGW) attached Spoke VPCs.

Customize Advertised Spoke VPC CIDRs

This route policy enables you to selectively exclude some VPC/VNet CIDRs from being advertised to on-prem.

One use case is if you have Spoke VPC/VNets that have multiple CIDR blocks, among which some of them are overlapping. If you attach these Spoke VPC/VNets, the Aviatrix Controller will reject them as there are overlapping CIDRs. By excluding the overlapping CIDRs, you will be able to attach the Spoke VPC/VNets.

When this policy is applied to an Aviatrix Transit Gateway, the list is an “Exclude list” meaning the CIDRs in the input fields will be excluded from advertising to on-prem.

When this policy is applied to an Aviatrix Spoke Gateway, the list is an “Include list” meaning only the CIDRs in the input fields are advertised to on-prem. In Release 4.7 and later, the “Include list” can be network ranges that are outside of the Spoke VPC/VNet CIDR.

Transit Peers As Backup to On-prem

When this feature is enabled on a Transit Gateway, every one of its remote Transit Peers does not advertise to its on-prem network all the Spoke VPCs and on-prem routes learned by this Transit Gateway, except when the link to the on-prem goes down at which point one of the remote Transit Peers starts to advertise to its on-prem network all the Spoke VPC/VNets and on-prem routes learned by this Transit Gateway.

One use case is a connected multi-site on-prem network, where each site is connected to the cloud via Aviatrix Transit Gateways and the Transit Gateways are full mesh connected. In such case, each Transit Gateway learns all Spoke VPC/VNets and on-prem network CIDRs. Without enabling this feature, route conflicts happen for the on-prem network. With this feature enabled, there is no route conflict to on-prem and any Spoke VPC/VNet has a redundant route to on-prem.

Jumbo Frame

Jumbo Frame improves Aviatrix Gateway throughput performance. This feature is enabled by default for AWS and OCI. It is not supported for Azure or GCP.

To enable Jumbo Frame for an Aviatrix Gateway:

  1. In Aviatrix Controller, from the left sidebar, select GATEWAY.
  2. On the Gateways page, select the gateway for which you want to enable Jumbo Frame and click Edit.
  3. Scroll down to Jumbo Frame and click Enable.

IPv6 (for AWS)

IPv6 can be enabled on an Aviatrix Gateway deployed in AWS. One use case is to use IPv6 to resolve overlapping VPC CIDRs when doing encrypted peering. This use case requires both the VPC and EC2 instances have IPv6 enabled.

When this option is enabled, Controller automatically enables IPv6 on the VPC CIDR and the subnet where the gateway is launched. It is your responsibility to enable IPv6 on any other subnets and instances. Use Migrating to IPv6 if you need help.

When building an encrypted tunnel between two identical VPC CIDRs to for networking between the instances in each VPC, the Controller uses the gateway’s IPv4 EIP as tunnel end point. Find out more in Use IPv6 for User VPN Access.

ActiveMesh Mode

ActiveMesh is officially supported in 5.1 release. If you deploy ActiveMesh gateway in the 5.0 beta code, please upgrade to the latest 5.1 before running it in production environment.

When an Aviatrix Transit Gateway has ActiveMesh mode enabled, both primary and backup gateway forward packets in ECMP and active/active state.

New and advanced features such as Multi-sites Transit solution where the Aviatrix Transit Gateway connects to multiple remote sites is only supported with ActiveMesh mode enabled on the Aviatrix Transit GW.

To enable ActiveMesh mode after the Transit Gateway or Spoke Gateway is enabled, go to Gateway, highlight the gateway and click Edit. Scroll down to find ActiveMesh Mode, click Enable.

OpenVPN is a registered trademark of OpenVPN Inc.