What are relayed connections, and how to avoid them?¶

Introduction¶

Enclave is designed to prioritise direct peer-to-peer connections between nodes wherever possible, providing the fastest and most efficient communication pathways. However, when direct connections cannot be established due to limitations in firewall or NAT configuration, connections may fall back to using Enclave owned and operated traffic relay servers. For more information about Enclave Relay servers, please see our how-it-works section on traffic relays.

When peers connect using relay servers, depending on geography, it can introduce additional latency and reduced throughput, and Enclave only uses relay servers as a means of last resort when a direct path cannot be established to ensure connectivity is available. This article explains why relayed connections occur, and what you can do to avoid them — from best practice to configuration overrides and workarounds.

Symptoms¶

Connections between systems in Enclave report as relayed instead of direct.
Higher latency and/or reduced bandwidth during communication is observed between peers as traffic is routed indirectly.

Cause¶

NAT and firewall behaviour¶

Most networks sit behind firewalls and NAT devices that control and rewrite IP and port information. NAT (Network Address Translation) allows multiple internal devices to share a single public IP, while stateful firewalls track outbound connections and only allow related inbound traffic.

For two peers to connect directly through NAT:

Each must learn its own server reflexive address (the external IP/port the Internet sees).
Each must share this with the other via Enclave signalling.
Each must attempt to contact the other on the expected IP and port combination at roughly the same time.
NAT and firewall rules must allow this inbound return traffic.

If either peer’s NAT rewrites the source port differently for each destination, or blocks return traffic, the connection fails — and Enclave falls back to a relay server.

TCP vs UDP¶

UDP is more tolerant of NAT due to its stateless nature. Enclave uses techniques like hole punching to establish direct UDP tunnels.
TCP requires a strict three-way handshake and is harder to traverse in symmetric NAT or tightly filtered environments.

NAT types and their impact¶

NAT Type	Description	Direct Connection Possible?	Notes
Full Cone NAT	One-to-one mapping: any external host can send packets to the internal IP/port once an outbound connection has been made.	✅ Yes	Most permissive; Since mappings are static and open to all external hosts after the first outbound packet, any peer can reply or initiate a connection as long as they know the public IP and port.
Restricted Cone NAT	Only external IPs that the internal host has previously contacted can send packets back.	✅ Yes	As long as the internal host sends any packet to the peer’s IP, the NAT will accept responses from that IP on any port. This makes timing and coordination easier.
Port Restricted Cone NAT	External host must match both IP and port that the internal host has contacted.	✅ Yes	Both peers must send packets to each other’s specific IP and port, at roughly the same time. This "simultaneous punching" opens matching paths on both NATs.
Symmetric NAT	Each outbound connection to a different destination uses a new external port; incoming packets must match the original destination.	❌ No	Direct connections almost always fail; peers can’t predict what port the other NAT will assign. Even simultaneous outbound packets often miss each other.

More restrictive NAT types, combined with aggressive port randomisation or lack of hairpin NAT support, reduce the likelihood of a successful direct connection.

NAT connection matrix¶

The ability to form a direct connection depends on how both peers' NAT devices behave. The table below shows common NAT type pairings and whether direct connectivity is typically possible.

Peer A NAT Type ↓ / Peer B NAT Type →	Full Cone	Restricted Cone	Port Restricted Cone	Symmetric
Full Cone	✅ Yes	✅ Yes	✅ Yes	❌ No
Restricted Cone	✅ Yes	✅ Yes	✅ Yes (timing-sensitive)	❌ No
Port Restricted Cone	✅ Yes	✅ Yes (timing-sensitive)	✅ Yes (simultaneous only)	❌ No
Symmetric	❌ No	❌ No	❌ No	❌ No

Notes

A direct connection is usually possible if at least one peer is behind a Full Cone, Restricted Cone, or Port Restricted Cone NAT.
If both peers are behind Symmetric NATs, direct connections almost always fail — relays are required.
Port Restricted Cone NATs often require both peers to initiate packets simultaneously, which is coordinated by Enclave.

Resolution¶

1. Check firewall ACLs¶

The most common cause of failed direct connections is overly restrictive firewall rules. Ensure:

Outbound UDP and TCP traffic from enrolled systems is allowed.
Return traffic is permitted by the firewall’s stateful inspection or allowed explicitly.
If using a cloud firewall (e.g., AWS security groups), make sure security group rules allow the required traffic between systems too.

2. Review NAT behaviour¶

Firewalls and routers often act as NAT devices, modifying port numbers or rejecting unsolicited inbound traffic. Where possible:

Use NAT types that preserve the same port across destinations (Full Cone or Restricted Cone).
Avoid Symmetric NAT devices, or configure them to minimise port randomisation.
Enable hairpin NAT support to allow local traffic to loop back through the public IP.

3. Adjust source match policy¶

By default, Enclave will require that the source address and port of a connecting peer exactly matches the expected source address as determined by the platform. If your NAT changes the port (or the IP) to deviate from the expected origin, direct connections may not be possible.

To increase flexibility, Enclave has a source-match-policy setting that can relax it's matching requirements. Set to ip to relax peer matching to IP only, or any to remove matching peer requirements all together.

Policy	Behaviour
`exact` (default)	Requires exact IP and port match.
`ip`	Requires only IP match.
`any`	No match enforcement.

This setting can be applied via the ENCLAVE_SOURCE_MATCH_POLICY environment variable, or using the CLI to set enclave set-config source-match-policy <value>.

4. Bind to a fixed public port¶

If none of the above methods allow a direct connection, or you're not able to make alterations to the bearer network behaviour and relays are consistently used, the final option is to bypass NAT entirely on at least one of the participant systems:

Bind Enclave to a fixed, known port.
Open that port on your firewall to the public Internet.
Ensure any intermediate routers perform static NAT or port forwarding to preserve that port.

This method guarantees predictable reachability from external peers, avoids the need for traversal techniques, and eliminates reliance on relay servers. Please see our documentation on forcing a specific port number for implementation details.

Summary¶

Relay servers are contended and should be considered a fallback option. While secure and end-to-end encrypted, they add latency and reduce throughput.
Enclave will always attempt a direct connection first and only fall back to relays after multiple failed attempts.
Direct connectivity may be unachievable in some environments, particularly with symmetric NATs or locked-down cloud firewalls.

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

Last updated May 2, 2025