I found Nebula at first. It works well, requiring no central server or public SSL certificate.

Conversely admins need to sign and distribute their own certificates with nebula-cert, and they are used to authorize and encrypt connections.

The minimal requirement to run a Nebula network is a machine with a public, static IP and a port available (a cheapest VPS would work). This machine will serve as a “lighthouse” which other nodes use to find each other. You can have multiple lighthouses and the network is available with at least one of them online, which is handy during migration.

Nebula will try its best at NAT traversal, but if that fails it try to relay connections through nodes configured to work as relays. I simply use lighthouses as relays because they are accessible from every node.¹ A simple (NixOS-based, check official docs for regular ones) lighthouse configuration looks like this:

services.nebula.networks."<name>" = {
  ca = "/etc/nebula/ca.crt";        # it would be better to use agenix or sops-nix
  cert = "/etc/nebula/host.crt";    # but I'm too lazy to touch a working config
  key = "/etc/nebula/host.key";
  isLighthouse = true;
  isRelay = true;
  listen.port = 4242;
};

networking.firewall = {
  allowedTCPPorts = [ 4242 ];
  allowedUDPPorts = [ 4242 ];
};

And a client configuration is a bit more complicated than that, because it needs to know where to find a lighthouse, and to configure its firewall² to accept connections.

services.nebula.networks."<name>" = {
  ca = "/etc/nebula/ca.crt";
  cert = "/etc/nebula/host.crt";
  key = "/etc/nebula/host.key";
  staticHostMap = {
    # nebula ip is the one you assigned to the machine while signing its cert.
    # you can check it with `nebula-cert print -path host.crt`
    "<lighthouse-nebula-ip>" = [ "<lighthouse-public-address>:<port>" ];
  };
  lighthouses = [ "<lighthouse-nebula-ip>" ];
  relays = [ "<lighthouse-nebula-ip>" ];
  # I only have trusted devices in the network,
  # if that's not true use a more strict config
  firewall = let any = [{
    host = "any";
    port = "any";
    proto = "any";
  }]; in {
    inbound = any;
    outbound = any;
  };
};

networking.firewall = {
  allowedTCPPorts = [ 4242 ];
  allowedUDPPorts = [ 4242 ];
};

The mobile app works similarly, just set the same information up with the GUI. Beware that the mobile client doesn’t allow any inbound connections and the firewall is not configurable as of now (2025-07).

Tailscale solves the problems coming with Nebula, at the expense of a central server, and additionally requiring a valid SSL certificate. Normally their clients connect to the Tailscale coordination server to give a smooth onboarding experience, but I don’t want to depend on freemium services, and they do mess up sometimes. Luckily there’s a self-hosted solution called Headscale for personal use scenarios.

In Tailscale, the coordination server is not a regular node anymore. It is a dedicated public service that handles not only service discovery, but also client registration, key distribution and access control. And relays (DERP servers) are a standalone service that can be hosted separately from the coordination server. Headscale is a coordination server implementation that has simplified access control and account system, with an embedded DERP server.

To run Headscale with embedded DERP server^{1 2} (again in NixOS, refer to official docs otherwise):

services.headscale = {
  enable = true;
  address = "0.0.0.0"; # this is the listen address
  settings = {
    server_url = "<public-url-of-the-server>";
    derp = {
      server = {
        enabled = true;
        region_id = 999;
        region_code = "hsc";
        region_name = "Headscale embedded";
        stun_listen_addr = "<listen-addr>:<listen-port>";
        ipv4 = "<public-ipv4-addr>";
      };
      urls = []; # this disables DERP servers provided by Tailscale
    };
    # set these if you don't acquire certs with headscale
    # note you may also want to set `services.headscale.group` to access certs
    tls_cert_path = "<tls-cert>";
    tls_key_path = "<tls-key>";
    dns = {
      # note that this shouldn't be the same as your server's public domain
      # I use an nonexistent TLD like .tail
      base_domain = "<magic-dns-domain>";
    };
  };
};

This is a very basic config, so you may want to checkout the reference config file for more options available.

Once the Headscale service is up and running you need to first set it up.

headscale users create <user-name>

This user name is required in following auth process of clients.

In contrast it’s much simpler to register and run a Tailscale client. The vanilla client is FOSS so I can just go with it:

services.tailscale = {
  enable = true;
  openFirewall = true;
  extraUpFlags = [
    "--login-server"
    "<your-headscale-address>"
  ];
  extraDaemonFlags = [
    "--no-logs-no-support" # this disables telemetry
  ];
  # this configures your system to be able to serve as an exit node
  # (with `sudo tailscale set --advertise-exit-node`,
  # or put `--advertise-exit-node` in `extraSetFlags`)
  useRoutingFeatures = "server";
  # see below
  authKeyFile = "<auth-key>";
};

# prevent tailscale from using nebula interface
systemd.services.tailscaled.serviceConfig = {
  RestrictNetworkInterfaces = "lo <interfaces-other-than-nebula>";
};

This needs some explanation. Basically with this config, Nix generates a systemd service, that starts Tailscale daemon with tailscaled --no-log-no-support <other-flags-omitted> then calls tailscale up once with the given auth key. Some intervention is needed because Tailscale doesn’t avoid Nebula interfaces and this may lead to various issues (Nebula is smart enough to avoid routing through Tailscale so the reverse doesn’t hold).

There are two flows to register a new client with Headscale (official docs here).

1. Non-interactively with a pre-generated key:

   # on the server
   headscale preauthkeys create --user <user-name>
   

   This generates a one-time key that you can put in aforementioned authKeyFile (effective for one hour by default). Deploy the config with the key on your device to log it into the network.

2. Interactively without setting the key:

   # on the client device
   tailscale login --login-server <user-name>
   

   This leads to a web page on the server that shows a key, then you need to register the client with the key.

   # on the server
   headscale nodes register --user <user-name> --key <key-on-the-page>
   

In both cases you only need to do this once per client/device.

On mobile devices it’s even simpler, you need to go out of the way to set your login server but that’s basically it. Upon first login the interactive login page shows up with the key, and again you run headscale nodes register to register the device.

security.acme.acceptTerms = true;
security.acme.certs."<your-domain>" = {
  email = "<your-email>";
  dnsProvider = "<dns-provider>";
  # agenix path to the systemd environmentFile in my case,
  # free to use all other means to provide access keys
  environmentFile = config.age.secrets.acme-env.path;
};

services.headscale = {
  # choose a atypical port
  port = 11366;
  # other options stays the same, omitted
  settings = {
    server_url = "https://<your-domain>:11366";
    derp = {
      server = {
        # anything different from the headscale server port
        stun_listen_addr = "0.0.0.0:11367";
        # ...
      };
    # ...
  };
};

# Also open the corresponding ports in firewall!

Occasionally I run a Windows VM inside my Linux laptop. I need to access it remotely as well. Luckily enough, a tunnel to the virtual machine network can be opened with a one-liner using SSH:

ssh -L 3389:192.168.122.84:3389 <device-running-vm>

This maps 192.168.122.84:3389 (IP address of the virtual machine in my case, and the default port of Microsoft RDP service) on the remote host to localhost:3389. An RDP client can then connect to 127.0.0.1 to access the remote virtual machine. This time I can just use the Microsoft RDP client on mobile to log in.