HA Connector pairs

  • 5 minute read
Prev Next

The AppGate ZTNA system supports active-passive high availability (HA) operation of Connector pairs on traditional networks that support ARP and in AWS. Connectors also support the internal failover mechanism between multiple Gateways within a Site. The Connector pair both run the keepalived daemon, which monitors the other Connector using VRRP. Failover is triggered by the failure of the active Connector, whereupon the virtual router redundancy protocol (VRRP) will re-assign which one is active, the VIP will be reassigned, and the passive Connector will become active.

This section describes how you can configure Connector appliances to take advantage of this functionality.

Use the Appliances > Functions UI to create Connectors

Before you start

Ensure you have a single Connector (Express) or Connector (Advanced) fully configured, tested, and operational. Only the Connector (Express) requires that a Site be specified. However, there is a good reason to specify one for the Connector (Advanced) when it comes to HA. sdpctl will use the Site setting to ensure that the Connectors on any given Site will not be upgraded at the same time.

Create an HA Connector pair

You can create and deploy a second Connector appliance that shares a VIP and replicates all resource groups. The AppGate ZTNA system uses a match on the virtual IPs to associate the HA pair. The two appliances will negotiate which one is to become active. If the active Connector goes offline then the second Connector will become active. You can see which one is active in the dashboard. The Connector whose status for Network IP addresses displays both the actual IP and the virtual IP is currently the active Connector.

You can create an HA Connector pair by cloning a Connector or creating a second Connector and manually duplicating its HA and resource group configurations.

To create an HA Connector pair, perform the following steps:

  1. Navigate to Appliances (System > Appliances),

  2. Select your first Connector appliance to open the Edit Appliance page.

  3. In the Functions tab under High Availability Configuration, enable Assign Virtual IP interface for HA Connectors (IPv4 or IPv6).

If you are cloning the appliance:

  1. After configuring the appliance, in the Edit Appliance page select Actions > Clone.

  2. In the cloned appliance, make necessary changes to the Name and Interfaces fields.

If you are manually creating the second Controller:

  1. In the Appliances page select +Add to create a new appliance.

  2. When following the steps to configure a Controller, duplicate the settings of the first Controller in the High Availability Configuration section.

  3. In the Resource Group Configuration section use the Get configuration from existing Connector Clients dropdown to select the other Connector. This will create a clone of the resource group(s) from the first appliance.

When you have finished configuring the appliance, deploy it alongside the first one. If you are using a cloud environment, see the Deploying HA Connector pairs in cloud environments section.

Operation of an HA Connector pair

When operating in HA mode, VRRP is used to start or stop clients on the Connectors according to the VRRP state. Because clients are not always managed by VRRP, such as when multiple NICs are in use, there needs to be some means of knowing which clients should be managed by VRRP.

For Connector (Advanced) this is done by checking:

  • the local resources are in the same subnet as the NIC

Advanced connector settings showing device ID and NIC configuration for network resources.

or

  • the NIC defined in the Local Resources is the same as the NIC selected in the High Availability Configuration

Configuration settings for high availability with virtual IP interface selection.

For Connector (Express), it is assumed that when there is a High Availability Configuration then clients are always managed by VRRP.

Manage HA Connector pairs

To make changes to your HA Connectors:

  1. On one of the Connectors, Navigate to Appliances > Functions > Resource Group Configuration.

  2. If you do not want to edit the active Connector, reboot it. This will cause the second Connector to become the active one while you are editing.

  3. When you have completed editing the first Connector, save your changes.

  4. Edit the second Connector and delete any resource groups you changed. Then use the Get configuration from existing Connector Clients option to copy over the changes you made to the first Connector.

  5. When you are finished, click Save. The HA Connector pair are now updated and operational.

Deploying HA Connector pairs in Cloud environments

HA operation relies on the use of the VRRP and ARP/CloudAPIs, meaning that HA Connector deployments can only work in environments which have ARP or Cloud API support. For unsupported Cloud environments, use snapshots and start a replacement instance if required.

AWS

AWS networking does not support ARP, meaning we can't make use of the standard HA implementation for Connectors in AppGate (VIP assignment). AWS HA Connector implementation makes use of the EC2 API to assign or unassign the VIP from the ENIs in the instance.

In addition to the setup detailed above there are some additional steps that are required:

Instance IAM role

Each Controller EC2 instance needs to have an IAM role with the following actions:

  • ec2:UnassignPrivateIpAddresses

  • ec2:AssignPrivateIpAddresses

  • ec2:DescribeRouteTables

  • ec2:ReplaceRoute

The resource for those actions should be the ENIs in the EC2 instances.

Set up the route table with a route from the resource IP to the Master Connector instance’s network interface. Connector appliances will automatically update these routes to point to the Master Connector’s network interface during failover.

The route table must have an explicit subnet association with the subnet the Connectors are in. Routes need to show when you run the following:

aws ec2 describe-route-tables —filters Name=association.subnet-id,Values="subnet-XXXX"

The resource for those actions should be the ENIs in the EC2 instances.

Example:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "PrivateIpAddressActions",
			"Effect": "Allow",
			"Action": [
				"ec2:UnassignPrivateIpAddresses",
				"ec2:AssignPrivateIpAddresses"
			],
			"Resource": [
				"arn:aws:ec2:eu-north-1:194335033129:network-interface/eni-01e1b1cc75622bbb0",
				"arn:aws:ec2:eu-north-1:194335033129:network-interface/eni-077c1f94b2a4b59d4"
			]
		},
		{
			"Sid": "RouteTableActions",
			"Effect": "Allow",
			"Action": [
				"ec2:DescribeRouteTables",
				"ec2:ReplaceRoute"
			],
			"Resource": "arn:aws:ec2:eu-north-1:194335033129:route-table/rtb-0c5eb265"
		}
	]
}

Instance security group

Each EC2 connector instance should allow VRRP traffic (protocol 112) from the other EC2 Connector instances.

VPC subnet

Specifying IP addresses that will be used by the Connectors:

  • Assign a static private IP address to the ENI of each EC2 Connector instance. This is due to the way AppGate ZTNA has implemented HA.

  • Add a CIDR reservation for the chosen VIP (so it can never be assigned to any other machine in that subnet).

In the AWS VPC routing table, update the routing table so the resource destination is set to the master Connector NIC. The Connector will automatically update the routing table so that the destination will always be set to the master Connector NIC on failover.

AppGate ZTNA configuration

Due to the way AppGate ZTNA has implemented HA, the static private IP addresses used above also need to be assigned in the two Connector appliance interface configurations. The DHCP option must also be enabled at the same time for compatibility reasons.

Related articles