Managed CGNAT traversal for Nexus Atlas

Direct when possible. Connected throughout.

Let drones, vehicles, ground stations, and remote sites find and reach one another across 4G, 5G, and CGNAT—through a direct path when the network allows it, through authenticated relays when it does not, or through both for added resilience. No servers to rent, no port forwarding, and no networking degree required.

No public IP requiredNo inbound portsBuilt into Nexus Atlas
Nexus Atlas CGNAT traversal and multipath bonding Three cellular modems attempt a direct connection and maintain relay paths through CGNAT. Other bearers join them in one bonded encrypted Nexus Atlas connection. CGNAT direct — when the network allows it relayed — when it doesn't Atlas relay 4G modem 5G modem 5G modem …plus everything else you run MANET radio VSAT mmWave link HaLow/SiK one bonded, encrypted connection
Relay firstBring up a usable path with outbound-only connectivity.
Direct upgradeRemove the relay hop whenever both networks permit it.
Direct + N relaysKeep additional measured paths available for resilience.
One Atlas tunnelCombine cellular paths with every other bearer.
The reachability gap
A modem can reach the internet without being reachable from another vehicle.

Why cellular endpoints are hard to reach

01

Carrier-grade NAT blocks inbound paths

Cellular providers share public addresses across many subscribers. Your node can send traffic out, but another endpoint cannot simply dial back in.

02

Mappings change while platforms move

Cell changes, reconnects and carrier policy can replace an endpoint without warning. Static address assumptions do not survive mobile operations.

03

Traditional failover chooses one path

A classic tunnel normally commits to direct or relay. Nexus Atlas keeps every usable path measurable and available to the same scheduler.

How it works

Reachable first. Direct when possible. Resilient throughout.

Traversal happens inside the Nexus Atlas data plane, so a change from relay to direct—or back again—does not rebuild the encrypted tunnel.

See the complete connection sequence
01

Connect outward

Each node opens an authenticated outbound session to selected Atlas relays. CGNAT normally permits it; no inbound rule is required.

02

Meet immediately

The relay provides a working rendezvous path at once and lets the two endpoints exchange candidates safely.

03

Go direct when possible

The peers test the real network path together. If traversal succeeds, direct connectivity becomes another measured Atlas path.

04

Keep every useful path

Direct and multiple relay routes can stay available beside cellular, satellite, radio, Wi-Fi, mesh, or wired bearers.

Layer 01 · Cellular access

One 4G or 5G bearer

The physical connection supplied by a cellular modem.

directprimary relaysecondary relay
Layer 02 · Bearer diversity

Everything else the platform carries

Second carrier, satellite, tactical radio, Wi-Fi, mesh or wired.

Layer 03 · Nexus Atlas

One encrypted multipath tunnel

Applications see a normal Layer-3 connection while Atlas chooses how packets travel.

Two dimensions of resilience

More paths over cellular. More links beyond cellular.

A direct connection and several relay paths can coexist over a single modem. That cellular path set then sits beside every other physical bearer in the secure Atlas tunnel.

Important: “All available” does not mean “all carrying every packet.” Operators choose best-path, aggregation, duplication or strict-priority behaviour.
Policy, not hard-coded behaviour

Choose what resilience means for each deployment.

The same path inventory can optimize for latency, throughput, predictable failover or delivery confidence.

Best path

Send on the path with the lowest predicted delivery time and keep alternatives ready.

Aggregate

Distribute traffic across usable paths according to capacity and operator weights.

Duplicate

Replicate selected traffic across several paths when delivery confidence matters most.

1·2

Prioritize

Follow a strict operator-defined order for deterministic primary and fallback paths.

console.nexusatlas.net

See the console before you sign in.

Seven screens tell the whole story — the live fleet, enrollment, alerts, teams, the audit trail and the way in. Every screen is the real product, in your choice of light or dark.

