> ## Documentation Index > Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt > Use this file to discover all available pages before exploring further. # Connectivity > This section provides the purpose, elements, and actions performed on the Connectivity pages. This section provides the purpose, elements, and actions performed on the **Connectivity** pages. ## Purpose The **Network Attachment** page creates and manages network attachment connections that link Transit or Spoke gateways together for multi-cloud and hybrid network deployments. ## Elements Connectivity: Network Attachment * **Network Attachment table**: Displays existing network attachment connections with gateway names and connection status. * **+ Network Attachment button**: Opens the Create Network Attachment dialog to connect two gateways. * **Edit button**: Opens the Edit Network Attachment dialog to modify an existing connection. * **Delete button**: Removes a network attachment connection. ## Actions To create a network attachment between two gateways: 1. Go to **Networking** > **Connectivity** > **Network Attachment**. 2. Click **+ Network Attachment**. 3. Select the **Source Gateway** type (Transit or Spoke) and choose the source gateway. 4. Select the destination gateway from the attachment list. 5. Click **Save**. The new network attachment appears in the Network Attachment table. ### Parameter Details | CoPilot Parameter Name | Description | | ---------------------- | --------------------------------------------------------------------------------------------------------- | | Source Gateway | The Transit or Spoke gateway that initiates the network attachment. This field is read-only when editing. | | Transit Gateway 1 | The first Transit gateway in the attachment connection. | | Transit Gateway 2 | The second Transit gateway in the attachment connection. | | Spoke Gateway 1 | The first Spoke gateway in the attachment connection. | | Spoke Gateway 2 | The second Spoke gateway in the attachment connection. | | Connection Status | The current status of the network attachment connection. | To delete a network attachment: 1. Go to **Networking** > **Connectivity** > **Network Attachment**. 2. Locate the connection in the table and click the **Delete** button. 3. Confirm the deletion. The network attachment is removed from the table. ## Purpose The **External Connections (Site2Cloud)** page configures and manages Site2Cloud connections between Aviatrix Gateways and external devices. ## Elements Connectivity: External Connections (S2C) * **+ External Connection button**: Starts the workflow to create a new External Device, AWS Virtual Gateway, Azure Virtual Network Gateway, or Microsoft SSE Solution connection. * **BGP Settings button**: Configures BGP settings to receive notifications on overlapping BGP address and route limitations, and to set the maximum BGP AS path length. * **External Connections (S2C) table**: Displays the list of existing S2C connections and their details. * **Delete button**: Removes an existing S2C connection from the table. * **Actions button**: Download configuration files, connectivity Diagnostics, and BGP Diagnostics for an S2C connection. ## Actions To create an external Site2Cloud connection: 1. Go to **Networking** > **Connectivity** > **External Connections (S2C)**. 2. Click **+ External Connection**. 3. Select the connection type (External Device, AWS Virtual Gateway, Azure Virtual Network Gateway, or Microsoft SSE Solution). 4. Configure the connection parameters (Name, Tunnel Type, Local Gateway, Remote Device IP, subnets, and BGP settings as applicable). 5. Click **Save**. The new external connection appears in the External Connections (S2C) table. ### Parameter Details | CoPilot Parameter Name | Description | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | A name for the connection (all four workflows). | | Type |
  • **BGP over IPsec**: connect to an external device using IPsec tunneling protocol and Border Gateway Protocol (BGP) routing.
  • **BGP over GRE**: connect to an external device using GRE tunneling protocol and BGP routing.
  • **BGP over LAN**: connect to an external device using BGP routing without any tunneling protocol.
  • **Static Route-Based (ActiveMesh)**: connect to an external device using IPsec tunneling protocol and Static Route configuration with full mesh peering from the primary and highly availalble (HA) gateway instances.
| | Local Gateway | The Aviatrix gateway that connects to the remote device.
  • **BGP over IPsec** and **Static Route-Based (ActiveMesh)**: Spoke Gateways appear only if BGP is enabled on the Spoke (AWS/Azure).
  • **BGP over GRE**: Spoke Gateways appear only if BGP is enabled on the Spoke (AWS).
  • **BGP over LAN**: select the Local Gateway per the KB workflow.
