The Virtual Network

We've talked about the way we build connectivity quite extensively in How it works, but lets look at the virtual network you have at your disposal once the connectivity is established.

On each system where the agent is installed, we add a virtual network adapter.

On Linux, this adapter materialises as tap0, on macOS as utun0. This is because Windows and Linux support Layer-2 traffic, but macOS only supports Layer-3 traffic.

Info

Enclave can usually sit comfortably alongside existing VPN configurations if you have them, so if an existing VPN is using tap0, we may use tap1, tap2 and so on, as required.

On mobile platforms we create this adapter as a "VPN" configuration on the device, in the platform-specific manner that is required.

By default, this virtual adapter is connected to the subnet 100.64.0.0/10; this subnet is reserved for carrier-grade NAT by RFC 6598, and provides a network of up to 4.1 million devices. Alternate subnets can be used if required, but care must be taken to avoid overlap with existing networks. You can find more details on this range here.

We use this subnet by default because it is guaranteed not to clash with any existing IP addresses allocated for either public or private use, ensuring the routes we provide don't interfere with your local network.

When a system enrols, it is allocated a random static IP address from the subnet, which stays fixed for the lifetime of the enrolment.

Tip

Having a statically-allocated IP address gives a number of benefits, especially if your device is moving between networks (i.e. from cellular to wi-fi and back); the virtual IP address doesn't change even though the "real" one does, meaning that existing connections on the virtual network stay active when moving between networks.

Because we create a L2/L3 network adapter, to any applications running on the devices, we are "just another network", so applications do not need to be changed/reconfigured to use Enclave, and any IP-based protocol will run on top of it.

Routing Table

On systems running Enclave, we deploy additional routes into the operating system routing table to instruct the operating system that traffic destined for the 100.64.0.0/10 subnet should be sent over our adapter. Here's an example for a system with a virtual address of 100.84.16.33.

Network Destination          Netmask          Gateway        Interface  Metric
         100.64.0.0      255.192.0.0          On-link     100.84.16.33     256
       100.84.16.33  255.255.255.255          On-link     100.84.16.33     256
    100.127.255.255  255.255.255.255          On-link     100.84.16.33     256

On Windows devices, we also add an additional route with a very high metric, to allow Windows to correctly classify our network:

Network Destination          Netmask          Gateway        Interface  Metric
            0.0.0.0          0.0.0.0  100.127.255.254     100.84.16.33    9999

If you're using Enclave Gateway, this routing table will look a little different, as we add additional routes to the OS routing table to route any traffic intended for the gateway over our adapter.

Traffic Enforcement and ACLs

Within each Enclave Policy, you are able to provide ACLs that control which traffic is allowed between peers over the virtual network. I'll cover briefly here how that's enforced.

Inside each agent process, we have our own stateful firewall implementation performing real-time evaluation of the TCP/IP headers of each packet as it moves across the virtual network, dropping packets that are not allowed by policy.

Our firewall understands which policies have all their trust requirements met, and which don't, so we are able to mutate the permitted traffic immediately upon a change in the effective set of policy for the agent.

We enforce traffic restrictions on both ingress and egress traffic; actively restricting egress traffic is not often part of a default firewall configuration, however it both helps to reduce the amount of data sent over the network (Windows can be quite noisy in the traffic it tries to send over a connected network), and helps prevent some niche forms of remote shell attacks if one of the systems in a connection has been compromised.

DNS

In the Enclave portal, you are able to configure DNS names for systems (or tags). A configured DNS name will then be resolvable on any system where a policy says it may be able to connect to a system with that name. Let's look at how this works.

On each Enclave Agent, we run a custom DNS nameserver in-process with the agent. On most platforms, this nameserver binds to port 53 on the Enclave Virtual adapter, and can only be reached from that local system.

If the nameserver sees a request for a name that matches a defined Enclave DNS name, it will respond with the virtual IP address of that peer, allowing the system to connect using the virtual IP in the 100.64.0.0/10 subnet.

Note

While the local Enclave nameserver will see any DNS requests sent by the local agent, we do not log any of those DNS queries in our platform by default, or in the local agent log files. If you are asked by Enclave support to adjust your log level to capture more information, those DNS names may be logged, and you may wish to delete the relevant log files once the support process has concluded.

You can find more information on how our split-tunnel DNS works in the relevant documentation.