Skip to content

NAT traversal and connectivity

Enclave builds direct peer-to-peer tunnels between systems without requiring any open inbound firewall ports, and without exposing any listening services to the internet.

What is NAT, and why does it matter?

Network Address Translation (NAT) is a technique used by routers and firewalls to allow multiple devices on a private network to share a single public IP address. When a device on your local network sends a packet to the internet, the NAT device rewrites the packet's source IP address (and usually the source port) to its own public address, and records the mapping in an internal table. When a response comes back, the NAT device looks up the mapping and forwards the packet to the correct internal device.

NAT exists for two main reasons. First, IPv4 address exhaustion - there simply are not enough public IPv4 addresses for every device in the world to have its own. NAT lets an entire office or home network operate behind a single public address. Second, NAT provides a degree of isolation, because devices behind a NAT device are not directly addressable from the internet.

That isolation is exactly the problem for peer-to-peer connectivity. If two devices both sit behind NAT, neither can accept an inbound connection from the other. The NAT device on each side has no mapping for the other peer's traffic, so it drops the packets. Traditional VPNs solve this by placing a server with open ports on the public internet and routing all traffic through it, creating a bottleneck and a visible target. Enclave takes a different approach: instead of funnelling traffic through a central point, Enclave connects peers directly to each other, even when both are behind closed firewalls.

NAT types

Not all NAT devices behave the same way. The way a NAT device creates and enforces its mapping table determines how easy or difficult it is to establish a direct connection through it. There are four commonly recognised NAT types, each progressively more restrictive.

Full Cone NAT

A Full Cone NAT creates a one-to-one mapping between an internal IP/port and an external IP/port. Once the mapping exists, any external host can send packets to that external address and they will be forwarded to the internal device. This is the most permissive type - as long as the internal device has sent at least one outbound packet, any peer that knows the public IP and port can reach it.

Restricted Cone NAT

A Restricted Cone NAT is slightly more restrictive. It still creates a consistent mapping (the same internal IP/port always maps to the same external IP/port), but it only accepts incoming packets from an external IP address that the internal device has previously sent a packet to. The port on the remote side does not matter - only the IP address is checked. This means that as long as both peers have sent a packet to each other's IP address, the NAT will allow the traffic through.

Port Restricted Cone NAT

A Port Restricted Cone NAT adds a further restriction. Like a Restricted Cone NAT, it creates a consistent mapping, but it checks both the IP address and the port of the remote host. Incoming packets are only accepted if the internal device has previously sent a packet to that specific IP and port combination. This means both peers must send packets to each other's exact IP and port at roughly the same time for the connection to succeed - a technique called simultaneous hole punching.

Symmetric NAT

Symmetric NAT is the most restrictive type. Unlike the cone NATs, a Symmetric NAT creates a different external mapping for every unique destination. If your device sends a packet to server A, it gets one external port. If it sends a packet to server B, it gets a different external port. Incoming packets are only accepted if they come from the exact destination the outbound packet was sent to.

This is the NAT type that causes the most problems for peer-to-peer connectivity. Because the external port changes for every destination, neither peer can predict what port the other's NAT device will assign when it tries to reach them. Hole punching almost always fails, and a relay is required.

A direct connection is usually possible when at least one peer is behind a cone-type NAT. If either peer is behind a Symmetric NAT, the connection will almost always fall back to a relay. For a full compatibility matrix and troubleshooting steps, see What are relayed connections, and how to avoid them?.

How Enclave traverses NAT

Enclave's connectivity is built on the principles established in ICE (Interactive Connectivity Establishment, RFC 8445), the same framework that underpins direct connections in video calling platforms and WebRTC.

The Discovery Service

For two peers to find each other, they need a trusted intermediary. In Enclave, that role belongs to the Discovery Service.

Each peer maintains an outbound connection to the Discovery Service and reports its reachable addresses - its "connection candidates". The Discovery Service also observes each peer's public IP address and port as they appear from outside the NAT (sometimes called the server-reflexive address). When policy allows two peers to communicate, the Discovery Service introduces them by sharing each peer's connection candidates with the other.

Once the introduction is complete, the Discovery Service steps out of the data path. Traffic flows directly between the two peers, not through the Enclave platform. The Discovery Service is only needed again to build new connections or respond to policy changes. For more on the Discovery Service and how policy is evaluated, see Enclave Discovery Service.

Hole punching

The key technique that makes direct connections possible is called hole punching. If both peers send outbound packets to each other at roughly the same time, the stateful firewalls and NAT devices on each side see the other peer's packets as return traffic for the outbound connection they just allowed.

