Super Peers
Netsody devices connect to each other directly whenever possible. Super peers are publicly reachable helper nodes that make those direct connections possible and take over as a fallback when no direct path exists. They are part of the data plane.
A super peer is never a mandatory hop: traffic uses a direct path first and only goes through a super peer when no direct path can be established.
What a super peer does
A super peer has three tasks:
- Discovery. It acts as a meeting point where devices locate each other by their public-key identity, so no device needs a fixed, publicly reachable address.
- Direct-connection establishment. It helps two devices traverse NATs and firewalls to open a direct, end-to-end encrypted connection.
- Relay fallback. When a direct connection cannot be established, for example behind a strict firewall, it forwards traffic between the two devices so they can still communicate.
See Connectivity and Data Plane for the transports involved: QUIC for direct connections, MASQUE over HTTP/3 for relaying, and HTTP/2 over TLS as a relay fallback when UDP or QUIC is blocked.
What a super peer can see
All traffic between Netsody devices is end-to-end encrypted and authenticated between the two peers. A super peer that relays a connection forwards ciphertext only and cannot read the payload. Devices authenticate each other by their public key, and access is enforced locally by the agent following Zero Trust principles. A super peer is not a policy authority and is not trusted with the traffic contents.
The controller is never in the data path, not even for relayed connections.
Operations and self-hosting
Netsody operates public super peers in Europe, North America, and the Asia-Pacific region, so devices in these regions have a nearby meeting point and relay available without any setup.
You can also run your own super peer, for example to keep relay traffic on your own infrastructure. The Self-Hosting guide describes running the Netsody super peer (netsody-sp) alongside the controller.
A super peer belongs to the data plane only and never handles the network configuration. A self-hosted super peer therefore also works with the hosted Netsody controller: you do not have to self-host the controller to use your own super peers. Reasons to run your own include:
- placing a super peer closer to your own nodes for lower latency, or
- keeping all discovery signaling and relayed traffic on super peers you operate,
while still managing your networks through the hosted controller and dashboard. Point your agents at your own super peer with netsody login --super-peer …; repeat the flag to configure several.
You can mix the Netsody-operated super peers with your own, or run only your own. Each device signals through all super peers available to it, and when a connection has to be relayed, the agent selects one of the available super peers automatically.