| | Static Routing Type |
  • When **Type** is **Static Routing over IPsec**, set to **ActiveMesh** for the Static Route-Based (ActiveMesh) workflow.
  • Not used for the three BGP Types.
| | Remote Subnet CIDR(s) | **Static Route-Based (ActiveMesh)** only: remote network CIDR(s) to route toward the remote destination; use commas to separate multiple CIDRs. | | Attach Over |
  • **BGP over IPsec**, **BGP over GRE**, and **Static Route-Based (ActiveMesh)**: choose **Private Network** or **Public Network** (for example Direct Connect / ExpressRoute vs internet); controls whether IPsec or GRE traffic uses private or public addresses.
  • **BGP over LAN** is only supported over private networks—this field does not appear in that workflow.
| | Jumbo Frame |
  • **BGP over IPsec** and **BGP over GRE**: improves throughput between the Local Gateway and the remote device; enable Jumbo Frame on the gateway first; only on private connections that support jumbo frames.
  • Not applicable to **BGP over LAN** or **Static Route-Based (ActiveMesh)** per those KB workflows.
| | Algorithms |
  • **BGP over IPsec** and **Static Route-Based (ActiveMesh)**: **Default** or **Custom** encryption for IPsec.
  • **BGP over GRE**: **Default** or **Custom** algorithms for authenticating traffic between the Local Gateway and the on-premises device.
  • Not applicable to **BGP over LAN**.
| | Internet Key Exchange |
  • **BGP over IPsec**, **BGP over GRE**, and **Static Route-Based (ActiveMesh)**: **IKEv1** or **IKEv2** (recommended for BGP over IPsec with IPv6). If **IKEv1** with certificate authentication to another Aviatrix device, include intermediate CAs; when an intermediate CA renews, re-authentication fails until the new certificate is added.
  • Not applicable to **BGP over LAN**.
| | Local ASN |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: BGP AS number the Local Gateway uses to exchange routes with the remote device.
  • **Static Route-Based (ActiveMesh)** does not include a BGP Configuration section in the KB workflow.
| | ActiveMesh |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: when On, full mesh peering from primary and HA Local Gateways to remote devices; when Off, point-to-point tunnels.
  • The KB notes **BGP over LAN** ActiveMesh only for **Azure Route Server Integration**.
  • **Static Route-Based (ActiveMesh)** describes ActiveMesh behavior in the document intro; the workflow does not list this toggle as a separate field.
| | BFD |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: toggle BFD for rapid detection of link or node failure between the Local Gateway and the remote BGP peer.
  • Not applicable to **Static Route-Based (ActiveMesh)** in the KB workflow.
| | Manual Learned CIDR Approval |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: when On, email administrators to approve dynamically learned CIDRs before propagation to Spoke VPC/VNet route tables; when Off, learned CIDRs propagate automatically.
  • Not applicable to **Static Route-Based (ActiveMesh)** in the KB workflow.
| | Advertise BGP Communities |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: BGP communities to advertise to the BGP peer.
  • Not applicable to **Static Route-Based (ActiveMesh)** in the KB workflow.
| | BGP Multihop |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: enables BGP with a remote device that is not directly connected; must match multihop on the remote device.
  • Not applicable to **Static Route-Based (ActiveMesh)** in the KB workflow.
| | Support for IPv6 | Toggle to enable IPv6 for that connection type. | | Advertise IPv6 via IPv4 Peer | When enabled, advertises IPv6 routes over an IPv4 BGP session. | | Authentication Method | **Static Route-Based (ActiveMesh)** only: **Pre-Shared Key** or **Certificate**; for certificate authentication, select the Remote CA Certificate uploaded from the remote device. | | Remote Device Tunnel Destination IP |
  • **BGP over IPsec**, **BGP over GRE**, and **Static Route-Based (ActiveMesh)**: remote device interface IP address for the tunnel row.
  • **BGP over LAN** uses **Remote Device IP** instead (see below).
| | Remote Device IP | **BGP over LAN** only (**LAN Configuration**): remote device interface IP address. | | Remote ASN |
  • **BGP over IPsec**, **BGP over GRE**, and **BGP over LAN**: BGP AS number the remote device uses with the Local Gateway (use the same value for primary and HA gateways).
  • **BGP over LAN** uses the same semantics for Primary and HA instances.
  • Not applicable to **Static Route-Based (ActiveMesh)** in the KB workflow.
