Documentation / Knowledge Base

All connected systems appear as relayed connections

In some environments, Enclave peer-to-peer tunnels may unexpectedly fall back to relayed connectivity — even when both systems are directly reachable and no explicit firewall rules are blocking traffic. This article explains why this can occur, the most common causes, how to verify the problem, and how to mitigate it using configuration settings or environment changes.

Symptoms

When examining the status of connected hosts in the Enclave system tray application on Windows, or using the CLI, all connections to other systems may appear as relayed. This is visible in the output of enclave status or through Enclave logs which show peer connections consistently negotiated through relay hosts.

Administrators may note:

• Connections to other systems consistently appear relayed, despite compliance with the recommended NAT configuration.
• Debug logs show inbound tunnel attempts being discarded due to an unknown connection with no known matching candidate.
• The Enclave Discovery Service provides valid public (server-reflexive) connection candidates for other systems, yet none are successfully connected.

Cause

This issue is caused by a source port mismatch introduced by intermediate network devices between Enclave and the platform Discovery Service. If you're unfamiliar with how relayed connections work in Enclave, see what are relayed connections? for an overview.

When Enclave connects to the Discovery Service, that system's observed source IP and port are recorded as a connection candidate to be later shared with other systems when initiating a connection between them. Other systems then expect network traffic from the affected system to originate from the same IP and port identified by the Discovery Service.

However, some networks modify the source port of packets sent by Enclave, depending on the destination of outbound packets — especially on connections targeting TCP port 443. This is commonly due to:

• TLS interception appliances
• Firewalls performing non-transparent inspection or connection proxying
• NAT devices applying per-destination port rewriting
• ISP-grade CGNAT behaviour

If the source port used in the peer-to-peer connection does not match the candidate seen by the Discovery Service, the receiving peer rejects the connection when source-match-policy is configured to exact or ip.

Event flow

To illustrate the failure mode clearly, consider the following timeline of events:

1. Sam starts Enclave

   Enclave binds to a local port (e.g., port A), using the SO_REUSEADDR socket option.

2. Sam connects to the Discovery Service

   However, a middlebox modifies the source port of the outgoing connection to port B. The Discovery Service registers (IP X, port B) as Sam’s server reflexive (Public IP) connection candidate.

3. Alex and Sam receive connection candidates for each other from the Discovery Service

   Both parties begin cycling through provided connection candidates attempting to establish a direct connection.

4. Alex receives a connection attempt from Sam

   The packet arrives from IP X, port A (Enclave's original socket binding on Sam's device) on a high port number.

5. Alex rejects the connection as unknown

   The source address of the packet from Sam (IP X, port A) does not match the advertised candidate (IP X, port B). If source-match-policy is set to exact, Enclave discards the packet logging the message, "unknown connection with no known matching candidate".

6. Relay fallback is triggered

   No valid direct connection can be established, except for via a relay server.

This behaviour occurs when source-match-policy is set to exact, which requires both IP and port to match. It leads to unwanted relayed connections when middleboxes silently rewrite port mappings inconsistently.

As of version 2026.x.x, the default `source-match-policy` is `any`, which avoids this problem. This article applies to systems where the policy has been explicitly set to `exact` or `ip`.

Resolution

Option 1: Reset source match policy to the default

If source-match-policy has been explicitly set to exact or ip, reset it to the default (any) to tolerate NAT-induced port and address rewriting:

enclave set-config source-match-policy any
enclave restart

This allows Enclave to accept inbound tunnels regardless of the source address. Source address matching is a secondary check that runs after the cryptographic handshake, which already authenticates the peer's identity via certificate. For further detail, refer to the source-match-policy documentation.

Option 2: Avoid the interfering network path

This problem will often disappear when moving to a different network (e.g., mobile hotspot or alternate Wi-Fi) which can help confirm that the root cause lies with the original network path — typically a firewall or router interfering with TLS traffic.

If switching networks resolves the issue without changing configuration, then the Enclave agent and platform are functioning correctly, and the problem lies with the intermediate network.

Administrators should consider:

• Replacing or reconfiguring local routers performing TLS interception to add an exception for the Enclave platform
• Disabling non-transparent proxying features when communicating with the Enclave platform
• Contacting the ISP if the problem is present across all local networks

Troubleshooting tips

• Use enclave status to check if all peers appear as relayed.
• Check the current value of source-match-policy using enclave list-config — if set to exact or ip, reset to any.
• Switch to a different bearer network and observe if direct tunnels succeed.
• Examine Enclave logs at debug log level for dropped connection attempts with mismatched source ports.
• Confirm whether any recent firewall or router updates may have introduced interception behaviour.

Devices known to interfere with direct connection establishment

The following devices have been confirmed to introduce NAT or proxy behaviour that causes Enclave to fall back to relayed connections due to source port mismatches:

Manufacturer	Device	Behaviour
Technicolor	Magenta Home Box (FGA2233)	Modifies source port for outbound TCP/443 connections, interfering with tunnel negotiation.

If you encounter similar behaviour with other devices or software, please report details to support@enclave.io so we can update this list.

Notes

• This issue is not caused by Enclave, but by behaviour introduced on the network pathway between peers.

• It most commonly appears in environments using TLS inspection or non-transparent firewalls.

• If source-match-policy has been set to exact or ip, resetting to the default any will resolve this issue.

---

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

Published July 8, 2025