Virtual networking¶
Once connectivity is established (see What is Enclave?), each system gets access to a virtual network. Enclave creates a virtual network adapter on every system where the agent is installed. To applications, this adapter is just another network interface - any IP-based protocol works over it without modification.
Each enrolled system is assigned a static IP address from the 100.64.0.0/10 subnet, which is reserved for carrier-grade NAT by RFC 6598. This range is guaranteed not to conflict with existing public or private IP allocations, so Enclave's routes never interfere with your local network. The address stays fixed for the lifetime of the enrolment, even as the system moves between physical networks - switching from cellular to Wi-Fi does not change the virtual IP, so existing connections on the virtual network remain active.
Alternative subnets can be configured if required, but care must be taken to avoid overlap with existing networks. See the 100.64.x.x addresses KB article for more detail on this range.
Routing table¶
Enclave deploys additional routes into the operating system routing table so that traffic destined for the 100.64.0.0/10 subnet is sent over its adapter. The following example shows routes 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, Enclave also adds an additional route with a very high metric, to allow Windows to correctly classify the Enclave 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 are using Enclave Gateway, the routing table includes additional entries because Enclave adds routes for traffic intended for the gateway.
Traffic Enforcement and ACLs¶
Each Enclave policy can include ACLs that control which traffic is allowed between peers over the virtual network. Here is how that enforcement works.
Inside each agent process, Enclave has its 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.
The firewall understands which policies have all their trust requirements met, and which don't, so permitted traffic is updated immediately upon a change in the effective set of policy for the agent.
Enclave enforces traffic restrictions on both ingress and egress. Actively restricting egress is not often part of a default firewall configuration, but it reduces unnecessary traffic (Windows generates significant background traffic on connected adapters) and helps mitigate certain remote shell attack vectors if one of the systems in a connection has been compromised.
DNS¶
In the Enclave portal, you can configure DNS names for systems or tags. A configured DNS name is then resolvable on any system where policy permits connectivity to the named peer.
Each Enclave agent runs a custom DNS nameserver in-process. On most platforms, this nameserver binds to port 53 on the Enclave virtual adapter and can only be reached from the local system. Enclave uses split-tunnel DNS: queries that match a defined Enclave DNS name are resolved locally to the peer's virtual IP address in the 100.64.0.0/10 subnet, while all other queries pass through to the system's normal DNS resolver unchanged.
Note
While the local Enclave nameserver will see any DNS requests sent by the local agent, Enclave does not log any of those DNS queries in the 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.
For more detail on how the stub resolver handles query ordering, see Stub resolver query order.
Last updated August 1, 2026