Mesh Network
Cosineq
/koʊˈsiːnɪk/ • A post-quantum zero-trust mesh VPN that isolates every connection between devices and services. Complete control, with all the pieces rolled out in your own infrastructure.
Performance matters in Cosineq: relayed sessions sustain 992 Mbit/s on roughly one core of the relay. Direct peer-to-peer QuicN traffic runs at 11–12.3 Gbit/s.
Relay figure measured lan2 → relay → lan1, single TCP flow, batched forwarding. June 2026.
Every connection between two devices in a Cosineq mesh is its own isolated, authenticated, post-quantum QuicN tunnel. There is no flat network in the middle that everything shares. Each device connects explicitly to another device, all with unique secure identities. Access must be granted before a connection starts and every packet runs through filtering. Deploy it as an overlay mesh or a traditional server model; the choice is yours. Connectivity, resiliency, security - all three are fundamental to the Cosineq architecture.
The control plane
The mesh VPN that gives post-quantum connectivity to every device, individually.
- High availability from day one
- An active-active cluster of Cosineq mesh controllers that scales to however many you need to service your deployment. New controllers can be added without re-enrolling any device or STUN/relay subordinate.
- Server groups
- Designed for horizontal services scaling, such as VPN egress machines. Every server has its own key-based identity, individually revocable, and a device only needs to connect to a single address of the set. Add or remove systems from the server set at any time without bringing down the Cosineq mesh.
- Overlay networks that do not collide
- Independent and isolated overlay networks, with their own IPv4 and/or IPv6 subnets, and every device gets a stable address on that network just like a physical one. All services and routes advertised on the networks are policy-gated - for both who and what.
Relays and reachability
- High-performance relays when no direct path is available
- Post-quantum QUIC-session relays that forward peer-to-peer connections when the devices cannot reach each other directly. Along with a thin packet encapsulation for low latency, the controller determines and offers the shortest relay path for the devices to use.
- Too many kinds of NAT
- With NAT and firewalls enforced in most cases, Cosineq works to find a connection path through them. Devices attempt direct IPv6, direct IPv4, signed STUN with synchronised hole punching, and a relay. Transparent tunnel connection migration is featured to allow your device to keep the session when it migrates networks, which is common when you're on mobile.
Zero trust applied
- The receiving device enforces access policy
- Access control policy is checked at connection time and again for each packet on the receiver side. Denied connections are closed immediately.
- Extensive access policy
- Almost like a firewall but focussed only on mesh traffic.
Rules can be built from tags (labels) applied to users and devices.
A rule presents itself as
from tag:admin to tag:prodwith protocols and ports, rather than unintuitive addresses. - Local rules in addition to controller ones
- A device can block specific peers, drop inbound connections, filter by tag, and reject advertised routes. These only ever add restrictions to its inbound connections and do not loosen network policy.
- Device isolation
- Designed to be like classic VPNs, for businesses and VPN providers. Turn it on and clients only see and connect to the servers advertised; devices do not know of each other's identity or presence. All connection policies are still driven by the controller so knowing another device's identity does not mean a connection will succeed.
- Anti-spoofing at the tunnel
- Only packets belonging to the peer and its authorised backend routes are permitted. Everything else gets dropped.
The clients
- Desktop, mobile, headless
- Linux, Windows and macOS desktop clients, native iPhone, iPad, macOS, and Android apps, along with root and rootless command-line clients. Graphical apps have a built-in SSH client for direct mesh-to-host access.
- Several meshes, one install
- Multiple profiles on all clients with pinned identity keys, each tied to its own independent controller managed or direct peer-to-peer setups.
- Services advertisement, not just hosts
- A device can advertise what it hosts, say a media server or a traditional service, to appear in the mesh network roster. Example use: SSH and RDP consoles open in one click from the device view.
- Unprivileged containers
- Userstack-only mode removes operating system changes entirely and does not rely on a kernel tunnel device: no administrative privileges, no host routing changes, no kernel firewall rules and no domain resolver rewriting. SOCKS5 at the initiator and completely transparent ICMP, UDP and TCP connections at the target.