About External Connection Settings

This document describes the options that you can configure for an Aviatrix gateway Site2Cloud (S2C) external connection to remote devices, such as on-premises router or firewall.

You can create external connections in Aviatrix CoPilot by going to CoPilot > Networking > Connectivity > External Connections (S2C) tab, then from the + External Connection dropdown menu, select External Device.

In this document, Local Gateway refers to the Aviatrix gateway that you want to connect to a remote device.

General Configuration

Type

Type refers to the VPN tunneling and routing protocol. You can select from:

  • BGP over IPsec: Builds VPN tunnel using the IPsec tunneling protcol and Border Gateway Protocol (BGP) routing.

  • BGP over GRE: Builds VPN tunnel using the GRE tunneling protocol and BGP routing.

  • BGP over LAN: Builds VPN tunnel over the LAN interface without using a tunneling protocol (such as IPsec or GRE) and BGP routing.

  • Static Routing over IPsec: Builds VPN tunnel using the IPsec tunneling protcol and Static routing.

Local Gateway

The Local Gateway on which you want to create an external connection to a remote device.

Local Subnet CIDR(s)

(Static Route connections only) The Local Gateway CIDR(s) to route traffic to the cloud destination.

Remote Subnet CIDR(s)

(Static Route connections only) The remote network CIDR(s) to route traffic to the remote network destination.

IPsec Configuration

Attach Over

The underlying infrastructure of your network.

  • Private Network: Your underlying infrastructure is a private network, such as AWS Direct Connect and Azure ExpressRoute. When this option is selected, BGP over IPsec runs over private IP addresses.

  • Public Network: Your underlying infrastructure is a public network or the internet. When this option is selected, BGP over IPsec runs over public IP addresses.

Jumbo Frame

Jumbo Frame improves the performance throughput between the Local Gateway and the remote device.

You must first enable Jumbo Frame on the Local Gateway before creating an external connection. Enabling Jumbo Frame on the Local Gateway enables it on the WAN and LAN interfaces of the gateway.

  • Jumbo Frame is only supported on private connections that support Jumbo Frame.

  • For Transit and Spoke Gateways:

    • Jumbo Frame is supported for AWS and OCI only; it is not supported for Azure and GCP.

    • Jumbo Frame is supported with High Performance Encryption and BGP over IPsec and BGP over LAN connections only. High Performance Encryption must be enabled on all gateways in the end-to-end path of the traffic flow.

  • For Edge Transit and Spoke Gateways:

    • (Edge Transit Gateway) Jumbo Frames can be enabled on the Edge Transit Gateway when creating BGP over IPsec or BGP over GRE external connection to remote devices.

    • (Edge Spoke Gateway) Jumbo Frame is enabled (by default) for BGP over LAN connections, when the Edge Spoke Gateway is created.

Algorithms

Aviatrix supports the following default encryption algorithms to authenticate the communication between the Aviatrix gateway and the remote device. This feature is not applicable for BGP over GRE, BGP over LAN connections.

  • Phase 1 Authentication: Default is SHA-256

  • Phase 1 DH Groups: Default is 14

  • Phase 1 Encryption: Default is AES-256-CBC

  • Phase 2 Authentication: Default is HMAC-SHA-256

  • Phase 2 DH Groups: Default is 14

  • Phase 2 Encryption: Default is AES-256-CBC

You can also choose to customize or modify the default values.

Internet Key Exchange

The Internet Key Exchange (IKE) protocol is used for authentication and encryption of packets between the Aviatrix gateway and the remote device. Aviatrix gateways support IKE version 1(IKEv1) and IKE version 2(IKEv2) to establish secure connections to remote sites.

Authentication Configuration

Authentication Method

(Static Routing over IPsec connections only) You can authenticate the connection using Pre-Shared Key (PSK) or certificate-based authentication.

Pre-Shared Key

(Optional) Pre-Shared Key(PSK) is a string of random characters that is used to authenticate the BGP tunnel connection between the Aviatrix gateway and the remote device. You must ensure that this key is the PSK that is configured for your remote device. If you do not specify one, it is auto-generated. You can view the auto-generated PSK value when you download the external connection’s configuration (see Download the External Connection Configuration).

For ActiveMesh connections, if you want the tunnels that are created to have different PSK values, you will need to enter the PSKs separated by a comma.

500
  • A comma denotes two separate PSK values. Do not include a comma in a single PSK string.

  • The double quote ASCII character (“) is not allowed. A tunnel connection cannot be established if the PSK string contains the double quote character.

Certificate-Based

You can use certificate-based authentication only if a remote CA certificate has been uploaded or imported.

When creating your external connection, you enter the Subject Alternative Name(SAN) of the certificate for Remote Identifier SAN. If the remote endpoint is highly available(HA) devices, add a second connection row and enter the SAN of the remote HA gateway in the Remote Identifier SAN field.

The SAN (Subject Alternative Name) is a way to indicate that multiple domains can be secured by the same certificate.

Remote Identifier SAN

(Static Routing over IPsec only) Aviatrix only supports IP_ADDRESS and KEY_ID as the IKE identity type for the remote identifier in the pre-shared key authentication. The IP_ADDRESS must be a valid IPv4 IP address. The KEY_ID is a remote device ID during the key authentication.

By default, Aviatrix configures the public IPv4 address of the peer device as the Remote Identifier for pre-shared key authentication. You can adjust this setting to the private IPv4 address of the peer device.

