Deploying a Connector (Express) to connect users to local resources
The Connector is an easy way to protect remote networks and/or groups of under-protected devices. Advanced has multiple configuration options, however by using the Express, only minimal configuration is required to allow users to connect to the local resources associated with a Connector via Appgate SDP Gateways.
In a typical environment, a Connector would be deployed as a standalone Appliance in a remote location such as in the Cloud or at a site office.
The Connector can be configured for HA operation if required.
The Connector (Express) is like an easy button for secure remote access. With it, you can quickly on-board a new location (cloud or physical) and immediately provide fine-grained access to that location. It is network agnostic, working across any available ISP, WAN or SD-WAN connection. And, because it requires no inbound connections, it can be deployed behind an edge firewall without needing any changes to existing infrastructure.
Works with just one Site and will connect to all the Gateways on that Site. This ensures the user's Client connection (up traffic) can always rendezvous with the Connector's (down traffic) Client connection.
Can have only one resource group; the Client is automagically assigned a Policy and will therefore consume one resource group license.
Uses the pre-configured built-in Connector IdP - which still requires an IPv4 and/or IPv6 Pool to be assigned.
Automagically creates the required (down rules) for the Policy based on user's up rules. This comprises matching down rules 'from the user's tun IP address'.
Requires no manual configuration options for Policies or Entitlements.
Supports up to 16,000 TCP connections to local resources.
NOTE
If local resources need to initiate a connection (to/through a Gateway) you will need to use Connector (Advanced).
Basic operation
Use the Appliances UI to configure Connector (Express).
Think of a resource group as a selection of local resources that will share the same access rights (same Policy) and have their traffic handled by one Client instance in a Connector.
The resource group has a configuration for Name and Local Resources, check boxes for Source NAT to Local Resources and Destination NAT to Local Resources and there is a Device ID created for the related Client that will provide the connectivity (to the Gateways).
Each Connector is just a platform that can run multiple special versions of the Linux headless Client, each utilizing the same trusted connectivity approach as normal Clients.
Each resource group configured will get a unique Policy assigned to the Client which sets the local routing and then connects to an available Gateway on each of the allowed Sites.
To maintain isolation, each of the resource groups (the Clients and their related multi-tunnel network adapters) run in their own isolated Linux name-spaces (virtual network).
Each Client defined by a resource group will consume an IP address from the IP pool (which can be separate from the normal user's IP pool) - so ensure the pool size allows for the total number of resource groups defined in the Collective.
The Clients use concealed profiles and credentials which are automatically applied, so on boot-up the Clients will immediately try to sign in to the Controller(s) (and continue to retry if it fails). For this reason it is strongly advised to always have a valid Policy for these Clients, otherwise the retries will effectively become a DoS attack on the Controllers and consume large amounts of disk space on the Connectors with log warning messages.
Main use case - down traffic from users to local resources
Down rule flow (read from bottom)
Local resource will need to know how to route any return traffic towards the Connector.
Traffic is forwarded to the local resources according to the Source NAT to Local Resources or Destination NAT to Local Resources setting.
Resource group defines the which local resources are routable through the Connector Client.
Connector Client receives traffic destined for the local resources.
All Connector Clients connect to all Gateways on the Site.
A VPNd process on each Gateway will handle the traffic from each Connector Client.
Matching down rules are automagically created for the Connector Clients from the user's Entitlements Actions on just that Gateway. Users' traffic is then forwarded 'tun-to-tun'.
User connects to a Gateway on the Site. A VPNd process will handle their traffic which is 'firewalled' according to the user's Entitlement Actions.
How to Configure Down access
If you want to give access for users down to local resources (remote from a Gateway's protected resources) using the Connector you will need to do the following setup.
Connector
Enable the Connector function on your appliance.
Under Site select the Site to which the Connector should be associated.
Under Resource Group Configuration do <Add new> - specify the Name (i.e. printerA) and define the Local Resources [i.e., 192.168.8.10] receiving data. Leave Source NAT to Local Resources enabled, unless the local resources/network requires to see the users tun IP [i.e., 192.168.1.20].
Under High Availability Configuration assign a VIP to one of the interfaces if you plan to deploy the Connector as part of an HA pair.
Local resources
If Source NAT to Local Resources is disabled then traffic from the Connector will appear to be coming from the user's Client tun IP. Make sure that you add a route so the local resource can return traffic it receives from the Connector. This can be done in a number of ways:
On the device - add a route for the user's Client tun IPs via the Connector
On the router - add a route for the user's Client tun IPs via the Connector
In the Cloud Cloud environments such as Azure or AWS this often requires two things be done:
add a route on the local subnet for the source IPs via the Connector
allow the NIC on the Connector to accept traffic for destinations other than itself. In AWS disable "Source/Destination Check" in Networking. In Azure this is enable "IP forwarding" in the Network interface configuration.
Identity Provider
Make sure that the built-in Connector identity provider has ipv4 and/or ipv6 pools assigned for the Connector Clients to use [i.e., 192.168.100.0/24] to suit your use case. The default IP pools can be used and configured to provide a larger range of IPs for the virtual tunnel interfaces if needed. Refer to IP Pools.
Entitlements
Create an Entitlement for the user to allow up traffic to the local resource(s) behind the Connector [ i.e., TCP up to 192.168.8.10].
NOTE
The Appgate SDP system recognizes this IP address as being a local resource only accessible via an associated Connector and adds the user's tun IP (as a source) to the generic down rule from the Gateway to the Connector Client. This rule includes all protocols TCP, UDP, GRE, etc.
Policy
Create a Policy for the user and add the user's up Entitlement.
NOTE
The Policy for the Connector Client is created automagically
Dashboard
Go to the appliance status dashboard and verify that the Connector function shows healthy. That means the Client has signed in with Entitlements assigned.
Go to session details, find the Client by it's name and view the details:
check Entitlements to see that the right Actions are allowed
check User Claims>ag to see if the right connectorSubnets are listed
User
When Destination NAT to Local Resources is enabled:
Traffic should be sent to the Connector Client's tun IP address instead of the local resource's IP address. The Appgate SDP system has very sticky IP pool allocation algorithm - so the tun IP address should normally never change. The Client's tun IP address will be one-to-one mapped to a specific local resource's IP address such as a printer. The Connector will also perform SNAT to local resources, so the resulting traffic will appear to be coming from the IP of the Connector. This option eliminates issues when two groups of local resources behind different Connectors have a overlapping IP address ranges - allowing the unique tun IPs to be used instead.
NOTE
Only a single local resource can be specified per resource group (strictly speaking, it's one for IPv4 and one for IPv6).
Now test the access for your user, there should be access to the local resource as configured in your Entitlement.
SSH access to a Connector
There is a specific way to configure SSH command line access to a Connector that has no fixed/public IP address if you require this.