The Technology Behind Netrinos

Overview

Netrinos creates a full mesh network where every device maintains direct encrypted WireGuard tunnels to all other devices. Unlike traditional VPN architectures that route traffic through a central server, the mesh topology enables direct peer-to-peer communication with no single point of failure.

The connections are bidirectional, creating an overlay network that functions like a LAN across the public internet. Once connected, any device can initiate communication with any other device, regardless of which device is behind NAT. This enables use cases that traditional VPNs cannot support, such as a home server pushing notifications to a laptop or a laptop accessing a home NAS from anywhere.

The system handles all configuration automatically. Devices authenticate once during installation, then cryptographic keys are distributed and connections are established without user intervention. NAT traversal works through firewalls and carrier-grade NAT without requiring port forwarding or network configuration. All communication is encrypted end-to-end.

WireGuard Foundation

Netrinos uses WireGuard for all data plane encryption. WireGuard is a VPN protocol with native support on Linux, Windows, macOS, iOS, and Android, and is used in production by Cloudflare, Mullvad, NordVPN, and other large-scale deployments.

Why WireGuard?

• Performance: The protocol has minimal overhead. Benchmarks typically show 3-4x higher throughput compared to OpenVPN.
• Cryptography: ChaCha20 for symmetric encryption, Poly1305 for authentication, Curve25519 for key exchange, BLAKE2s for hashing, HKDF for key derivation.
• Codebase size: Approximately 4,000 lines of code compared to 100,000+ for OpenVPN or IPsec implementations.

Cryptographic Properties

WireGuard provides these security guarantees:

• Identity = Public Key: Each device is identified by its Curve25519 public key. The protocol does not use certificates, PKI, or certificate authorities. Possession of the private key constitutes device identity.
• Perfect Forward Secrecy: Session keys are derived using ephemeral Diffie-Hellman key exchange. Compromise of a device does not expose past session traffic. Session keys rotate every 2 minutes.
• Replay Protection: The protocol uses nonce counters and timestamp-based handshake cookies to prevent replay attacks. It handles packet reordering and duplication.
• Attack Surface: The protocol does not respond to unauthenticated packets, making it silent to port scanners and network probes.

See the WireGuard protocol documentation for full technical details.

The Netrinos Layer

WireGuard is a point-to-point protocol that requires manual configuration of keys, endpoints, and allowed IPs. Netrinos adds a configuration management layer that automates these tasks to create a zero-configuration mesh network. Control plane communication between devices and the Netrinos broker (rendezvous server) uses TLS encryption over HTTPS.

Key Management

Each device generates its own WireGuard keypair. The private key never leaves the device. If the private key is lost for some reason, a new keypair will be generated and Netrinos will manage the public key distribution.

During installation, the client authenticates once using account credentials. It registers its public key with the broker and receives the public keys of other authorized devices. Subsequent authentication is cryptographic and does not use the password.

When a device is removed from an account, its public key is removed from the distribution list. Other devices stop accepting connections from that key on their next synchronization cycle. This revocation process does not require access to the removed device.

NAT Traversal

Most devices operate behind NAT, whether from security firewalls, home routers, cellular modems, carrier-grade NAT, or combinations thereof. Traditional VPNs require port forwarding or DMZ configuration. Netrinos uses coordinated hole punching (also called UDP hole punching or NAT traversal) instead.

When a device initiates an outbound UDP connection, the NAT device creates a temporary mapping that allows response traffic. The broker records each connection's public endpoint (IP and port) and coordinates simultaneous connection attempts between peers. Both devices send packets at the same time, creating bidirectional NAT mappings and establishing a direct tunnel.

This approach works through complex NAT chains, such as multiple layers of routing devices and CGNAT, without requiring firewall configuration or port forwarding.

In rare cases where hole punching fails, traffic routes through a relay server as a fallback. The connection remains end-to-end encrypted.

Mesh Topology

Netrinos uses a full mesh topology where each device maintains a direct WireGuard tunnel to every other device. This differs fundamentally from hub-and-spoke VPN architectures where all traffic routes through a central server.

In a mesh topology, traffic flows directly between peers without routing through intermediate servers. This optimizes latency and bandwidth, as performance is limited only by the direct network path between communicating devices. Individual device failures do not affect other connections in the mesh.

Mesh connections are bidirectional. Once established, traffic can flow in either direction between peers, regardless of which device is behind NAT. This differs from traditional VPN architectures where only clients can initiate connections to servers.

Mesh vs Hub-and-Spoke

Network Addressing

Each device receives a static IP address from the 100.64.0.0/10 range. This is shared address space defined in RFC 6598, commonly used for carrier-grade NAT. The assigned IP address persists across network changes, reboots, and reinstalls while the device remains in the account. Because these addresses exist only within the WireGuard tunnels, they do not conflict with the same address ranges used elsewhere on the Internet or in private networks.

Devices are also assigned DNS names in the format devicename.account.2ho.ca, which are registered in public DNS. These names provide a convenient way to reference devices, though the static IP addresses can be used directly as well.

Connection Establishment

Connection establishment follows this sequence:

1. Device 1 Contacts Broker: Device 1 provides its public key and network endpoint. The broker stores this information and returns connection details for other authorized devices in the network.
2. Device 2 Contacts Broker: Device 2 provides its public key and network endpoint. The broker stores this information and returns connection details for other authorized devices, including Device 1.
3. Direct Tunnel Established: The two devices establish a direct WireGuard tunnel. Traffic flows peer-to-peer without passing through any intermediate server.

The broker facilitates discovery and NAT traversal coordination but is never involved in the data path. After the WireGuard handshake completes, all communication flows directly between peers.

If the peers cannot establish a direct connection, the system automatically falls back to a relay server that is reachable by both devices. This fallback is infrequent and occurs only when restrictive NAT configurations prevent direct hole punching. The relayed traffic remains end-to-end encrypted and the relay cannot decrypt it.

Advanced Features

The following capabilities are available exclusively in Netrinos Pro.

Access Control

Access control policies determine which devices can communicate with each other within the mesh. Netrinos acts as a configuration manager for native operating system firewalls, implementing policies at the kernel level for maximum performance and security.

On Linux, Netrinos configures nftables rules to enforce access policies. On macOS, it uses the pf (packet filter) firewall. On Windows, Netrinos implements a custom Windows Filtering Platform (WFP) driver that operates independently of Windows Firewall, which is frequently misconfigured or disabled by users. This separation ensures that access control policies remain enforced regardless of the Windows Firewall state.

When a device is removed from the account, its public key is revoked and removed from all other devices. This removes the WireGuard tunnel and updates the access control list. The local firewall rules are updated automatically to enforce the new policy.

Network Routing

Network routing allows devices to access IP subnets beyond the mesh itself. A device can be configured as a gateway node, performing network address translation for traffic to specific networks. For example, you would configure a route on your laptop to access your home network (192.168.1.0/24) through a gateway device at home. This allows the laptop to reach resources like a NAS without installing Netrinos on those resources. A gateway on a cloud server can provide access to region-restricted content or other networks beyond that server.

Routes are configured on each device individually. Different gateway nodes can provide access to different networks, and each device configures which gateway to use for which destination networks. Traffic is source NAT'd using nftables masquerade (Linux), pf NAT (macOS), or Windows NAT, appearing to originate from the gateway device's location.

The local routing table is updated automatically using platform-specific mechanisms: ip route on Linux, route on macOS, and the Windows routing table on Windows.

Platform Support