A Remote Identifier is used to identify the remote end of the tunnel and establish the IPsec connection. You can enter a DNS, IP address, or email address.

BGP Configuration

Local ASN

The BGP AS number the Local Gateway will use to exchange routes with the remote device.

ActiveMesh

ActiveMesh enables full mesh peering for failover redundancy. When ActiveMesh is disabled, point-to-point tunnels are created instead of full mesh.

When you have a pair of primary and highly available (HA) Local Gateways and HA remote devices:

  • With ActiveMesh: four tunnels are created (primary and HA Local Gateways to the primary and HA remote devices).

  • Without ActiveMesh: two tunnels are created (primary local to primary remote, HA local to HA remote).

When you have one Local Gateway with HA remote devices or HA Local Gateways with one remote device,

  • With ActiveMesh: two tunnels are created (primary to primary, primary to secondary)

  • Without ActiveMesh: one tunnel is created (primary to primary)

By default, ActiveMesh is On for Transit and Spoke Gateway BGP over IPsec and BGP over GRE connections.

You can turn On ActiveMesh for these connections:

  • Transit and Spoke Gateway BGP over LAN connections in Azure and GCP

  • Edge Transit and Spoke Gateway BGP over LAN connections

  • Edge Transit Gateway BGP over IPsec and BGP over GRE connections over private network.

    For Edge Transit Gateways in Megaport, ActiveMesh is disabled for external connections over private networks. Megaport only supports point-to-point connections.

BFD

Bidirectional Forwarding Detection (BFD) is a network protocol that enables detection of a link or node failure between the Local Gateway and its BGP peer.

Manual CIDR Approval

An approval process for gateway-learned CIDRs. This approval process improves security for your network.

When Manual CIDR Approval is On, if an unapproved CIDR address attempts to access the connection, an email notification is sent to the administrator to approve or block access before the CIDRs are propagated to the Spoke VPC/VNet route tables.

Manual CIDR Approval is Off and disabled by default unless the Local Gateway you select has Learned CIDR Approval turned On; the Connection option selected, and the BGP connection selected. Then it is On by default (not editable).

The BGP communities to advertise to the BGP peer.

Before you can configure additional BGP communities at the connection-level, the gateway advertise to BGP communities to peers setting must be enabled either from the global BGP communities setting or at the gateway-level.
  • Same as Gateway: This is the default setting for the connection. The gateway advertises the BGP communities that were received or tagged on the route.

  • Block Advertisement: The gateway will not to advertise BGP Communities received from any BGP peer or attachment.

  • Add Additional Communities: The gateway will advertise the additional BGP communities specified to the external BGP peer in addition to the BGP communities that were received or tagged on the route. You can choose to enter a numeric BGP community tag or select from the dropdown menu.

    Aviatrix supports:

    • Numeric You can specify numeric BGP community tags specified as two 16-bit numbers (0-65535):(0-65535).

    • No-Advertise When a No-Advertise BGP community is attached to a route from an external BGP peer, the Aviatrix gateway will not advertise the route to any gateway attachments or external BGP peers.

      Aviatrix gateways only support eBGP to external BGP peers.
    • No-Export When a No-Export BGP community is attached to a route from an external BGP peer, the Aviatrix gateway will not advertise the route to any external BGP peers and advertise only to gateway attachments.

  • Specify Communities: The gateway will advertise to the external BGP peer only these BGP communities specified and ignore the BGP communities that are already tagged on the route.

BGP Multihop

External BGP connectivity requires that the remote peer is directly connected (single-hop) to the Local Gateway.

When the remote peer is not directly connected (separated by multiple hops), you must enable BGP Multihop for the Local Gateway to establish a BGP session with a remote peer.

Tunnel Configuration

BGP over IPsec and BGP over GRE Connections

Remote Device Tunnel Destination IP

The remote device interface IP address.

Remote ASN

The BGP AS Number that the remote device will use to exchange routes with the Local Gateway.

The Remote ASN should be the same for the primary and HA Local Gateways.

BGP Local IP

(Optional) The local tunnel inner CIDR range allowed to communicate over the VPN tunnel.

BGP Neighbor IP

(Optional) The remote tunnel inner CIDR range allowed to communicate over the VPN tunnel.

Tunnel Source IP

(Edge Transit Gateway only). The Tunnel Source IP is the Edge Transit Gateway WAN interface IP address to use for the connection to the remote device.

For Transit Gateway, this setting defaults to the eth0 IP address.

Pre-Shared Key

BGP over LAN

Remote Device IP

The remote device interface IP address.

Remote ASN

The BGP AS Number of the remote device that will be used to exchange routes with the Local Gateway.

The Remote ASN should be the same for the primary and HA Local Gateways.

Local LAN IP

The Local Gateway interface IP address.

Remote LAN IP

The remote device interface IP address.

Static Routing over IPsec

Remote Device Tunnel Destination IP

(Static Routing ActiveMesh only) The remote device’s interface IP address.

Remote Device IP

The remote device’s interface IP address.

Local Gateway Instance

The Local Gateway’s IP address.

Local Tunnel IP

(Static Routing ActiveMesh only) The local tunnel inner CIDR range allowed to communicate over the tunnel.

Remote Tunnel IP

(Static Routing ActiveMesh only) The remote tunnel inner CIDR range allowed to communicate over the tunnel.

Pre-Shared Key