Connector (Advanced)

Deploying a Connector (Advanced) to provision access from/to un-managed devices

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 (Advanced) can be used to enable protection for un-managed devices in any location (cloud or physical) that require connectivity to multiple, distributed protected resources. The rich functionality provided allows fine-grained, Policy-based, bi-directional network connections to be established using up to 60 resource groups - each supporting up to 16,000 TCP connections from/to the local resources.

• It supports both up rules (from local resources to Gateway / (protected) hosts) and down rules (from Gateway / (protected) hosts to local resources) both of which are explained in detail below.

• It support DHCP relay through the connected Gateways. This allows a defined group of local resources to obtain their local IP address from a remote DHCP server (a protected host) thus avoiding the requirement to have any additional managed infrastructure located alongside the Connector.

• Each resource group configured will consume one resource group license.

• It uses the pre-configured built-in Connector IdP - which still requires an IPv4 and/or IPv6 Pool to be assigned.

Basic operation

Use the Appliances UI to configure Connector (Advanced).

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.

Each resource group has a configuration for Name and Local Resources, check boxes for Source NAT to Local Resources, Source NAT from 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.

Types of Resource Group

There are two types of IP configuration available when configuring the Advanced Connector resource group; one for normal non DHCP traffic and the other for DHCP relay traffic.

DHCP relay traffic

This type of traffic has specific default settings. The usual IP configuration options relating to NAT/SNAT are not compatible with these settings and are therefore not allowed. Instead, you need to enter details of the DHCP server(s) which will be providing IP addresses to the local resources located alongside the Connector.

With the non DHCP traffic, you would normally have to configure and Policies for the Connector Clients. This is not required in the case of DHCP relay traffic, as the system knows enough to generate the required Entitlement and Policy automagically.

However, remember to ensure the DHCP relay traffic is routeable on the Site behind the relevant Gateways. The route needs to be added to the DHCP server (or the next hop) pointing the DHCP scope to the AppGate Gateway. Note that this only works with a single Gateway setup.

The main use case - up traffic from local resources (such as a web-cam)

Up rule flow (read from top)

• Local resource sends traffic destined for a protected resource.

• Local resources need to have their traffic routed towards the Connector.

• Connector routes traffic to the appropriate Clients based on the Resource group configuration.

• Traffic is split into the required tunnels (based on Entitlements) and forwarded from either the Clients' tun IP address or the IP address of the local resource depending on the Source NAT from Local Resources setting.

• A VPNd process on a Gateway on each Site will handle the traffic from each Connector Client.

• Traffic is 'firewalled' according to the Entitlement Actions and is then forwarded to the (protected) hosts either from the inbound IP address or the IP address of the Gateway depending on the Site's Disable Source NAT on Gateways setting.

• Device traffic arrives at the required (protected) host.

How to Configure UP access

If you want to give access from a local resource behind a Connector via a Gateway up to a protected resource 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 if using HA Connectors.

• Under Resource Group Configuration do <Add new> - specify the Name (i.e. web-cams) and define the Local Resources [i.e.192.168.8.0/25] sending data. Leave Source NAT from Local Resources enabled, unless the protected resources requires to see the local resource's IP [i.e.192.168.8.10].

• 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

Local resource need to know to send traffic to the Connector. This can be done by specific route or diverting the default gateway:

• Specific routes can be added so the local resource knows to send traffic for protected resources to the Connector. This can be done in a number of ways:

  • On the device - add a route for the (protected) hosts' IPs via the Connector

  • On the router - add a route for the (protected) hosts' 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 (protected) hosts' 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.

• Local resources' default gateway can be set to the Connector's IP address - this avoids having to configure multiple routes on multiple devices. Then in the resource group configuration, enable Default Gateway (Forward non-matching traffic). The traffic from the local resource will now have matched traffic (from Entitlements) sent down the appropriate tunnel and the remaining traffic will be forwarded to the Connector's default gateway.

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.

Entitlement

• Create an Entitlement allowing the desired access to the protected resources, e.g. TCP up to 10.1.2.3 on port 1000.

• If you want to optionally use a DNS server that lives on the protected network (for the local resources) then include an Entitlement for the DNS server as well.

Policy

• Create a Policy and make sure it is applied only to that particular Client by assigning it if the Identity Provider is "Connector" AND user.clientName is video cameras.

• Add the created Entitlement to the Policy.

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 ti see if the right connectorSubnets are listed

Protected resources

If Source NAT from Local Resources is disabled then traffic from the Connector (Advanced) will appear to be coming from the IP address of the local resource. When this is the case, the user claim ag.connectedSubnets will exist and will be reporting the IP address of the local resource in Session Details.

These are also used to set routes on this Gateway which will allow traffic to be sent to these IP addresses. If Disable Source NAT on Gateways is enabled as well, then traffic from the Gateways to the protected resources will appear to be coming from the IP address of the local resource.

• Make sure that you add a route so the (protected) hosts can return traffic it receives from the Gateway.

Alternative use case - down traffic from protected resources behind Gateways

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.

• Connector Clients connect to just one Gateways on the required Sites.

• A VPNd process on each Gateway will handle the traffic from each Connector Client.

• A down Action rule needs creating for the Connector Clients, in this case from - the (protected) host's IP address.  

• (protected) hosts on a Site send traffic to the local resources' IPs (or Connector Client's tun IP).

How to Configure down access

If you want to give access from a protected resource behind a Gateway down to a local resource via 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 if using HA Connectors.

• Under Resource Group Configuration do <Add new> - specify the Name (i.e. web-cams) and define the Local Resources [i.e., 192.168.8.0/25] receiving data. For down traffic, you must disable Source NAT from Local Resources. This will allow the local resource to be reached by its actual IP [i.e.192.168.8.10]. Leave Source NAT to Local Resources enabled, unless the local resources/network requires to see the protected resources IP [i.e., 10.1.2.3].  

• 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 protected resource's 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 (protected) hosts' IPs via the Connector

• On the router - add a route for the (protected) hosts' 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.

Site

• For down traffic, you should Disable Source NAT on Gateways on the Site. This will allow reaching the local resource by it's actual IP [i.e., 192.168.8.10]. If you have more than one Gateway configured for the Site, then you should only Disable Source NAT on Gateways if the network behind the Gateways supports ARP.

Entitlements

• Create an Entitlement to allow down traffic from the protected resource to the Client, e.g. UDP down on port 500 from the protected resource's IP [i.e., 10.1.2.3].

Policy

• Create a Policy and make sure it is applied only to that particular Client by assigning it if the Identity Provider is "Connector" and `user.clientName` is IP-phones.

• Assign the created Entitlement to the Policy.

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

Protected resources

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 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 from your protected resource, it should have access to the local resource as configured in your resource group.

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.