About VPN Gateway Settings

This document describes the settings you can configure for an Aviatrix VPN Gateway.

VPN Gateway Creation Settings

This section describes the settings you configure when creating a VPN Gateway. You create a VPN Gateway by going to CoPilot > Cloud Fabric > UserVPN > VPN Gateways or by typing VPN Gateways in the navigation search.

Account

Your cloud provider account.

Instance Size

Instance Size is the gateway instance size.

When selecting the gateway instance size, use 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 High Performance Encryption (HPE) Mode)

c5n.9xlarge

70Gbps (with HPE Mode)

c5n.18xlarge

70Gbps (with HPE Mode)

Azure Performance Numbers (without High Performance Encryption 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 High Performance Encryption 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

If you need IPsec performance beyond 2Gbps, refer to ActiveMesh HPE Performance Benchmark.

Gateway Resize

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

High Performance Encryption

High Performance Encryption (HPE) 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.

When a gateway instance is launched with High Performance Encryption enabled, 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 High Performance Encryption are:

Cloud Provider Instance Sizes that Support HPE

AWS

t3, t3a, c5, c5n, c6in

Azure

Standard (except for B1ms, B2s, B4ms, B8ms, D1_v2, D2_v2, DS1_v2, DS2_v2, D2s_v3, D4s_v3, F2s_v2, F4s_v2)

GCP

n1-standard (except for standard-1 and standard-2), n1-highcpu (except for highcpu-2)

OCI

All instance sizes

HPE is only supported on OCI Spoke/Transit gateways.

For an overview of Aviatrix High Performance Encryption, see About High-Performance Encryption.

Instances

info

Attach to Subnet

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 the Internet gateway (IGW). To learn more about VPC and subnets, refer to this link.

If you do not have a VPC/VCN with public subnet in AWS, GCP, or OCI, you can use our Creating a VPC/VNet using CoPilot tool to create a VPC with fully populated public and private subnets in each AZ.

VPN CIDR

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.

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 (Split Tunnel)

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.

Nameservers (Optional-- Split Tunnel)

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 — Split Tunnel)

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.

split here

Enable ELB

The "Enable ELB" Load Balancer option 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.

Client Certificate Sharing

This setting is disabled by default.

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

Duplicate Connections

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.

Users can still land on different VPN Gateways under a load balancer, even though this feature is enabled.

Policy Based Routing (PBR)

Policy-Based Routing (PBR) is only supported for gateways in standard AWS cloud.

Policy Based Routing 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.

Authentication — LDAP

Authentication options are:

About VPN Gateway General Settings

This section describes the settings you can configure for a VPN Gateway after it has been created.

Enable VPN NAT

This feature 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.

Use VPC/VNet DNS Server

The Use VPC/VNet DNS Server feature enables you to set the default DNS server for the Aviatrix gateway.

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

When this feature is Off, the Aviatrix Gateway will revert to use its built-in (default) DNS server.

When enabling this feature, the Controller checks to make sure the gateway can indeed reach the VPC/VNet DNS server; if not, an error is returned.

For more information, see Using VPC/VNet DNS Server.

Jumbo Frame

Jumbo Frame improves Aviatrix Gateway throughput performance.

  • Jumbo Frame is enabled by default for AWS and OCI. It is not supported for Azure or GCP.

  • If the gateway is used in a Transit FireNet configuration, ensure that the associated firewall also has Jumbo Frame enabled.

GRO/GSO

The GRO/GSO feature enables you to configure the gateway interface and enable or disable Generic Receive Offload (GRO) and Generic Segmentation Offload (GSO).

GRO/GSO is On by default to improve performance. You can set this feature to Off to minimize out of order packets for sensitive applications (like FTP), but there will be a performance throughput penalty.

Gateway Single AZ HA

The Gateway Single AZ HA feature enables the Aviatrix Controller to monitor the health of the gateway instance and restart the gateway instance if it becomes unreachable. Gateway Single AZ HA is enabled by default.

Using Gateway Single AZ HA, you can select the gateway instance to restart.

When Gateway Single AZ HA status is On, the Aviatrix Controller attempts to restart the gateway instance. When status is Off, Controller does not attempt to restart the gateway instance.

If you’re using Terraform to create Aviatrix gateways, you must enable the single_az_ha flag in the aviatrix_gateway resource. See Aviatrix Provider.

Change Interface(s) RX Queue Size

Using the Change Interface(s) RX Queue Size, you can select a gateway and set the gateway’s interface(s) RX Queue Size.

  • A larger RX queue size introduces high latency in forwarding packets.

  • A smaller RX queue size has low latency but will drop packets early when forwarding packets.