| | Advertise IPv6 via IPv4 Peer | **BGP over IPsec** only: when enabled, advertises IPv6 routes over an IPv4 BGP session. | | BGP Local IP (Optional) |
  • **BGP over IPsec**: local tunnel inner CIDR allowed over the VPN tunnel.
  • **BGP over GRE**: local tunnel inner CIDR allowed over the GRE tunnel.
  • Not applicable to **BGP over LAN** or **Static Route-Based (ActiveMesh)** (which use **Local Tunnel IP** / **Remote Tunnel IP** instead).
| | BGP Neighbor IP (Optional) |
  • **BGP over IPsec**: remote tunnel inner CIDR allowed over the VPN tunnel.
  • **BGP over GRE**: remote tunnel inner CIDR allowed over the GRE tunnel.
  • Not applicable to **BGP over LAN** or **Static Route-Based (ActiveMesh)** (which use **Local Tunnel IP** / **Remote Tunnel IP** instead).
| | BGP Neighbor IPv6 | **BGP over IPsec** only: remote tunnel inner IPv6 CIDR range. | | Local Gateway Instances | **BGP over LAN** only: Primary or HA Local Gateway instance for the LAN row. | | Local LAN IP | **BGP over LAN** only: Local Gateway interface IP address. | | Remote LAN IP | **BGP over LAN** only: remote device interface IP address. | | Local LAN IPv6 (Optional) | **BGP over LAN** only: Local Gateway interface IPv6 address. | | Remote LAN IPv6 | **BGP over LAN** only: remote device interface IPv6 address. | | Local Tunnel IP | **Static Route-Based (ActiveMesh)** only: local tunnel inner CIDR allowed over the tunnel. | | Remote Tunnel IP | **Static Route-Based (ActiveMesh)** only: remote tunnel inner CIDR allowed over the tunnel. | | Tunnel Source IP |
  • **BGP over IPsec**, **BGP over GRE**, and **Static Route-Based (ActiveMesh)**: Edge Transit Gateway can use multiple WAN interfaces—select which WAN to use; Transit Gateway defaults to the eth0 IP.
  • Not applicable to **BGP over LAN** in the KB workflow.
| | Pre-Shared Key (Optional) |
  • **BGP over IPsec**, **BGP over GRE**, and **Static Route-Based (ActiveMesh)**: PSK configured on the remote/external device; auto-generated if omitted.
  • Not applicable to **BGP over LAN** in the KB workflow.
| | Remote Identifier SAN | **Static Route-Based (ActiveMesh)** only with certificate authentication: Subject Alternative Name (SAN) of the remote CA certificate. | | Add remote peers |
  • **BGP over IPsec** and **BGP over GRE**: click **+ Remote Device** and enter the next remote IP, ASN, and tunnel fields.
  • **BGP over LAN**: click **+ Remote Device** and enter the next remote IP, ASN, and LAN fields.
  • **Static Route-Based (ActiveMesh)**: click **+ Remote Device** and enter the next remote tunnel and authentication details.
