In today’s distributed environments, organizations often need to securely connect remote networks or groups of under-protected devices—such as IoT sensors, cameras, or legacy systems to their protected resources.
Appgate SDP addresses this challenge with the Connector, a flexible solution designed to extend Zero Trust security to unmanaged or remote assets, whether in the cloud or at branch offices.
There are two deployment options of the connector:
· Connector (Express): Designed for simplicity, requiring minimal configuration to quickly connect users to local resources via Appgate SDP Gateways.
· Connector (Advanced): Offers granular control and advanced features for complex environments, supporting multiple resource groups, high availability (HA), and fine-tuned policy management.
This article is focusing on express connector
Deploying an Appgate Connector: Initial Appliance Installation and Seeding
The first step is to install or spin up a new appliance and seed it as a blank node. This process is identical to deploying any other Appgate SDP appliance, such as a Controller, Gateway, or LogServer.
Configuring the Built-in Identity Provider and IP Pools for Appgate Connectors
When deploying an Appgate Connector (either Advanced or Express), it’s important to understand how authentication and IP address assignment work for the Client instances running inside the Connector appliance.
Appgate SDP includes a built-in Identity Provider (IdP) specifically for Connectors. This IdP is used to authenticate the headless Client instances that are created for each resource group within the Connector appliance. Each resource group you configure in a Connector is essentially a separate Client, and each of these Clients requires its own unique IP address for secure tunnel communication.
Why this matters
Each resource group = one Client = one IP address:
Every resource group you define in a Connector will consume one IP address from the assigned pool.
· Isolation and Routing:
These IP addresses are used for the virtual tunnel interfaces, ensuring proper isolation and routing between resource groups and protected resources.
· Scalability:
Planning your IP pools in advance ensures you can scale your deployment without running into address shortages.
Step-by-Step: Configure an Appgate Connector and Resource Group
Select the check box for the Connector function.
In the Site section, select the appropriate site for the Connector from the Appliance Site drop-down list.
In the Resource Group Configuration section, click Add New at the Advanced Connector field.
Give your Connector a distinctive and descriptive Name.At Local Resources, click Add New.
Enter the private IP Address or the subnet of the protected Resource(s).
Enter the Netmask Length.
Enter the NIC.
· NAT Options:
o Source NAT to Local Resources: Enable if you want traffic to local resources to appear as coming from the Connector’s tunnel IP.
Source NAT from Local Resources: Enable if you want traffic from local resources to appear as coming from the Connector’s tunnel IP.
Finally Check if the connector resource group CG-Switch in our example is connected in the active session
Verify connector health
On the appliance dashboard, ensure the Connector function shows as healthy.
A healthy status means the Client(s) (one per resource group) have successfully signed in and have entitlements assigned
Note: - Connector Express in Appgate SDP is designed for quick, easy, and secure remote access to local resources with minimal configuration. To achieve this, it automatically creates the required Policy and Entitlements for the Connector Client.
When you define a resource group (a set of local resources behind the Connector), Connector Express automatically creates a Policy for the Connector Client. This Policy includes the necessary down rules that match the user’s up rules (i.e., the user’s entitlements to access those resources).
This ensures that when a user is entitled to access a resource behind the Connector, the system automatically allows the return (down) traffic from the resource back to the user, without manual intervention.
Keep in mind The primary use case for the Express Connector is to allow users (remote or protected by Appgate) to access local resources (like printers, servers, or devices) located behind the Connector and NOT the other way around.