Configuration

Subnet filtering

With at least one subnet attached to a Gateway Access Policy it is possible to enable and configure Subnet Filtering on that policy.

Subnet Filtering allows administrators to avoid providing full access to entire subnets and instead restrict Senders access to a limited set of IP addresses.

For example, you may have an Enclave Gateway which provides access to 10.0.0.0/24 but only want to allow systems on the Senders side of the policy to access two servers in that subnet: 10.0.0.8 and 10.0.0.9. By adding a Subnet Filter to the policy you can restrict access to the wider subnet and provide only the required access.

In the example below the policy grants the users tag access to the 172.16.1.0/24 subnet advertised by the Enclave Gateway named Menlo Park Office. Having then enabled subnet filtering, a rule has been added which restricts Senders access to only two IP addresses, 172.16.1.10 to 172.16.1.11, two domain controllers in the Menlo Park Office.

Trust requirements

Gateway Access Policies obey trust requirements and ACLs the same was as a regular Direct Access Policies, so you can easily apply Zero Trust requirements to the Senders connecting into your subnets, like multi-factor authentication.

DNS name resolution

In many circumstances, you may prefer to use DNS names to access devices behind an Enclave Gateway rather than the local IP address of those devices. In most situations, devices on the LAN will already have a hostname, and one or more DNS names assigned and we want to ensure parties reaching the LAN via the Enclave Gateway are able to resolve device IP addresses using the existing DNS names.

Consider a developer working from home who needs access to the company database server in the office. The office network is 10.0.0.0/24 and the database server on that network has the IP address 10.0.0.30. The database server's hostname is dbserver1 and it's joined to a domain called corp.net, so it's fully qualified domain name is dbserver1.corp.net.

To provide access via a Gateway, there must be an Enclave system in the office network that is "Allowed to act as a Gateway" (set by an Administrator in the Enclave Portal). Once enabled, and with a Gateway Access Policy has in place which shares access to the 10.0.0.0/24 subnet (or a part of it) to the developer working from home, Enclave will be able to resolve dbserver1.corp.net on the developer's system without any further configuration.

This is possible because Enclave runs a local stub resolver which provides name resolution services to all enrolled systems. When the local stub resolver on the developer's laptop doesn't know how to resolve the name dbserver1.corp.net, the operating system will fall back to asking it's other configured DNS resolvers, but when a system is connect to an Enclave Gateway it will automatically forward that DNS query to the Gateway.

If the Gateway can successfully resolve a forwarded DNS query into an IP address, it will do and send the answer back. In this example, the developer's system may attempt to resolve dbserver1.corp.net to an IP address. The local Enclave stub resolver on the developer's laptop won't know the answer, but as the developer's system is connected to an Enclave Gateway the local stub resolver will forward the query to see if the Gateway can opportunistically resolve it.

As the Enclave Gateway is on the same subnet in the office as the fileserver, it's likely that the Enclave Gateway itself will be able to resolve dbserver1.corp.net into a local IP address, 10.0.0.30. That answer is sent back to the developer's laptop, and since the developers laptop is configured to access the 10.0.0.0/24 subnet via the same gateway, the access is automatic and seamless.

Security behaviour

An Enclave Gateway will only provide an answer for a given DNS query if the Gateway Access Policy that allowed it to be forwarded in the first place allows the querying party to reach the returned IP addresses.

So, for example if a DNS query is forwarded to an Enclave Gateway, and the query yields an answer of 10.0.0.30 and 192.168.0.30, but Gateway Access Policy only allows 10.0.0.1 to be reached, then the returned result will NOT include 192.168.0.30 so as to prevent information disclosure from the Gateway about systems in adjacent networks.

A Gateway may attempt to resolve forwarded DNS queries in one of two ways:

1. Using static or DHCP assigned nameservers to query the forwarded name verbatim.

2. Using the /etc/hosts file in to resolve the forwarded name

   10.0.0.30 dbserver1
   10.0.0.30 dbserver1.corp.net
   

The .local domain

If you are deploying a gateway to reach a domain with a .local suffix (for example, if you are using Active Directory as your DNS server, and have defined your corporate domain as ending with .local), then DNS resolution through the Enclave Gateway may fail.

