Traffic between peers¶

Traffic not flowing between peers¶

If Enclave appears to be connected to the Enclave platform and other peers, but you can't get network traffic to move across the tunnels, please work through the following checklist to identify the problem.

Check the Enclave network interface is online using ipconfig /all.

Look for Ethernet adapter Universe in the list and check that Media State is not shown as Media disconnected. If it is, try running enclave restart and consider sharing local Enclave logs with support@enclave.io to help us investigate the problem.

C:\> ipconfig /all

Ethernet adapter Universe:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Enclave Virtual Network Port
Physical Address. . . . . . . . . : 00-FF-2C-FD-0F-12
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 100.117.177.98(Preferred)
Subnet Mask . . . . . . . . . . . : 255.192.0.0
Default Gateway . . . . . . . . . : 100.127.255.254
DNS Servers . . . . . . . . . . . : 100.117.177.98

Check both connected peers can each ping their own Enclave IP address listed in enclave status as the Local address:.
Check that the Peer state of the peer you're trying to reach is showing as Up in the enclave status output.
When trying to ping another peer connected via Enclave, check that your ping requests are targeting the Virtual address of the destination peer and not the Local address.
Enclave honours the local firewall configuration. Check that the traffic you're trying to send is permitted to be received by any host-based firewalls on the target system. Pay particular attention to Windows Firewall; although Enclave sets its interface classification in Windows Firewall to Private, occasionally we see misclassification as Public instead. Also note that if you're expecting to be able to PING a target system, and are able to do so over the bearer network but not via Enclave, it's possible that there is an ICMP rule in the Windows firewall that allows ICMP packets in only on Domain classified interfaces, for example, and not Private interfaces too.
Check the routing table on each peer is configured correctly.

The routing table is configured automatically by Enclave so unlikely to be the source of a problem unless there are other conflicting routes already in place. Check for duplicate entries or conflicting routes in your routing table, or other network interfaces also using the 100.64.0.0/10 subnet.
```
C:\> route print | findstr 100.64.0.0

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination    Netmask        Gateway         Interface    Metric
100.64.0.0             255.192.0.0    On-link    100.117.177.98       281
```
Check that the MTU configured in the .profile files matches on both sides of the tunnel. Each time Enclave starts, it will set the interface MTU according to the value configured in the relevant .profile, so if you change the MTU manually, be sure to reflect this change in the .profile file; otherwise, it will be overwritten each time Enclave is restarted. You may also use native OS tools to examine configured MTUs. On Windows, use netsh interface ipv4 show subinterfaces. On Linux, use ip addr | grep mtu, and on macOS, use ifconfig -a.

Using ping to verify connectivity¶

If you're using ping tests to verify connectivity, it's important to check that the host-local firewall is not dropping traffic arriving on the Enclave network interface.

Check that the host-local firewall on both peers is not obstructing traffic flows either to, or from the Enclave network interfaces.

On Linux the Enclave network interface is likely to be named tap0 (or similar) and on Windows the Enclave network interface is usually called Universe or Enclave Virtual Network Port. On macOS, the network interface is likely named utun0.

The easiest way to verify that the host-local firewall is not interfering with Enclave traffic is to temporarily disable it, but if that's not possible in your environment, you should ensure ping traffic (icmp type 8, code 0) is permitted by the host-local firewall.
On Windows, you should check that the Enclave network interface is correctly classified by the Windows Firewall as Private and if required, create an ACL permitting inbound ICMP traffic using PowerShell:
```
New-NetFirewallRule -DisplayName "ICMPv4 (In)" -Profile Private -Direction Inbound -Protocol ICMPv4 -Program Any -Action Allow
```
Check that the ACLs defined by your Policies are allowing ICMP traffic to flow on both systems by examining the ACLs reported by enclave status on each peer.

For example, if your attempts to ping a target system are timing out, check that the system you're sending the pings from has an allow ACL like allow [X] from local -> peer where X is either [any] or includes the word icmp.

Critically you're checking that the Enclave local -> peer ACL on the sender-side of the tunnel permits icmp (or any) to be sent. If it does, that means the peer -> local ACL on the receiver side of the tunnel also permits that traffic to be received too.

ACLs in Enclave are symmetric, so if the sender-side is allowed to send ICMP traffic, the receiver-side will implicitly be allowed to receive it.

Trust requirements¶

If you have configured User Authentication trust requirements and peers are showing as down despite the user appearing to be signed in, the issue may be that individual conditions within a trust requirement (such as a security group membership) are not being met.

Run enclave status and check whether any peers show as Down, local trust requirement not met or Down, remote trust requirement not met.
If so, examine the per-policy trust requirement breakdown in the status output. Look under Not Met Conditions for the specific condition that is unsatisfied.
Note that the Enclave desktop app may show "Signed In" and trust requirements as "Met" even when specific conditions (such as security group membership) are unmet. This is because the desktop app reports the authentication status, not the full trust requirement evaluation. Use enclave status or enclave status --json for the complete picture.
For detailed guidance on diagnosing and resolving this issue, see the knowledge base article: User shows as signed in but tunnel is down.

Relayed connections between peers¶

If you observe that some or all of your enrolled systems are using Enclave's traffic relay servers to connect, you may want to explore reconfiguring the bearer network to facilitate peer-to-peer (P2P) connections. Relay servers are a fallback mechanism, used when direct connections fail due to restrictive NAT settings, high-port blocks, or threat inspection modules on routers and firewalls.

Relay servers are shared across the platform and have throughput restrictions, which can lead to increased latency and reduced bandwidth. Follow the steps below to troubleshoot and potentially resolve relayed connections.

Check NAT (Network Address Translation) settings on routers and firewalls. NAT configurations can either support or block direct peer-to-peer connections. Depending on the type of NAT, you may need adjustments to improve connectivity. Full-Cone NAT allows external hosts to contact internal hosts using the same port as the original outbound connection, making it ideal for direct connections. Also, Address-Restricted Cone NAT and Port-Restricted Cone NAT are also favorable for peer-to-peer connectivity as they typically allow direct communication in most scenarios. Symmetric NAT is highly restrictive however, as it assigns a different public port for each outbound destination, which complicates direct peer-to-peer communication and often necessitates relayed connections.

Verify that the firewall rules and NAT settings on both systems allow outbound UDP and TCP traffic on the ports used by Enclave. If possible, adjust NAT modes to a less restrictive type, such as Full-Cone or Port/Address-Restricted Cone NAT. See also notes about traffic relays.
Firewalls can block outbound connections, particularly on high-numbered ports, which are necessary for successful peer-to-peer communication. Verify that outbound UDP and TCP connections on high-numbered ports (typically above 1024) are allowed on both systems. To check if outbound connectivity on high-numbered ports is available, you can use the http://portquiz.net/ website. If outbound connectivity on high ports fails, update firewall settings to permit outbound traffic on these ports. See also the related guidance on firewall ports for establishing peer-to-peer connectivity.
Ensure threat detection or deep packet inspection rules are not interfering with Enclave traffic, and check for any explicit P2P detection and blocking on your network firewalls. See also using Enclave with your firewall.

If you're still experiencing traffic issues after working through this checklist, see collecting logs and contact support.