Frequently asked

No — that is the design. A new account is created in pending activation: it can sign in, and it can connect to nothing. An administrator has to activate it. You can sign in deliberately, so you can see the state you are in rather than staring at a login failure.

Your account page shows exactly where you stand, and the server list comes back empty with the reason attached.

No new connections. A ticket cannot be redeemed without the master, and there is no fallback — that is the entire authorization model, so it fails closed.

Existing tunnels keep working for a grace period configured on each node, fifteen minutes by default, and are then torn down. A brief blip should not disconnect everyone; a prolonged one should not leave revoked accounts tunnelling indefinitely. A security-sensitive deployment sets the grace to zero.

Only if your administrator allows it. Two independent limits apply: devices, which is how many machines may hold credentials at all, and concurrent sessions, which is how many may be tunnelled at once. Both default to one and both are per account.

You can revoke one of your own devices to free a slot, subject to a cooldown that stops a device slot being passed back and forth between friends.

Not by giving them the password. Signing in also requires a signature from a key that was generated on your machine and is held by the operating system's key store — so they would have to extract that key, not merely learn a secret. Past the device limit, enrolling a new machine is refused outright.

Nothing about what. A node reports byte counts and handshake timestamps; there is no destination, no DNS query and no payload anywhere in the system, because nothing collects them. The absence is structural, not a setting somebody could switch on.

What is kept: bytes in and out per session, which node and when, and your public IP at connect time for abuse handling — that last one on its own retention window, thirty days by default. The full list is here.

Because it is fast, small enough to audit, and — importantly here — it has no concept of logging in. A peer either exists or it does not, which is what lets authorization happen entirely before the peer is created, where it can be enforced rather than advised.

The cost is that WireGuard is UDP-only and a restrictive network can block it. There is no TCP/443 fallback today; the node's data plane is behind an interface that allows one to be added without touching the master or the clients.

Clients: Windows 10 and 11, Android and iOS. Nodes: Linux and Windows Server. Master: anywhere .NET 10 runs, with SQL Server behind it.

The apps page says plainly which parts have been executed on real hardware and which have not — worth reading before you commit to a rollout.

A compromised node sees the traffic passing through it. That is inherent to every VPN and no design removes it. What this one removes is everything else: a node holds no user credentials, has no database access, cannot mint a session, and cannot redeem a ticket that was issued for a different node.

Its certificate is revoked centrally by thumbprint, and the revocation takes effect at the TLS layer on the node's next call — there is no revocation list to distribute and no responder to be down.

It is available to every account and required of none. Two-factor here is per account, not per deployment: you are asked for a code exactly when you have enrolled one, and you turn it on and off from your own security page. Administrators should enrol one.

That is the point of it. One master service, an agent per node, and the clients — nothing phones anywhere. The deployment page covers the ports, the database, the first administrator and the traps worth knowing before you hit them.

Send us a message. It goes to the administrators of this master, with a subject and whatever detail you can give, and it is read by a person.