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 configured option is to exact. Note that exact is the default value.

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). Enclave enforces strict source port validation and 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 is correct and expected when source-match-policy is set to exact (as it is by default), as it protects against spoofing or unexpected source origins. However, it leads to unwanted relayed connections when middleboxes silently rewrite port mappings inconsistently.

Resolution

Option 1: Use a more tolerant source match policy

To tolerate NAT-induced port rewriting, change the agent configuration to match only on source IP:

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

This allows Enclave to accept inbound tunnels from the correct IP, even if the source port differs. For further detail, refer to the source-match-policy documentation. Note that switching to use ip as the source matching policy reduces the strictness of validation, so please consider your threat model before relaxing this constraint.

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 (i.e. maintaining source-match-policy=exact), 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.
• Temporarily set source-match-policy=ip to determine whether relaxed source port validation enables direct connections
• Switch to a different bearer network and observe if direct tunnels succeed.
• Maintain source-match-policy=exact during testing to confirm network effects.
• 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.

• Relaxing source-match-policy is a functional workaround, but the ideal resolution is to ensure the network allows stable NAT mappings across destinations.

---

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

Published July 8, 2025