| #### AWS Virtual Gateway | CoPilot Parameter Name | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Name | Identifier for the connection to the AWS VGW. | | Local Gateway | Transit Gateway that peers with the VGW. | | Local ASN | BGP AS number the Transit Gateway uses with the VGW. | | VGW Account Name | AWS account (access account) where the VGW was created. | | VGW Region | AWS Region that contains the VGW. | | VGW ID | Unique identifier of the target Virtual Private Gateway. | | Manual CIDR Approval | When the selected gateway requires learned CIDR approval at connection level, this follows that policy; otherwise it stays off by default. | #### Azure Virtual Network Gateway | CoPilot Parameter Name | Description | | ---------------------- | ------------------------------------------------------------------------------------------------- | | Name | Identifier for the connection to the Azure VPN Gateway. | | Aviatrix Gateway | Transit Gateway that connects to the VNG (must be in the Transit VNet where the VNG is deployed). | | VNG Name | Azure Virtual Network Gateway to use for the connection. | #### Microsoft's SSE Solution | CoPilot Parameter Name | Description | | ---------------------- | ------------------------------------------------------------------------- | | Name | Identifier for the BGP over IPsec connection to Microsoft's SSE Solution. | | Local Gateway | Aviatrix Gateway (BGP-enabled) that connects to Microsoft's SSE Solution. | To configure BGP settings for Site2Cloud connections: 1. Go to **Networking** > **Connectivity** > **External Connections (S2C)**. 2. Click **BGP Settings**. 3. Configure notifications for overlapping BGP address and route limitations. 4. Set the maximum BGP AS path length. 5. Save your changes. BGP settings apply to all Site2Cloud connections using BGP. To delete an external Site2Cloud connection: 1. Go to **Networking** > **Connectivity** > **External Connections (S2C)**. 2. Locate the connection in the External Connections (S2C) table. 3. Click the **Delete** button for the connection. 4. Confirm the deletion. The connection is removed from the table. To download configuration files or run diagnostics for an S2C connection: 1. Go to **Networking** > **Connectivity** > **External Connections (S2C)**. 2. Locate the connection in the External Connections (S2C) table. 3. Click the **Actions** button for the connection. 4. Select **Download configuration files**, **Connectivity Diagnostics**, or **BGP Diagnostics** as needed. Configuration files and diagnostic results are downloaded or displayed. **BGP over LAN:** In AWS, BGP over LAN allows BGP-enabled Spoke Gateways to connect to third-party instances in the same VPC without IPsec or GRE. In Azure, it allows connection to third-party instances in the same VNet. Each connection can connect to one or at most two third-party instances. BGP over LAN is not supported for GCP, OCI, and Alibaba Cloud. For Azure, you must indicate the number of LAN interfaces (maximum eight). Adding new LAN interfaces to an Azure Spoke Gateway reboots the gateway and may cause traffic disruption. You cannot delete an interface after the Spoke Gateway is created. ## Purpose The **AWS TGW** page creates AWS Transit Gateway and manages the integration by attaching an Aviatrix Transit Gateway and other AWS resources, reviewing TGW attachments, and controlling routing and network domain connections for hybrid and multicloud deployments. ## Elements Connectivity: AWS TGW * **+ AWS TGW button**: Starts the workflow to create a new AWS Transit Gateway. * **Audit Settings button**: Turns On or Off Auto Audit (Every night) for TGW attachments. * **AWS TGW table**: Displays the list of existing AWS TGWs and their details. * **Edit button**: Modifies an existing AWS TGW from the table. * **Delete button**: Removes an existing AWS TGW from the table. * **Actions button**: Audits the AWS TGW and views the TGW routes. ## Actions To create an AWS Transit Gateway: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Click **+ AWS TGW**. 3. Configure the AWS TGW parameters (Name, Account, Region, TGW CIDR, and other settings). 4. Save the configuration. The new AWS TGW appears in the AWS TGW table. ### Parameter Details | CoPilot Parameter Name | Description | | ----------------------- | --------------------------------------------------------------------------- | | Name | Name assigned to the AWS Transit Gateway. | | TGW ID | AWS-generated identifier of the AWS Transit Gateway. | | Account | AWS account where the AWS Transit Gateway is created. | | Cloud | Cloud provider associated with the Transit Gateway. | | Region | AWS region where the Transit Gateway resides. | | FireNet Inspection Mode | Inspection mode used when integrating the AWS Transit Gateway with FireNet. | | Peered AWS TGWs | Number or list of AWS Transit Gateways peered with this gateway. | | TGW CIDR | CIDR block assigned to the AWS Transit Gateway. | To configure audit settings for TGW attachments: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Click **Audit Settings**. 3. Turn **Auto Audit (Every night)** On or Off for TGW attachments. 4. Save your changes. Audit settings apply to all AWS TGW attachments. To edit an existing AWS TGW: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Locate the AWS TGW in the table and click the **Edit** button. 3. Update the desired parameters. 4. Save your changes. Changes take effect after saving. To delete an AWS TGW: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Locate the AWS TGW in the table and click the **Delete** button. 3. Confirm the deletion. The AWS TGW is removed from the table. To audit an AWS TGW: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Locate the AWS TGW in the table and click the **Actions** button. 3. Select **Audit** to run the TGW attachment audit. The audit results are displayed. To view TGW routes: 1. Go to **Networking** > **Connectivity** > **AWS TGW**. 2. Locate the AWS TGW in the table and click the **Actions** button. 3. Select **View TGW routes**. The TGW routes are displayed. ## Purpose The **Native Peering** page manages native cloud VPC or VNet peering connections to enable direct connectivity without using Transit Gateways. ## Elements Connectivity: Native Peering * **+ Native Peering button**: Starts the workflow to create a new native peering connection. * **Native Peering table**: Displays the list of existing native peering connections and their details. * **Delete button**: Removes an existing native peering connection from the table. ## Actions To create a native peering connection: 1. Go to **Networking** > **Connectivity** > **Native Peering**. 2. Click **+ Native Peering**. 3. Configure the peering parameters (VPC/VNet pairs, regions, accounts, and CIDR blocks). 4. Save the configuration. The new native peering connection appears in the Native Peering table. ### Parameter Details | CoPilot Parameter Name | Description | | ---------------------- | ----------------------------------------------- | | Name | Name of the native peering connection. | | VPC/VNet 1 | First VPC or VNet in the peering connection. | | VPC/VNet 1 CIDR | CIDR block of the first VPC or VNet. | | Region 1 | Cloud region of the first VPC or VNet. | | Account 1 | Cloud account that owns the first VPC or VNet. | | VPC/VNet 2 | Second VPC or VNet in the peering connection. | | VPC/VNet 2 CIDR | CIDR block of the second VPC or VNet. | | Region 2 | Cloud region of the second VPC or VNet. | | Account 2 | Cloud account that owns the second VPC or VNet. | To delete a native peering connection: 1. Go to **Networking** > **Connectivity** > **Native Peering**. 2. Locate the connection in the Native Peering table and click the **Delete** button. 3. Confirm the deletion. The native peering connection is removed from the table. ## Purpose The **External CA Certificates** page manages external certificate authority certificates used to authenticate and secure Aviatrix connections. ## Elements Connectivity: External CA Certificates * **+ Certificate button**: Starts the workflow to add a new external CA certificate. * **Download Aviatrix CA Certificate button**: Downloads the Aviatrix CA certificate for external use. * **External CA Certificates table**: Displays the list of existing external CA certificates and their details. * **Delete button**: Removes an existing external CA certificate from the table. ## Actions To add an external CA certificate: 1. Go to **Networking** > **Connectivity** > **External CA Certificates**. 2. Click **+ Certificate**. 3. Upload or configure the certificate and enter the required details. 4. Save the certificate. The new certificate appears in the External CA Certificates table. ### Parameter Details | CoPilot Parameter Name | Description | | ---------------------- | -------------------------------------------------- | | Name | Name assigned to the external CA certificate. | | Unique Serial | Unique serial number of the certificate. | | Issuer Name | Certificate authority that issued the certificate. | | Common Name | Common name defined in the certificate. | | Expiration | Date and time when the certificate expires. | To download the Aviatrix CA certificate for external use: 1. Go to **Networking** > **Connectivity** > **External CA Certificates**. 2. Click **Download Aviatrix CA Certificate**. The Aviatrix CA certificate is downloaded for external use. To delete an external CA certificate: 1. Go to **Networking** > **Connectivity** > **External CA Certificates**. 2. Locate the certificate in the External CA Certificates table and click the **Delete** button. 3. Confirm the deletion. The certificate is removed from the table. ## Purpose The **Settings** page manages the internal Certificate Authority (CA) configuration used to secure external connections. ## Elements Connectivity: Settings * **Rotate Certificate button**: Rotates the internal Certificate Authority (CA) certificate used to secure external connections. * **Download Trust Bundle button**: Downloads the trust bundle containing the internal Certificate Authority (CA) certificate and the new Certificate Authority (CA) certificate. * **Certificate table**: Displays the list of existing certificates and their details. ## Actions To rotate the internal Certificate Authority (CA) certificate: 1. Go to **Networking** > **Connectivity** > **Settings**. 2. Click **Rotate Certificate**. 3. Select the new Certificate Authority (CA) certificate and click **Prepare**. The new Certificate Authority (CA) certificate is applied to the internal external connection service. To download the trust bundle containing the internal Certificate Authority (CA) certificate and the new Certificate Authority (CA) certificate: 1. Go to **Networking** > **Connectivity** > **Settings**. 2. Click **Download Trust Bundle**. The trust bundle is downloaded for external use.