How VeilNet Works

Architecture #

Overview #

VeilNet is an ephemeral secure network that differs fundamentally from a Peer-to-Peer mesh overlay VPN network. It consists of:

• VeilNet Master: The control-channel message broker that enables the Reinforcement Learning routing algorithm used in the Anchor protocol.
• VeilNet Guardian: The authentication server for both users and VeilNet Conflux nodes. User authentication relies on Supabase, while Conflux node authentication uses a JWT system with both long-lived and short-lived tokens.
• VeilNet Conflux: The connector software that runs on the user’s virtual or physical machines, as well as container environments, to form the decentralised network.
• VeilNet Conflux Application: The frontend application that provides user access to VeilNet, available as a GUI on Android and Windows, or as a container or binary on Linux and macOS.

The key differences from a mesh overlay VPN network (such as Tailscale or Netbird) are:

• No Coordination Server: VeilNet is a decentralised network with no central server managing network state. The network forms automatically through VeilNet Conflux nodes, similar in principle to the TOR network but without a central registry. Encryption keys and routing decisions are generated at runtime and never stored. Conflux nodes do not synchronise configuration files, unlike mesh overlay VPN networks.
• Non-mesh and Ephemeral: In VeilNet, a machine or any entity joining the network is called a node, as they do not establish persistent peerings. Data channels between nodes are created on demand and dissolve when idle. No connection is persistent. Multi-hop transmission is natively supported by the Anchor protocol, resulting in a topology that is never fixed or static.
• Non-WireGuard: VeilNet is not based on WireGuard by design. WireGuard introduces significant incompatibilities with Kubernetes container networks and is fundamentally incompatible with Kyber Key Exchange Mechanism and Dilithium Digital Signature, the post-quantum cryptography standards chosen by VeilNet.

Authentication & Management Service: #

The authentication and management service of VeilNet is not involved in the overlay network itself. Their responsibilities include:

• User authentication and subscription: VeilNet Guardian handles all operations between Supabase and Stripe for user authentication and subscription management.
• VeilNet Conflux authentication: VeilNet Guardian authenticates a VeilNet Conflux instance before it joins the network. After validating a long-lived registration token or a short-lived conflux-token, it issues a certificate that permits the instance to join the global control channel. This exchange occurs only once when a new Conflux instance requests access. VeilNet Guardian is not involved in any further operations performed by that instance, except for issuing a Kill command to stop it.
• VeilNet Plane & Team management: VeilNet Guardian provides API endpoints for managing VeilNet Private Planes and teams. Access control in VeilNet is not based on subnets or IP addresses. Instead, it uses an identity-based model that simplifies the creation of a zero-trust network.
• VeilNet IP management: VeilNet does not use Carrier Grade NAT address space, and its address space can be any range, including public IP ranges. This is possible because the Anchor protocol routes based on VeilNet Conflux signatures rather than IP addresses. A VeilNet Plane can define any IP range, and each Conflux instance receives an IP address from that range. This IP address exists solely to maintain compatibility with external IP-based networks.

Decentralised Service: #

All other functionalities are handled by the VeilNet Conflux instance itself, which includes:

• Encryption Key Exchange: VeilNet uses symmetric encryption (AES-GCM-256) rather than the less secure asymmetric ChaCha20 used by WireGuard. There are no public or private keys. Each VeilNet Conflux derives a shared secret locally using Kyber KEM.
• Packet Authentication: VeilNet provides packet-level authentication to prevent tampering during multi-hop transmission. Each packet is signed using Dilithium digital signatures, which can be verified by the destination Conflux node.
• Conflux Authentication: VeilNet Conflux instances verify each other through cryptographically derived identity hashes associated with Dilithium signatures. If any instance attempts to impersonate another, its packets will fail Dilithium verification.
• Network Update: VeilNet Conflux instances do not receive network updates from any central server. They exchange information through the control channel, a NATS super cluster, allowing authenticated nodes to broadcast updates at runtime with sub-second delay.
• Routing: VeilNet Conflux instances do not rely on host routing tables. Subrouters or manually advertised routes required by other overlay VPNs are unnecessary. Conflux nodes use a multi-agent cooperative reinforcement learning algorithm via the control channel, combined with distributed dynamic programming to reduce convergence time. They establish:
  • a stream (a logical secure channel per destination),
  • then routes (multi-hop and multi-path forwarding),
  • and finally a tether (a set of aggregated WebRTC data channels for improved performance).
• Access Control: Access control is enforced at the Conflux instance level. Although any host or local network reachable by the machine running Conflux appears reachable from an IP perspective, VeilNet enforces identity-based access rules. Only verified instances may communicate. Untrusted instances are ignored, and their packets are silently dropped, keeping the node invisible.
• Load balancing & Self-healing: VeilNet Conflux instances handle load balancing automatically at a sub-routine level. In a Conflux instance, each stream is independent per destination, unlike WireGuard where traffic to all destinations uses the same encrypted tunnel. Each stream has its own independent subroutine for route discovery and data transmission through a tether. This enables VeilNet Conflux to maintain sub-millisecond overhead once a stream stabilises, even while performing more complex cryptographic operations. It also allows Conflux instances to switch routes dynamically, self-heal from network failures, and guarantee data delivery unless the destination is offline.
• Relay: VeilNet Conflux instances can automatically serve as relays for other verified instances without any configuration. This significantly reduces or eliminates the need for external relays for WebRTC data channels, which other overlay VPN networks depend on. It also enables VeilNet to function as a privacy network capable of replacing TOR.

Supporting Service: #

To ensure the decentralised network operates without downtime, VeilNet also relies on supporting services managed by providers such as Cloudflare, AWS and Google Cloud:

• NATS Super Cluster: The VeilNet control channel is a NATS super cluster spanning all continents, deployed across both AWS and Google Cloud. The likelihood of it becoming unavailable would require a species-level extinction event or a global internet shutdown.
• Cloudflare TURN: VeilNet does not use the open-source Coturn implementation for its Pion WebRTC data channels. Instead, it uses Cloudflare TURN, supported by Cloudflare’s global CDN, for improved performance and reliability. In practice, VeilNet Conflux instances automatically act as relays for one another, so only STUN functionality is used in 99 per cent of cases. TURN is reserved for extreme scenarios, including hostile network environments.