--- title: "Connectors" slug: "connectors-v6-5" description: "Configure high availability (HA) Connector pairs using VRRP for seamless failover in traditional and AWS networks." updated: 2025-11-25T14:18:29Z published: 2025-11-25T14:18:29Z canonical: "support.appgate.com/connectors-v6-5" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.appgate.com/llms.txt > Use this file to discover all available pages before exploring further. # Connectors The Appgate SDP system supports active-passive HA operation of Connector pairs on traditional networks that support ARP and in AWS. Connectors also support the [internal failover mechanism between multiple Gateways](/v1/docs/high-availability-ha) 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 VRRP protocol 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*](/v1/docs/functions-1) *UI to create Connectors* ## Before you start Ensure you have a single [Connector (Express)](/v1/docs/connector-express) or [Connector (Advanced)](/v1/docs/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 working. [sdpctl](/v1/docs/sdpctl) will use the Site setting to ensure that the Connectors on any given Site will not be upgraded at the same time. ## HA working This is done by creating and then deploying a second Connector Appliance that shares a VIP and replicates all the resource groups. The Appgate SDP 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 one goes offline then the other will become active. You can see which one is active in the dashboard. Look in the Connector's status for the *Network IP addresses*. The one with both the actual IP and the virtual IP shown is currently the active Connector. ### Create an HA Connector pair - In *Appliances > Functions > High Availability Configuration*, enable ***Assign Virtual IP interface for HA Connectors (IPv4 or IPv6)*** on your first Connector. - Either - Clone this appliance. - Make the necessary changes to *Name* and *Interfaces* (IP address). - OR - Add a second Connector in *Appliances > Functions*. - In *High Availability Configuration*, enable ***Assign Virtual IP interface for HA Connectors (IPv4 or IPv6)*** and duplicate the settings for the first Connector. - In *Resource Group Configuration*, use the ***Get configuration from existing Connector Clients***, which will create a clone of the Resource Group(s) from the first appliance. - Deploy the new appliance alongside the first one. There may be some additional configuration steps if using a Cloud environment (see below), otherwise as soon as they are both deployed one will become active. ### Operation of 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 ![Configuration settings for an advanced connector, highlighting the NIC field labeled 'eth0'.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/image(24).png?sv=2026-02-06&spr=https&st=2026-10-27T12%3A11%3A08Z&se=2026-10-27T13%3A11%3A08Z&sr=c&sp=r&sig=Fyo1ae%2FQYBki1ookZW%2FBm1sd0zRyN%2FN1DmSzLpkQD%2BM%3D) 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.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/image(25).png?sv=2026-02-06&spr=https&st=2026-10-27T12%3A11%3A08Z&se=2026-10-27T13%3A11%3A08Z&sr=c&sp=r&sig=Fyo1ae%2FQYBki1ookZW%2FBm1sd0zRyN%2FN1DmSzLpkQD%2BM%3D) 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 Initially, you should make your changes or additions in *Appliances > Functions > Resource Group Configuration* on just one of the appliances in the HA pair. If you prefer not to be editing the active Connector, then reboot it first to make sure the second becomes the active one. When you are done editing the first Connector, click **Save**. 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 have made from the first Connector. When you are done, **Save** and the HA Connector pair are 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 SDP (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 set up 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"` Example: ```json {    "Version": "2012-10-17",    "Statement": [        {            "Sid": "VisualEditor0",            "Effect": "Allow",            "Action": [                "ec2:UnassignPrivateIpAddresses",                "ec2:AssignPrivateIpAddresses",                "ec2:DescribeRouteTables",                "ec2:ReplaceRoute"            ],            "Resource": [                "arn:aws:ec2:eu-north-1:194335033129:network-interface/eni-055995dc42074937f",                "arn:aws:ec2:eu-north-1:194335033129:network-interface/eni-06fc544f5a0514b5d"            ]        }    ] } ``` ***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 SDP has implemented HA working. - Add a CIDR reservation for the chosen VIP (so it can never be assigned to any other machine in that subnet). ***Appgate SDP*** ***configuration*** Due to the way Appgate SDP has implemented HA working, the static private IP addresses used above also need to be assigned in the two Connector appliance [interface configurations](/v1/docs/system-settings). The DHCP option must also be enabled at the same time for compatibility reasons. Appgate SDP (Software Defined Perimeter) is a security solution that provides secure access to resources based on user identity and context, leveraging a zero trust security model. A component that extends connectivity to remote sites and unmanaged resources without requiring the use of a standalone Client. The virtual or physical instance on which the system is running. Each appliance is a stateless, configurable machine that can operate as a single function or a combination of functions. The Controller is the central management appliance in the Appgate ZTNA system, responsible for user authentication, policy distribution, and overall system administration.