If you connect to the gateway with SSH, and attempt to ping a workstation in the network, you may see this error:

enclave-admin@gateway1:~$ ping workstation1.mydomain.local
ping: workstation1.mydomain.local: Temporary failure in name resolution

The cause of this issue is that by default a number of Linux distributions treat the .local suffix as special, reserved for mDNS, and will not resolve queries to it.

In order to resolve this you must add the local domain as a search domain on the specific adapter (or adapters) that provide connectivity to your network. So, if you have an ethernet connection you may need to configure eth0 with that search domain.

How you configure the additional search domain will vary by OS version and distribution.

---

Example: Configure DNS search suffix using Netplan on Ubuntu Server

We provide here an example to configure Ubuntu 18.04 and later using Netplan. It's important to note that the when using Netplan, the local search domain should be applied to the interface, rather than as a global setting; otherwise local names will not resolve.

Note

The following command create a Netplan configuration file on an assumed fresh / clean installation of Ubuntu Server. Do not use the following command verbatim if your OS either is not a clean install, or you're using a desktop flavour of Linux such as Ubuntu Desktop, XUbuntu, or Linux Mint as the steps required are not the same.

Run the following multi-line command in-full to create a file at /etc/netplan/60-local-domain.yaml with the appropriate content. If your network interface is not called eth0, be sure to replace it with the name of your network interface before creating the file.

sudo tee /etc/netplan/60-local-domain.yaml > /dev/null <<EOF
# Configure an additional 'local' search domain
network:
    ethernets:
        eth0:
            match:
                name: eth0
            nameservers:
                search: ['local']
    version: 2
EOF

Running netplan try will apply the new configuration, waiting for user confirmation and backing out if none is given or the resulting changes destabilise the network.

sudo netplan try

Priority, redundancy and failover

It’s possible to have several Enclave Gateways all advertising the same logical subnets to the same set of Senders. In such cases Enclave will automatically pick one of the available Enclave Gateways for each logical subnet.

Which gateway wins is determined by the Gateway Priority setting in each Gateway policy. We have three Gateway Priority settings; Balanced, Ordered and Geographic.

Balanced

With a Balanced priority, senders will be distributed amongst the available configured gateways on the policy. If one or more gateways are the preferred route to a subnet, they will be used first before balancing to other gateways.

For example, an administrator might allow two systems in the Menlo Park Office to act as Gateways which both advertise access to the subnet 192.168.1.0/24.

With this gateway priority setting, clients connected via the policy will randomly choose one of the available gateways to move traffic through.

If a sender system in the policy loses its connection to one of the Enclave Gateways in the Menlo Park office, connectivity will automatically failover to the alternative Enclave Gateway.

In this way, by running multiple Enclave Gateways to provide access to the same group of logical subnets, Enclave will automatically enable multi-path failover and increase redundancy.

If one or more of the gateways are marked as a preferred route to a subnet, they will be prioritised, with traffic only failing over to other gateways when none of the preferred gateways are available.

With this priority mode, if a preferred gateway comes back online, traffic will automatically switch back to flowing through the preferred gateway.

Ordered

With an Ordered gateway priority setting, gateways are explicitly consumed in the order they appear in the receivers list. If a gateway is unavailable, the next available gateway will be used, in an Active/Passive configuration. When a higher-priority gateway becomes available, traffic will switch to it.

You can re-order gateways in the receivers list using the arrows displayed when hovering over a gateway.

An Ordered policy ignores any gateway subnet-level preference settings, so can be useful if you want to ensure that traffic is always routed through a specific gateway unless it is unavailable, regardless of the subnet.

If a gateway higher in the ordered list comes online again after being unavailable, traffic will automatically switch back to flowing through the higher-priority gateway.

Geographic

In this mode, gateways are selected based on approximate distance from sender to gateway, based on the sender and gateway's public IP address. Use this if you want users to connect via the gateway closest to them. Preferred gateways are used to choose between gateways that are less than ~10km apart.

A common use-case for this mode is when you want to route all internet access (i.e. 0.0.0.0/0) for your global users back through your own infrastructure. By using geographic priority, you can ensure that users are routed to the closest gateway to them, reducing latency and improving performance.

