Introduction
Learn how the anchor protocol runs a network with no central server, and how it compares with VPN gateways, reverse proxies and mesh VPNs.
Every machine on a VeilNet network runs an anchor, and every anchor does the same work. Each anchor checks its peers itself and finds the rest of its realm through gossip. It also relays traffic for other members when the realm tree allows it.
Machines belong to realms, and realms form a tree. Each machine holds a credential chain, a short series of post-quantum signatures from the top of the tree down to the machine. Every identity is an ML-DSA key, and every connection uses ML-KEM key exchange.
Your guardian, your organisation's control suite, issues every credential. Admission, routing and relaying run without it.
Comparing Zero-Trust Designs
Before VeilNet, remote access used three designs. Each design fixed the limits of the one before it, but each kept a central component.
Attackers target that central component, and when it fails, the whole network is affected. When a vendor runs it, the vendor also controls your network. Step through the four designs below.
A VPN gateway: tunnel into the network. Machines connect through one gateway that faces the internet. Attackers target the gateway, and anyone who gets past it can reach the whole network behind it. You run the gateway yourself.
IPsec · OpenVPN · WireGuard
A reverse proxy: hide services behind a cloud. Services sit behind a vendor's cloud, and every connection passes through it. You manage identity and policy in the vendor's console. An outage of the vendor's cloud affects every customer at once.
cloudflared · Twingate
A mesh VPN: connect machines directly. Machines connect to each other directly. A coordination server decides who is a member, and distributes keys and policy. When NAT blocks a direct connection, the vendor's relay servers carry the traffic.
Tailscale · NetBird · ZeroTier
VeilNet: remove the centre. Each machine checks every peer's credential chain itself, and finds the rest of its realm through gossip. Members relay traffic for each other where the tree allows it, and a relay cannot read what it carries. The whole network runs on your own infrastructure.
Each design is grouped by its core architecture. If you host the centre yourself, you change who runs it, but the centre is still there.
| VPN gateway | Reverse proxy | Mesh VPN | VeilNet | |
|---|---|---|---|---|
| The centre | The gateway | The vendor's cloud | The coordination server | None |
| Checks membership | The gateway | The vendor's cloud | Each machine, with keys the server pushed | Each peer, against a signed credential chain |
| Knows where each member is | The gateway | The vendor | The coordination server | Every member, through gossip |
| Carries traffic that NAT blocks | The gateway | The vendor's cloud | The vendor's relay servers | A member of the same realm or a realm above it, encrypted end to end |
| When the centre fails | No access | No access | Membership and keys stop changing | There is no centre to fail |
| Who holds control | You | The vendor's console | The vendor, unless you host the control plane yourself | You, from your realm key to every machine |
| Post-quantum | Added later, where it exists | Added later, where it exists | Added later, where it exists | ML-KEM and ML-DSA, required on every connection |
The three earlier designs all predate the 2024 ML-KEM and ML-DSA standards, so any post-quantum support they offer was added to a classical design. VeilNet requires ML-KEM and ML-DSA on every connection, so there is no post-quantum option to turn on.
Checking Every Peer
Anchors are not divided into classes. Every anchor can be a peer, a relay and a starting point for machines that join. Every anchor also tells its peers which address it sees them at.
An anchor checks every peer's credential chain itself before it accepts a connection. It checks the chain when the peer first knocks, and again after the encrypted handshake.
- No lookup. An anchor asks no server when a peer connects, so the check works even when no other machine is reachable. There is no gateway to get past and no console to compromise.
- No shared secret. Membership is a signature, not a password, so there is no network-wide key to steal.
- A silent port. An anchor sends nothing back to a sender without a valid chain: no handshake, no reset and no error. If the host also drops unsolicited UDP, the port looks like any other filtered port.
Finding Peers by Gossip
Gossip is how anchors share what they know about their realm. A new machine starts with a few addresses, the bootstrap list in its credential file. Over its first connection, it receives everything that peer knows about the realm.
From then on, each anchor passes every change to its connected peers as soon as it learns of it. Every member holds the realm's whole membership, so it finds a peer in its own memory. There is no directory server to query, and none that can go down.
A machine that leaves sends a signed departure notice, so its peers do not have to wait for a timeout.
- Derived addresses. Every member computes each other member's overlay address from its identity. All members reach the same result without negotiating.
- Signed route offers. The routes a machine offers carry its ML-DSA signature, because other machines make routing decisions based on them.
Relaying Traffic
Machines exchange data directly where the network allows it, and through up to five relays where it does not. Any member can be a relay, and the realm tree decides which realms it relays for:
- Members of a realm relay for each other.
- Members of a realm relay for every realm beneath it. For example, the bootstrap nodes in your organisation's realm relay for your sub-realms.
- A realm never relays for the realms above it, and sibling realms never relay for each other.
A relay is admitted by the same tree, but you do not need to trust it. Traffic is encrypted end to end. A relay learns only where to send the traffic next, not where it began.
| A relay | Details |
|---|---|
| Cannot see | What it carries, what kind of traffic it is, or the whole route |
| Cannot do | Change the traffic or its keys without detection, or pretend to be either end |
Inspecting Your Machines
You can see all of this on any machine that runs conflux, without asking a server:
- To list this machine's view of its realm, run
sudo conflux peers. TheSTATEcolumn readsconnectedfor peers with a live connection, andknownfor the rest. TheDATAcolumn readsyesfor peers this machine may exchange data with. - To see the anchor's own reachability, run
sudo conflux statusand look underanchor:. The anchor works this out from what its peers observe. - To check that the port is silent, send any packet to a member's port from a machine outside your network. Nothing comes back.