Pilot partner
Run an early deployment with direct engineering contact and help shape priorities through real-world feedback.
FAQ
Questions about reachability, relays, and what Atlas does next.
Short answers to the architectural and operational questions that usually appear before a pilot.
Product basics
What Traversal is.
Is this a separate VPN?
No. Traversal is an opt-in reachability and relay layer inside Nexus Atlas. Direct, punched, and relayed routes become ordinary measured paths for the existing encrypted Atlas tunnel.
Do both endpoints need Nexus Atlas?
Yes. Traversal connects enrolled Nexus Atlas nodes; it is not a public proxy or generic port-forwarding service. Both endpoints authenticate each other and establish outbound connectivity.
Do applications need to be modified?
Usually not. Applications use the stable Atlas network interface while encryption, path measurement, relaying, and failover happen underneath.
Is it TURN, STUN, or ICE?
It adopts STUN-compatible observation for NAT classification, replaces TURN with an Atlas-native opaque-frame relay, and replaces ICE nomination with relay rendezvous plus the Atlas probe and scheduling system.
Does every packet use a relay?
No. A relay provides immediate reachability and rendezvous. Direct paths are attempted where possible, and policy may keep direct and one or more relay paths available together.
Does Traversal bond several cellular modems?
Traversal makes paths through those modems reachable. The wider Nexus Atlas transport measures and schedules them beside other cellular, radio, satellite, Wi-Fi, mesh, or wired links.
Network and relays
How paths are found.
Why does CGNAT prevent direct inbound connections?
The carrier shares public addresses and controls the address-and-port mapping. A device can normally send outward, but an unrelated endpoint cannot create the reverse mapping or configure the carrier’s forwarding policy.
How does hole punching work?
Both nodes first learn how their traffic appears from the outside, then exchange those candidate addresses through a relay they already share. Each side sends probes toward the other at coordinated moments, and the outbound packets open the address mappings that let the peer’s packets in. A successful punch becomes an ordinary measured direct path beside the relay path—carrying the same end-to-end encrypted tunnel.
What happens when a node’s address changes mid-session?
The relay path recovers first: relay sessions are bound to authenticated identities rather than addresses, so traffic continues over the relay as soon as the node reaches it from its new address. The change also triggers a fresh observation, both nodes exchange updated candidate lists, and the direct path is punched again using the new addresses. Paths that are still alive are never disturbed by this process.
Does punching retry forever if it fails?
No. Punching is driven by new information, not by a timer. Each link makes one pass over the peer’s compatible candidates, and offers to a peer that never answers stop after about five minutes. Attempts reopen only when either side’s addresses actually change; a path that dies while addresses stay the same is left to the normal path-probing loop, which restores it on its own when connectivity returns.
What firewall access is required?
No inbound ports or public IP addresses are required. Nodes need outbound access to the configured Nexus Atlas relays; deployment-specific allowlists are provided during onboarding.
How is the “nearest” relay selected?
Atlas measures candidates from the participating endpoints. Observed network performance—not a city label alone—determines the useful shared relay set.
How much latency does relaying add?
It depends on the carriers, endpoints, and relay location. Atlas measures available paths and can use a direct path when possible; a pilot establishes the actual performance for your deployment.
What happens when a path or relay fails?
Atlas keeps available direct and relay paths measured. If one fails, traffic can move to another according to policy—but no software can maintain connectivity when every underlying network is unavailable.
What happens if the control plane is unavailable?
Clients retain the last verified relay map. Existing tunnels remain data-plane state, and reconnects can use the cached inventory.
Can we control where traffic is relayed?
Yes. Public relays are selected using measured path quality, while private or on-premises relays provide tighter control over placement, sovereignty, and access.
Can we run private relays?
Yes. Private and on-premises relay identities can be pinned in customer configuration without publication in the public relay map.
Security and privacy
What the service can see.
Can a hosted traversal relay read application traffic?
No. It forwards the encrypted Atlas tunnel frames. It can observe necessary outer metadata such as addresses, authenticated identities, timing, liveness, and byte counts.
How does a node authenticate a relay?
The signed map names each relay’s static identity. Connecting to the correct IP address is insufficient; the server must prove possession of the pinned key.
Is the relay map trusted because it uses HTTPS?
No. Transport security is useful, but map integrity comes from an Ed25519 signature checked against the authority key built into Atlas.
Is this the same trust model as Atlas multi-hop mesh forwarding?
No. Hosted traversal relays forward opaque endpoint-encrypted frames. Atlas mesh routing is a separate forwarding mode with its own hop and routing trust boundaries.
Deployment and access
How to get started.
Which platforms are available?
Nexus Atlas runs on Linux (x86-64 and ARM64) and on Android — both currently as evaluation builds issued during onboarding. The application tours and build requests live at nexusatlas.app; public signed packages are being prepared. Confirm platform and feature support for your specific deployment before a pilot.
Is Traversal production-ready?
Traversal is currently offered through guided early access. Supported platforms, regions, service levels, and production commitments are confirmed for each deployment.
Do I need a public IP or port forwarding?
No for relay-first connectivity. Each node initiates outbound sessions. A direct upgrade is used only when the current networks permit it.
What does the console do?
The console manages organizations, projects, node enrollment, status, relay use, alerts, audit, security, preferences, and available link metadata without becoming the tunnel data plane.
How is early access priced?
Subscription scope and early-access pricing are discussed during onboarding because hosted, private, and hybrid deployments have different operating requirements.