Open the console
Self-service — enroll your first node in minutes.
Fleet at a glance — Nodes online, relays in use and live positions on the map — per-node traffic and uptime below.
Enrollment without secrets — Nodes join with a one-time code — the device proves its own key, nothing is copied by hand.
Offline alerts — Email or webhook when a node stays offline past your threshold — and again when it recovers.
Built for teams — Organizations, projects and roles — switch scope from the header and control who sees what.
Every action on the record — Who enrolled what, when, from where — a filterable audit trail per actor, action and project.
Made yours — Theme, time zone and formats saved to your account — identical on every browser you sign in from.
From the first screen — Google or username sign-in, security-key MFA, light and dark — the door matches the house.
⤢  View full size
Where reachability matters

Built for endpoints that do not stay put.

The traversal layer is useful wherever Atlas nodes must communicate through access networks they do not own or control.

LIVE PATH SET3 bearers · bonded
UGV 07 5G · 42 ms RADIO · 8 ms SAT · 96 ms COMMAND ATLAS

Autonomous systems

Drones, UGVs and ground stations using cellular beside dedicated radio, mesh or satellite links.

Explore scenario
NETWORK CHANGEhandover · tunnel intact
CARRIER A CARRIER B FLEET 12 OPS

Mobile fleets

Vehicle-to-vehicle and vehicle-to-command connectivity as towers, networks and addresses change.

Explore scenario
CGNAT TRAVERSALoutbound only
FIELD SITE ATLAS RELAY OFFICE NO PUBLIC IP · NO INBOUND RULE

Remote sites

Office-to-office and field infrastructure where fixed public IPs or inbound firewall changes are unavailable.

Explore scenario
Network

The relay network.

Atlas measures public relay candidates from both endpoints and selects the shared set that performs best—not simply the one with the nearest city label.

View live network
Public footprintTwo regions serving today
As of August 2026
EU-CENTRAL

Germany

Two observation addresses
Signed relay identity

Serving
NA-EAST

Canada

Two observation addresses
Signed relay identity

Serving
Next region

Where should the network expand?

Tell us what you need, where you need it, and why the location matters. Demand and operational constraints help us prioritize new relay capacity.

Private and on-premises

A relay estate reserved for your organization.

We can deploy dedicated nodes in an organization’s cloud, data centre, edge sites, or sovereign environment. Their addresses and identities can be pinned in customer configuration and kept entirely outside the public nexusatlas.net relay map.

Explore private deployment
Relay-region proposal

Tell us where connectivity is missing.

This helps us understand geographic demand and the operational reason behind it. Use this form to send the product team your requested location and operational requirements.

Security & privacy

Built so the relay never has to see your payload.

Hosted relays forward encrypted Atlas frames. Trust comes from cryptographic identities and a signed relay inventory—not from an IP address or an operator promise.

Read the security model
01

End-to-end tunnel encryption

Inner IP packets, application payloads, video, telemetry, and command traffic remain encrypted between Atlas endpoints.

02

Pinned relay identities

Every relay must prove the static identity published in the signed map. Redirecting its address is not enough to impersonate it.

03

Offline map authority

The relay inventory is Ed25519-signed with an offline key, so a compromised serving control plane cannot forge trusted membership.

04

No customer payloads on disk

Relay sessions are disposable forwarding state. The hosted relay does not terminate or persist the encrypted Atlas tunnel payload.

05

A precise metadata boundary

Relays can observe outer addresses, authenticated identities, timing, liveness, and byte counts. We state that boundary plainly.

Get early access

Bring us the network you cannot control.

Apply as a pilot partner if you have a deployment ready to test, or start evaluating Nexus Atlas Traversal as a future customer. Tell us enough to understand the endpoints, carriers, regions, and operational constraints involved.

01

Pilot partner

Run an early deployment with direct engineering contact and help shape priorities through real-world feedback.

02

Customer evaluation

Research architecture, security, deployment options, and commercial fit before committing to a pilot.

Already enrolled? Open the console
Early-access applicationUsually answered by the product team

Your application is sent to the Nexus Atlas product team. You can also email office@nexusatlas.io.