If the distance to multiple gateways on the policy differs by less than ~10km (~6 miles), for example if the gateways are in the same cloud datacenter, the policy will randomly route clients between these gateways, as with a Balanced priority, including considering subnet priority.

If a closer gateway comes online, senders will automatically switch to using it.

Internet gateway

Once installed, Enclave Gateways can also act as a default route, allowing administrators to route all network / Internet traffic through one or more gateway-enabled systems in your network.

Routing all Internet traffic

Normally Enclave doesn’t interact with traffic destined for the public Internet, instead defaulting to a split-tunnel overlay network and only routing traffic between systems running Enclave.

However there may be times when you do want Enclave to route your public Internet traffic. For example, to ensure a predictable and static IP address is used to access to trusted SaaS services such as Office 365 or Salesforce.

To setup an Enclave Gateway as a default route on your network you should:

1. Enrol a Linux system to act as your Enclave Gateway

2. In the Portal, allow that enrolled system to act as an Gateway

3. Manually add the subnet 0.0.0.0/0 to that system in the Portal

4. Create a Gateway Access Policy which includes the Gateway system

Once setup, all public Internet traffic for systems on the Senders side of the policy will be routed via that Enclave Gateway.

You can also opt to block a subset of this traffic by modifying the Gateway Access Policy's Access Control Rules. For example, you could choose to allow all traffic other than SSH.

Routing only DNS traffic

When connected to an Enclave Gateway, the Enclave stub resolver will forward all DNS queries to connected Enclave Gateways, giving them an opportunity to try and resolve those DNS questions using nameservers available to the gateway, that might not otherwise be available to the gateway's connected clients.

The gateway-dns-reply-for-all configuration value on an Enclave Gateway specifies whether that gateway will answer all DNS queries it receives from connected systems, or only those where the resolved IP address is reachable via that Enclave Gateway (the later being the default behaviour of an Enclave Gateway).

For example, if a connected client attempts to resolve the name www.google.com, its local Enclave stub resolver will forward that query the connected Enclave Gateway. Depending on whether this setting is enabled or disabled, the gateway will:

• With this setting disabled, the Enclave Gateway (assuming it successfully resolved the DNS question) will evaluate whether or not it is configured to provide a route to that target IP address for the querying client. If the gateway cannot provide a route to the target IP address it will respond to the client with a SERVFAIL, causing the querying client to fallback to alternative local resolvers (which are usually dhcp assigned nameserver(s)).

• With this setting enabled, the Enclave Gateway (assuming it successfully resolved the DNS question) will always provide an answer to the querying client, regardless of whether or not the gateway can provide a route to the target IP.

By enabling this setting, the Enclave Gateway will answer all DNS questions it receives from connected clients. This setting therefore allows administrators to ensure all DNS queries, regardless of client location, are first passed to the Enclave Gateway to resolve, which in turn enables customers to configure the use of upstream resolvers to provide DNS filtering or other mechanics, without also tunnelling all network traffic through the Enclave Gateway.

This value (gateway-dns-reply-for-all) is disabled by default for two reasons:

1. To avoid leaking IP addresses about the network(s) available behind an Enclave Gateway through DNS queries made by connected Enclave clients about resources for which there is no policy granting them access to know about.

2. To ensure that Enclave clients connected to an Enclave Gateway receive the most geographically appropriate answers to DNS questions based on their own physical location, rather than the physical location of the gateway, for workloads and services which the gateway isn't providing access to.

Enable this setting if there is a use-case which requires all DNS queries to be handled by a specific nameserver, regardless of endpoint locality (e.g. all users are required to make DNS queries to an on-premise DNS filtering product or a specific nameserver) via a gateway, but the network traffic should still be split-tunnel (i.e. the gateway should not route all network traffic).

DNS filtering

When an Enclave Gateway is handling DNS queries from connected clients, administrators may choose to configure those gateways to forward DNS queries to filtering platforms on behalf of their users.

Presently we support:

• Pi-hole
• SafeDNS

---

Having problems? Contact us at support@enclave.io or get help and advice in our community support channels.

Last updated Sept 24, 2024