Here is how the process works:

  1. Both peers authenticate with the Discovery Service and report their connection candidates.
  2. The Discovery Service evaluates policy. If the two peers are allowed to communicate, it introduces them by exchanging their connection candidates.
  3. Both peers begin sending handshake packets to each other simultaneously, targeting each other's reported addresses.
  4. Each peer's firewall and NAT device see the incoming packets as responses to the outbound packets they just permitted, and allow them through.
  5. A cryptographic handshake takes place over the newly opened path, establishing end-to-end encryption.
  6. The tunnel is established and data flows directly between the peers.

The simultaneous timing is coordinated by the Discovery Service. Both peers are told about each other at the same moment, so they begin their outbound handshake attempts together. This coordination is what makes hole punching work even through Port Restricted Cone NATs, where the NAT device checks both the IP address and port of incoming traffic.

UDP and TCP

By default, Enclave prefers a UDP substrate to build tunnels and transport data, because it avoids the overhead of tunnelling Ethernet frames over TCP. TCP-over-TCP can cause performance problems because both layers try to manage retransmission and congestion independently, leading to head-of-line blocking and throughput degradation.

However, some networks restrict outbound UDP traffic. To maximise compatibility, Enclave attempts both UDP and TCP connections and uses whichever succeeds. UDP hole punching is generally more reliable than TCP hole punching because UDP is connectionless - there is no three-way handshake that needs to complete before the NAT mapping is established.

Connection candidates and priority

Each peer reports three types of connection candidate to the Discovery Service. When building a tunnel, Enclave tries all available candidates in priority order and uses the highest-priority connection that succeeds.

Local addresses

These are the IP addresses of the system's local network adapters, typically RFC 1918 addresses like 192.168.1.10. If both peers are on the same LAN, or have a routed path between their local networks (such as an existing site-to-site VPN or MPLS link), Enclave will discover these addresses and prefer this direct local connection over any other.

Local candidates have the highest priority because they offer the lowest latency and do not need to traverse NAT at all. Without this preference, two servers in the same data centre would route traffic to the internet and back even though a local path exists.

Public addresses

These are the IP address and port as seen by the Discovery Service - usually the public-facing address of the NAT device closest to the peer. Connections across the internet use these addresses, with hole punching to traverse the NAT devices in between.

The Discovery Service learns each peer's public address by observing the source IP and port of the peer's outbound connection. This is similar to how STUN servers work in WebRTC, providing each client with its own server-reflexive address so it knows how it appears to the outside world.

Relay servers

Relay servers have the lowest priority. When direct connections fail entirely, they provide connectivity of last resort. Relays are only used after all other candidates have been exhausted. See the next section for details.

Relay servers

Some NAT configurations - particularly Symmetric NAT - make hole punching impractical because neither peer can predict the port the other's NAT device will assign. In these situations, and when restrictive firewall rules block all direct paths, Enclave falls back to relay servers.

How relays work

When a relay is needed, Enclave selects the server that results in the shortest total path between both peers based on geographic proximity. Both peers connect outbound to the relay server's public TCP endpoint. A 128-bit randomly generated authorisation code, created by the Discovery Service and unique to each introduction, is presented by each peer to the relay. This sets up bidirectional transparent forwarding of encrypted packets between the two peers. The authorisation code can only be used once.

End-to-end encryption

Relay servers are simple packet routers. The end-to-end encryption is still established directly between the two peers during the cryptographic handshake, so the relay has no ability to decrypt the traffic passing through it. From a security perspective, a relayed connection is no less secure than a direct one - the relay sees only opaque, encrypted data.

Relay throughput

Relay servers are shared infrastructure. Because they serve multiple connections, they have throughput restrictions compared to direct peer-to-peer connections. Direct connections are always preferred because they offer lower latency and higher bandwidth. If you find that connections are being relayed when you would expect them to be direct, see What are relayed connections, and how to avoid them? for troubleshooting steps.

Existing network compatibility

When Enclave gathers its local connection candidates, it considers any local network adapter other than its own as a valid candidate for traffic. This means Enclave works alongside existing connectivity you already have in place.

If you have a site-to-site VPN, an MPLS link, or any other private connectivity between locations, Enclave can use those paths. Peers on opposite ends of an existing tunnel will discover each other's local addresses through that path and may connect over it directly, without needing to traverse the public internet at all.

You can deploy Enclave gradually alongside your existing network without replacing anything.

Further reading

Last updated August 1, 2026