Mesh VPN: Part 4 — Headscale or WireGuard: your own server instead of Tailscale

Tailscale, cloud NetBird and ZeroTier are convenient, but network control in them remains with a third-party company: it verifies users, issues keys and access rules. If that is unacceptable — for security requirements, because of data storage in Russia, or simply on principle — there are two paths: your own Headscale management server or WireGuard configured manually.

Headscale: your own server for Tailscale clients

Headscale is an open implementation of the Tailscale coordination server for hosting on your own server. Devices use the regular official Tailscale clients, but connect not to the company’s cloud, but to your server.

Important caveats from the project description:

• Headscale is not affiliated with Tailscale Inc. It is an independent open project. One of its maintainers works at Tailscale and may contribute during work hours, but their changes are reviewed by the other maintainers.
• Narrow task: Headscale serves a single tailnet and is intended for personal use or a small organization, not for a large company with hundreds of teams.

As of September 2026 the latest stable version is v0.29.3, the minimum supported Tailscale client version is v1.80.0 (per the release notes). When upgrading Headscale, check this requirement: old clients on routers and NAS may stop connecting.

What is supported

According to Headscale documentation, most Tailscale features are implemented:

• MagicDNS and split DNS;
• access policies (ACL and grants), Tailscale SSH;
• subnet routers and exit nodes, automatic route approval;
• built-in DERP server for relaying;
• web-based registration, preauthorization keys and OpenID Connect login (for example, via Keycloak);
• Taildrop, ephemeral nodes, tags.

Not yet implemented, in particular, are OIDC groups in access rules, Funnel and Serve functions, and network flow logs.

How to connect a device

# on the server: create a user
headscale users create office

# on the client: connect to your server instead of the Tailscale cloud
tailscale up --login-server https://headscale.example.ru

# on the server: confirm the device using the identifier from the link
headscale auth register --user office --auth-id <AUTH_ID>

For servers, preauthorization keys are more convenient:

headscale preauthkeys create --user <USER_ID>
tailscale up --login-server https://headscale.example.ru --authkey <KEY>

Command syntax changed between versions, so check the documentation for the version you install.

What you will need

• a server with a static address and a domain name;
• a TLS certificate — clients connect over HTTPS;
• backup of the Headscale database and configuration: without them, if the server is lost you will have to re-register all devices;
• monitoring of availability and regular updates.

WireGuard manually

The second path is to forego a coordination server and configure WireGuard yourself. Each device gets a key pair, and its configuration lists peers: their public keys, addresses, and which networks are available via each.

According to the official WireGuard guide, keys are generated like this:

wg genkey | tee privatekey | wg pubkey > publickey

Minimal server configuration /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.10.0.2/32

And the client:

[Interface]
PrivateKey = <laptop private key>
Address = 10.10.0.2/24

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.ru:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

The interface is brought up with wg-quick up wg0. PersistentKeepalive maintains the connection through NAT, and AllowedIPs specifies which addresses are reachable via that peer.

Honest note about the manual option: building a full mesh network this way is hard. Each new device must be added to all others, and NAT traversal is not available — one side must have an externally reachable address. Therefore, manual setups usually form a “star” with a central server or connect several sites with static addresses. For dozens of devices across sites, Headscale or NetBird are more convenient.

MikroTik

WireGuard is supported in RouterOS 7 out of the box, so a MikroTik router can be either a server or a node in a manual network. Configuration per MikroTik documentation:

/interface/wireguard
add listen-port=13231 name=wireguard1
/ip/address
add address=10.10.0.1/24 interface=wireguard1
/interface/wireguard/peers
add allowed-address=10.10.0.2/32 interface=wireguard1 public-key="<key>"

Don’t forget to allow the incoming UDP port in the router’s firewall. More about router capabilities in the article “MikroTik: what kind of router is it and why it’s convenient for small business”.

There is no Tailscale client for RouterOS: the Tailscale downloads page lists only Windows, macOS, Linux, iOS and Android. RouterOS starting from version 7.4 can run containers (the container package is required and container mode must be enabled), and technically you can run the Linux client there, but neither MikroTik nor Tailscale officially support that option. It’s more reliable to connect the office network to Headscale or Tailscale via a Linux server or a virtual machine behind the router acting as the subnet router.

What to choose

Common mistakes

• Headscale without backups. The management server becomes the central element of the network.
• Updating Headscale without checking client versions. Old clients below the minimum version stop connecting.
• Identical subnets across sites. Routing becomes ambiguous.
• Private keys in a repository or shared folders. A WireGuard private key must remain only on its device.
• Manual WireGuard for dozens of devices. Maintenance turns into constant config edits — at that scale you need a coordination server.