juanfont

C'est pour quel usage. Tu connais Headscale ? Ca permet beaucoup de choses sympa, sans se faire chier. juanfont/headscale

Tailscale Patched Tailworm. Your SSH Policy Still Sets the Blast Radius A compromised device inside a tailnet could abuse Tailscale SSH to do more than its configured local user should be able to do. Tailscale has released fixes in v1.104.4. But the conditions matter: this was not an unauthenticated attack from the public internet, and the separate Headscale findings need their own status check. The useful lesson is about two security boundaries. A tailnet policy decides which devices may connect. The SSH server must then keep each approved session inside the permissions granted to that local user. The Tailworm report found failures in that second boundary. What Tailscale fixed Tailscale SSH is an SSH server built into the Tailscale client. It uses device identity and tailnet policy to decide who may connect, which machine they may reach, and which local account they may use. That access check is not the issue Tailscale described in its response. The company says the reported bugs affected what an already-approved SSH session could do after connection. Under certain conditions, the session could perform operations beyond the configured local user's privileges, including through SSH forwarding. Tailscale says exploitation required an attacker to already control an authorized device in the tailnet, have SSH access explicitly allowed by policy, and meet the conditions for the vulnerable feature. The findings did not let a random internet user connect to arbitrary Tailscale SSH servers. The fixes are in Tailscale v1.104.4 and later. Tailscale recommends updating, reviewing which users and devices have SSH access, and considering SSH check mode for sensitive systems. Check mode adds an authentication step before access is granted. What the Tailworm report covered Security researcher Erica Windisch's report tested Tailscale v1.104.2 and Headscale v0.29.5 between October 22 and 24, 2026. It documented more than the SSH issue. The report also examined Serve and Funnel, the experimental Conn25 app connector, a relay client, and Headscale's control server. The report described three Tailscale SSH findings involving Unix socket forwarding and path checks. In its lab, the researcher reported root-level operations on target machines. Tailscale's response confirms that sessions could exceed the configured local user's privileges, but frames the conditions and impact in its own security bulletins. Keep those attributions separate: the report describes the reproduced root impact; Tailscale confirms the permission-boundary failures and the release that fixes its confirmed findings. The two write-ups also use different language about whether this was a worm. Tailscale says the findings do not describe self-replicating malware. It calls the risk lateral movement limited to SSH connections already allowed by policy. The researcher says automated spread was possible in a lab across devices that the policy permitted, without passwords or user action. Those descriptions agree on the key limit: an attacker needs an initial foothold on an approved device, and policy controls which SSH paths are available. They differ on whether automated movement inside that permitted network should be called a worm. It is not an internet worm that scans and infects arbitrary machines. But policy-approved paths can still matter if one device is compromised. Tailscale also says three Serve and Funnel bugs were fixed in v1.104.4. It describes two other findings as expected or opt-in behavior. The company says Conn25 is still pre-production and that stable app connectors are not affected. That is why the report should not be summarized as one flaw that gives every internet user root on every tailnet server. Headscale is a separate question Headscale is a separate, self-hosted control server. Tailscale's v1.104.4 client release does not itself update a Headscale server. The report also tested Headscale v0.29.5 and lists a separate control-server memory-exhaustion finding. Separately, its status note says a Headscale-side fix is pending for a gliderssh session-pinning issue. Those are different findings. The report does not clearly state a fix status for the Headscale control-server issue. Headscale's v0.29.6 release notes list other security and maintenance changes, but do not mention the Tailworm findings. That does not prove the control-server issue is still present in every deployment. It does mean operators should check Headscale's current advisories and project updates rather than assume the Tailscale client fix covers it. What operators should do 1. Update Tailscale clients to v1.104.4 or later, especially on devices that accept Tailscale SSH connections. 2. Review SSH policy. Limit access to the users and devices that need it, and avoid broad rules that create more reachable paths than necessary. 3. Consider SSH check mode for sensitive machines, as Tailscale recommends. 4. If you operate Headscale, track its server-side updates separately. A Tailscale client update is not a Headscale server update. The headline is serious, but its boundaries matter. A compromised, policy-authorized device was part of the attack conditions. The practical response is to patch the clients, narrow SSH access, and treat self-hosted control servers as a separate product with a separate update path. Sources - Tailscale: SSH findings and fixes, October 28, 2026 - Tailworm security assessment and remediation status - Headscale v0.29.6 release notes

Tailworm報告（Tailscale/headscale 11件の指摘）に対応する管理者向け設定棚卸しと完了チェック（2026-10-26 10:23 JST時点） 前提と範囲 この記事は、Tailscaleやheadscaleを運用している管理者向けに、Tailwormの研究報告への対応で必要になる設定の棚卸しと、作業後の完了チェックをまとめたものです。 内容は、2026-10-26 10:23 JST時点で公開情報をWeb上で再確認した結果に基づいています。筆者は報告された内容を自分で再現・検証していません。各項目の確認状況は、「研究報告」「ベンダーの認識」「修正コード」「製品への配信」に分けて記載しています。 Tailwormは、Erica Windisch氏によるTailscale/headscaleの研究報告で、11件の指摘を含みます（Tailworm）。研究で対象になったheadscaleは0.29.5です。 前提として、次の点を押さえておいてください。 - 11件すべてが確定した脆弱性ではなく、11件のCVEが付けられたわけでもありません。 - 外部の誰でもすべての端末に侵入できると実証された内容ではありません。 - 主なSSH関連の問題は、許可済みの接続か、侵害済みの端末が起点です。自分の端末だけで構成したtailnetでも、1台が侵害されれば起点になり得ます。 - ベンダーはUnix権限と転送に関する問題を認識し、調査中としています。全員へのSSH無効化は推奨していません。不要な転送を止めるよう求める案内は確認済みです（r/Tailscaleのスレッド）。 - Tailscale SaaSそのものが侵害されたという報告とは別物です。 - 実際の被害の有無は、今回の調査では確認していません。 OSや導入方法（パッケージ、コンテナ、systemd、launchdなど）がわからない状態で一律のコマンドを示すと誤った操作につながるため、この記事では変更コマンドを示しません。棚卸しの観点と判断の基準を示します。 用語 - 組み込みのTailscale SSH：tailscaledがSSH接続を受け付ける機能です。端末側でRunSSHが有効な場合に動作します。 - 通常のOpenSSH over Tailscale：sshd（OpenSSH）をTailscaleの経路越しに使う方法です。SSH関連の主な指摘は組み込みのTailscale SSHを対象にしています。 - 転送（forwarding）：SSH接続を通して、別の通信を中継する機能です。 - Unix socket：同じマシンの中でプログラム同士がやり取りするための窓口です。 - LocalAPI：tailscaledの管理用socketです。 - DERP：端末同士が直接つながらないときに通信を中継するサーバーです。 - Tailnet Lock：新しい端末のnode keyに、信頼された鍵による署名があるかを検証する仕組みです。 - HTTP/2：1本の接続の中で、複数のやり取りを同時に進める通信方式です。 !SSHの接続許可と端末上の操作権限の違いを示す図 図1：SSH policyで接続を許可することと、接続後に端末上で行われる処理の権限は別の問題です。T3/T2系の指摘は、この2つのずれに関わります。この図は主にSSH関連の指摘を説明するもので、11項目すべてを同じように説明するものではありません。 棚卸しの観点 バージョン - 各端末のTailscaleクライアントのバージョンを把握します。確認時点の安定版は1.104.2です（リリース一覧）。 - headscaleのバージョンを把握します。0.29.6を、すべての指摘が修正された根拠とすることはできません。 RunSSH - 組み込みのTailscale SSHが有効になっている端末を洗い出します。 - 通常のOpenSSHだけを使っている端末とは分けて記録します。 SSH policy - tailnetのポリシーのSSHに関する設定で、誰が、どの端末に、どのユーザーとして接続できるかを確認します。 - 広すぎる許可（全員から全端末へ、など）や、使われていない許可がないかを確認します。 - check modeを使っているかを記録します。ただし、check modeは権限の問題を根本から解決するものではありません。 転送 - 業務でSSHの転送が必要な端末と、不要な端末を分けます。 - 不要な端末では、tailscaledサービスの実行環境にTS_SSH_DISABLE_FORWARDING=1を設定し、サービスを再起動する必要があります。シェルでexportするだけでは効きません。具体的な設定場所はOSや導入方法ごとに公式の案内を確認してください。 - 転送の停止は一部の緩和策にすぎません。 Serve - Serveの設定と転送先を一覧にします。転送先にLocalAPIや他の特権的なsocketが含まれていないかを確認します。 - 公開先ごとの権限設定と、権限情報のヘッダーを信頼するアプリがあるかを記録します。 - TS_SERVE_ALLOW_ALL_INTERFACESが設定されていないかを確認します。 Funnel - Funnelを使っている端末と公開先を一覧にします。 - テスト用の設定や不要な公開が残っていないかを確認します。 headscale - 登録窓口が公開されているか、リクエスト数の制限があるか、メモリの監視があるかを確認します。 DERP - 使っているDERPサーバーが、公式のものか独自運用のものかを記録します。 - 信頼できない中継サーバーが設定に含まれていないかを確認します。 11項目と対応 1. T3：一般ユーザーの転送がroot権限で行われる - 概要：一般ユーザーとしてログインしても、転送の処理がroot権限で行われ、Unix socketに接続できるおそれがあります。管理用サービスを操作される懸念があります。 - 成立条件：RunSSHが有効であること、SSH policyで接続が許可されている（または許可済みの端末が侵害されている）こと、転送が有効であることです。 - 確認状況：ラボでの研究報告、ベンダーの説明、修正案のいずれもが、問題がこの方向にあることを裏付けています。 - 対応：不要な転送を止め、SSH policyを必要最小限にします。 2. T2：逆向きの転送によるsocketのなりすまし - 概要：逆方向のsocket転送で既存のsocketを置き換え、本来の窓口になりすますおそれがあります。 - 成立条件：組み込みのTailscale SSHへの接続が許可されていて、逆向きの転送が使えることです。 - 確認状況：研究報告と修正案の内容は一致しています。ただし、どの環境でもroot権限を取れると保証されたわけではありません。 - 対応：転送を制限します。鍵の漏洩が疑われる場合は調査します。 3. T2/T3 RACE：確認と利用の間の競合状態 - 概要：パスの安全を確認してから実際に使うまでの間に、対象を差し替えられる問題です。 - 成立条件：SSH接続が許可されていて、転送が使えること、対象パスを書き換えられること、そして差し替えのタイミングを合わせられることです。 - 確認状況：ラボでは、管理サービスの操作、鍵の窃取、Tailnet Lockを使っていない環境での不正な端末登録が報告されています。Tailnet Lockが有効な環境で、この保護を実際に無効にできるかは実証されていません。PR21942は確認時点でOPENです。 - 対応：不要な転送を止めます。侵害が疑われる場合は、端末を隔離し、鍵を失効させ、不審な登録端末がないかを確認します。 !自分の端末の1台が侵害された場合に他の端末へ波及する条件を示す図 図2：1台が侵害され、その端末からのSSHがpolicyで許可されている場合に、他の端末へ影響が広がる条件を示しています。この図は主にSSH関連の指摘を説明するもので、11項目すべてを同じように説明するものではありません。 4. C1：実験的な機能conn25 - 概要：アプリ単位の許可を越えて、内部の宛先に接続できるおそれがあります。 - 成立条件：conn25を使っていること、そして一定の権限があることです。 - 確認状況：研究報告の段階です。宛先まで届くことと、侵入に成功することは別の話です。 - 対応：使っているかを棚卸しし、使う場合は送信先を制限します。 5. T1：大量の要求によるメモリの枯渇 - 概要：許可済みのSSH接続から大量の要求を送り、メモリを使い切らせてサービスを止める問題です。 - 成立条件：組み込みのTailscale SSHへの接続が許可されていることです。 - 確認状況：研究報告の段階です。 - 対応：SSH policyで利用者を制限し、メモリを監視します。転送を止めるだけでは解決しません。 6. C2/C4＋C3：headscaleとDERPの資源枯渇 - 概要：headscaleの登録キャッシュやDERPの資源を枯渇させるという複数の指摘です。 - 成立条件：認証済みの内部の利用者、認証前の公開登録窓口、悪意のある中継サーバーの応答など、指摘ごとに起点が異なります。 - 確認状況：研究報告の段階です。登録できなくなることと、不正に登録されることは別の話です。 - 対応：登録窓口のリクエスト数を制限し、メモリを監視し、DERPの設定を見直します。 7. SERVE-F-1：LocalAPIへのServe転送 - 概要：ServeのTCP転送先をLocalAPIにすると、管理操作が外から使える状態になります。 - 成立条件：その設定が行われていて、相手からの到達が許可されていることです。 - 確認状況：ラボでの研究報告の段階です。 - 対応：管理用socketへの転送設定を削除します。 8. SERVE-F-2：設定後のsocket差し替え - 概要：Serveを設定した後にsocketを差し替えて、検査をすり抜ける問題です。 - 成立条件：その端末で、該当する場所への書き込み権限が必要です。 - 確認状況：LocalAPIへの実際の操作は、Hostヘッダーの検査で403（拒否）になったと報告されています。他の特権的なsocketには懸念が残ります。完全に突破できたと実証されたわけではありません。 - 対応：socketと親ディレクトリの権限を制限します。 9. SERVE-F-3：Funnel許可判定のCLIとdaemonの不一致 - 概要：Funnelで公開してよいかの判定が、CLIとdaemonとで食い違う問題です。 - 成立条件：通常のheadscaleでは、必要なingress許可を発行できません。ラボでは特別なテスト設定で代用しています。 - 確認状況：本番環境で誰でも無断で公開できると実証されたわけではありません。 - 対応：不要な機能やテスト用の設定を除去し、アプリ側でも認証を設けます。 10. SERVE-F-4：TS_SERVE_ALLOW_ALL_INTERFACES - 概要：標準ではないこの環境変数を設定すると、設定やネットワークの条件によって公開範囲がLANまで広がる可能性があります。 - 成立条件：この環境変数が設定されていることです。 - 確認状況：コード確認に基づく設定上の注意点です。実際のLANでの検証は行われていません。 - 対応：不要であれば除去します。必要な場合は、firewallとアプリ側の認証で保護します。 11. SERVE-F-5：HTTP/2での公開先間の権限情報の混線 - 概要：HTTP/2で1本の接続を並行して使うと、同じpeerに認められたaccepted app capabilitiesが、複数の公開先の間で混ざるおそれがあります。他人のユーザーIDになりすますという話ではありません。 - 成立条件：公開先が複数あること、公開先ごとに権限設定が異なること、権限情報のヘッダーを信頼するアプリがあることなどです。 - 確認状況：PR21931が統合済みで、問題の方向は強く裏付けられています。ただし、安定版1.104.2に修正が含まれて配信されているかは別に確認が必要です。 - 対応：アプリ独自の認証を使い、公開先を絞り、修正版の配信を確認します。 !確認済みの事項と未確認の事項を区別する図 図3：研究報告、ベンダーの認識、修正コード（OPENか統合済みか）、製品への配信は、それぞれ別の段階です。この図は主にSSH関連の指摘を例にしたもので、11項目すべてを同じように説明するものではありません。 作業手順と完了チェック !今すぐ行う3つの確認を示す図 図4：組み込みのTailscale SSHを使っているか、SSH policyの範囲は適切か、転送は必要か。まずこの3点を確認します。この図は主にSSH関連の対応を示すもので、11項目すべての対応を網羅するものではありません。 変更前 - [ ] 組み込みのTailscale SSHが使えなくなっても作業できる、別の管理経路（コンソール、帯域外管理、通常のOpenSSHなど）を確保した - [ ] 上記の棚卸し結果（バージョン、RunSSH、SSH policy、転送、Serve、Funnel、headscale、DERP）を記録した - [ ] 変更対象の端末と、その切り戻し方法を決めた 変更後 - [ ] 必要な利用者がSSH接続できることを確認した - [ ] 不要な利用者や端末から接続できないことを確認した - [ ] 転送を止めた端末で、転送が実際に拒否されることを確認した（設定がtailscaledサービスの実行環境に反映され、再起動されていること） - [ ] tailscaledと、公開しているサービスが正常に動いていることを確認した - [ ] Serve/Funnelの不要な設定、管理用socketへの転送、TS_SERVE_ALLOW_ALL_INTERFACESが残っていないことを確認した - [ ] headscaleの登録窓口の制限とメモリ監視が有効であることを確認した 継続確認 - [ ] PR21942の状態と、PR21931の修正が安定版に含まれているかを追跡している - [ ] 公式の修正版が出たら適用し、全端末のバージョンを確認した - [ ] Tailscaleのセキュリティ情報ページを定期的に確認している check modeやTailnet Lockは有効な補助策ですが、権限の問題を根本から解決するものではありません。未確認の情報を「デマ」とも「安全」とも扱わず、証拠の段階を追い続けてください。 出典 - Tailworm：tailworm.com - r/Tailscaleのスレッド：reddit.com - tailscale PR21931：tailscale#21931 - tailscale PR21942：tailscale#21942 - Tailscale Security Bulletins：tailscale.com - Tailscaleのリリース：github.com/tailscale/tailscale/releases - headscale v0.29.6：github.com/juanfont/headscale/releases/tag/v0.29.6 この記事のもとになった整理（新しい事実の出典ではありません）：x.com

@paulmillr Or maybe juanfont/headscale

@tmuxvim You can self-host! juanfont/headscale

@graphtheory Totally understandable The core underlying tech (wireguard) is rock solid and totally OSS, and Headscale is the OSS version allowing you to self-host the relays. Tailscale employees even contribute to Headscale! juanfont/headscale

@rwojo @jgarzik Or: juanfont/headscale

Headscale: 85 title matches against 18 on 443 and 7 certificate hits Headscale: 85 title matches against 18 on 443 and 7 certificate hits Self-hosted control planes for mesh networking are a small population by design. Headscale is an open-source implementation of a coordination server for clients that would otherwise use a hosted service, and its numbers online are worth reading precisely because they are small. A tiny count is where measurement discipline earns its keep. The counts ZoomEye queries on 23 October 2026, sub_type=all, page size one: - title="Headscale": 85 - title="Headscale" && port="443": 18 - title="Headscale" && ssl="headscale": 7 These are the smallest figures in this series, and they do not imply the software is barely used. That conclusion would not follow from the data. Why the number is small for a good reason A coordination server is infrastructure for a private network. Its users are the devices enrolled in that network, and they reach it over the mesh, which means the server can sit behind the same overlay it coordinates or on a private address reachable only through an initial bootstrap path. Organisations that self-host such a service usually do so for exactly that reason: they want the control plane off the public internet. The architecture pushes toward the same outcome that security review would recommend. The second reason is presentation. A control plane is rarely intended for a browser, so the responses it produces are protocol messages, not HTML pages with titles. Where a UI exists, it may be a separate component or a plain API response. What a small count can still tell you Eighty-five assets present a title naming the product. Eighteen of those are on 443, and seven present a certificate that mentions the name. Each figure is a different kind of evidence, and their overlap is unknown. For an organisation running the service, the useful interpretation is narrower than the count: does anything on the public internet confirm that this infrastructure exists. A certificate naming the product, published by the same organisation, connects the identifier to a network block. That is the kind of link that a targeted attacker uses to decide where to spend effort. The security model of a coordination server The server distributes network configuration and node keys. It does not carry user traffic in normal operation; the peers connect directly or through relays. That separation is good design and it concentrates risk in one place. Compromise of the coordination server means control over the network map. An attacker who can register a node and obtain configuration can place themselves inside the mesh, subject to the policy the server distributes. The server therefore holds the authority that a VPN concentrator holds, without the data path that would otherwise be visible in traffic monitoring. The credentials are accordingly high value: the server's own database of nodes, any pre-authentication keys issued for enrolment, and the API tokens used to administer it. Practical checks - Confirm whether the coordination server needs a public listener at all. Many deployments require one for initial enrolment or for roaming clients, and that requirement is worth stating explicitly rather than inherited. - Restrict the enrolment path. A pre-authentication key is a durable credential; its lifetime and its distribution decide how much a leak matters. - Review certificates. A name that identifies the software is unnecessary for a private service and provides free confirmation to anyone who looks. - Separate administration from coordination. Where the server's API and its node-facing endpoints share a listener, a single network path exposes both. - Back up the node database. Rebuilding a mesh from lost state means re-enrolling every device, which is an operational event as much as a security one. Detection notes Node registration is the event with the most signal. Each registration has a key, a timestamp and a source address. A registration from an unfamiliar address, or one that uses a key that should have expired, is unambiguous. API access to the server forms the second record. Administrative calls are rare in a stable deployment, which makes any anomaly visible against a quiet baseline. Reading small numbers, again A count of seven certificates is not a finding; it is seven opportunities to confirm an organisation's infrastructure by inspection. The lesson generalises to every small, self-hosted control plane: the population is small, the individual exposure is concentrated, and the value of the measurement comes from interpreting each query as a separate instrument rather than averaging them into a single belief about how many systems exist. References - Headscale documentation: headscale.net - Headscale source repository: juanfont/headscale - ZoomEye queries executed 23 October 2026 with sub_type=all: title="Headscale" 85; title="Headscale" && port="443" 18; title="Headscale" && ssl="headscale" 7

Tailscale & Headscale Alternatives: Own Your Control Plane You liked the mesh model. You didn't like that someone else's server decided when your devices could talk to each other. So you went looking for a way to keep the first thing without the second, found Headscale — a community reimplementation of Tailscale's coordination server — and put it on a VM in your rack. Which solved the ownership problem and handed you a new one: you are now the maintainer of an unofficial clone of a proprietary control plane, and when it breaks at 11pm, the person on call is you. That's a real trade and plenty of people make it happily. But it's worth knowing it isn't the only way to get what you were after — so this post is about what a coordination server actually does, what it knows about your network, and the three honest options for who runs it. What is a coordination server? Mesh VPNs split the job in two, and the split is the whole story. The data plane is the encrypted traffic between your devices. In Tailscale's case, that's WireGuard, running peer-to-peer, and it genuinely does go directly between your machines when it can. Your file transfer from the NAS to your laptop isn't passing through anyone's data center. The control plane is everything that makes the data plane possible: distributing public keys, telling each device the current address of every other device, deciding which peers are allowed to see each other, handling NAT traversal negotiation, and issuing the ACLs that get enforced. That's the coordination server, and with a managed mesh, it's the vendor's. The distinction matters because "your traffic goes directly between your devices" is true and also not the reassurance it sounds like. The coordination server doesn't need to see your traffic to know a great deal about you. What it knows Run through what a coordination server has to know in order to do its job: - Your entire network topology. Every device you've enrolled, its name, its operating system, its keys. - Connection timing. Which devices came online, when, and from what IP address. That's a movement log for every laptop and phone you've enrolled. - Your access policy. The ACLs describing who may reach what — which is a fairly detailed description of what you consider sensitive. - The key material distribution. It's the thing handing out and rotating public keys. None of that is a vulnerability. It's inherent to the architecture — you cannot coordinate a mesh without knowing its shape. But it does mean the honest description of a managed mesh isn't "nobody can see my network." It's "a third party knows the shape of my network and when I use it, and I've decided that's fine." For a lot of homelabs, that genuinely is fine. It's a reasonable trade for something that works in four minutes with no port forwarding. And the relay question The other detail worth understanding: peer-to-peer doesn't always work. Roughly a fraction of connections can't establish a direct path — symmetric NAT on both ends, restrictive corporate firewalls, some mobile carriers, and carrier-grade NAT are all common culprits. When direct connection fails, mesh VPNs fall back to relaying traffic through vendor-operated relay servers. That traffic is still end-to-end encrypted; the relay can't read it. But it does mean that on connections where NAT traversal fails, your data transits infrastructure you don't own, and you generally don't get told which connections those are. Again: not a scandal, and the vendors document it. But if you self-host because "I don't want my traffic touching third-party infrastructure," this is the part of the architecture that doesn't fully deliver that, no matter how the marketing is worded. Why people go looking In our experience, the search for an alternative comes down to one of three motivations, and they want quite different things: Ownership. You want the control plane on your hardware. Not for a compliance reason — because it's yours and you'd like it to stay that way. Continuity. You don't want your access to your own house to depend on a company's uptime, funding, acquisition, or pricing decisions. "Is Tailscale down?" is a question a lot of people search for, and if the answer determines whether you can reach your own NAS, that's the dependency you're trying to remove. Auditability. You want a connection log that exists only on your infrastructure, and you'd like to be able to answer "who connected to what, when" from your own records. Notice that none of those are about speed or features. They're about who holds the keys. Option one: Managed mesh, and be at peace with it Tailscale, ZeroTier's hosted controller, Cloudflare's tunnels — these are good products, and the operational overhead is close to zero. No port forwarding, no dynamic DNS, no certificate management, works behind carrier-grade NAT without you thinking about it. If your honest answer to "do I want to maintain this?" is no, this is the right choice and there's no shame in it. A VPN you actually keep patched beats a self-hosted one you stopped updating in 2024. Choose this if: convenience is the priority, you're behind CGNAT, and a vendor knowing your topology doesn't bother you. Option two: Headscale Headscale is a community-built, open-source implementation of Tailscale's coordination server. You run it, it speaks the same protocol the official Tailscale clients expect, and your control plane is now a container on your own box. It genuinely does solve the ownership problem. It's also worth being clear-eyed about what you've signed up for: - It's a reimplementation of a proprietary API maintained by people other than the vendor. Feature parity is a moving target, and when the upstream protocol changes, Headscale follows rather than leads. - You are the support tier. There's a GitHub issue tracker and a helpful community, and that's the escalation path. - You still depend on the official clients, which are built by the company whose server you've chosen not to use. - Some features that exist in the managed product aren't available or work differently, and the list changes over releases. For someone who enjoys this — and lots of homelabbers genuinely do, that's the hobby — Headscale is a good time. For someone who wants control and not a new project, it's a heavier lift than it first appears. Choose this if: you want the mesh model specifically, you want to own the control plane, and maintaining infrastructure is a feature of your weekend rather than a cost. Option three: A self-hosted server with a company behind it The third option tends to get overlooked because it isn't mesh-shaped: run a supported VPN server on your own hardware. This is what OpenVPN Access Server is. You put it on a VM — a mini PC, a Proxmox guest, whatever's spare — and you own the server, the certificate authority, the keys, the logs, and the access policies. No coordination server exists, because the architecture doesn't have one: clients connect to your server directly, and your server is the only thing that knows your topology. Nobody at OpenVPN can see your network because no component runs on our infrastructure. You get the access controls the mesh vendors market as ZTNA — per-user and per-group policies, MFA enforcement, device posture, split tunneling, LDAP or RADIUS or SAML integration — with the policy engine inside your perimeter. And the free tier is genuinely free: two simultaneous connections, forever, all features, no credit card. For a homelab where you and one other device are connected at a time, that's often all you need. Past two, you pay per concurrent connection. Choose this if: you want ownership and a support contact, and you can live without the mesh topology. What you give up Self-hosting Access Server costs you things, and skipping past that would be doing you a disservice. You need a reachable address. A hub-and-spoke server has to accept inbound connections, which means a routable public IP and a forwarded port. If you're on Starlink or behind carrier-grade NAT, that's a hard blocker — mesh VPNs get around it precisely because their coordination server brokers the connection. We wrote about what to do in that situation, and the short version is that our cloud-delivered option needs no inbound port at all. You need dynamic DNS if your ISP hands out addresses by DHCP, which most residential connections do. You're on the hook for maintenance. Patching, certificate renewal, backups. Nobody else is doing it. Hub-and-spoke isn't mesh. Traffic between two remote clients goes via your server, so a big file transfer between two people outside your house is bounded by your home upload speed. Mesh handles that case better, and if that's your main workload, mesh is the right architecture. The comparison | |Managed mesh|Headscale|Self-hosted server| |:-|:-|:-|:-| |Who runs the control plane|Vendor|You|You| |Who runs the data plane|You, mostly — see relays below|You, mostly|You, entirely| |Who knows your topology|Vendor|You|You| |Traffic may relay via third party|Yes, on NAT-traversal failure|Yes, unless you also self-host relays|No| |Works behind CGNAT|Yes|Yes|No — needs a public IP| |Support when it breaks|Vendor|Community|Vendor| |Setup effort|Minutes|Moderate, plus ongoing|Moderate, plus ongoing| |Free tier|Yes, vendor-defined|Free, self-hosted|2 connections, forever|   The actual recommendation If you're on Headscale and enjoying it, stay. It does what you wanted. If you're on Headscale because it was the only way you could own the control plane, and the maintenance has stopped being fun, a self-hosted server with a company behind it gives you that ownership with someone to call. It also closes the relay gap: Headscale gives you the control plane, but traffic still falls back to relays unless you're running those yourself too. A hub-and-spoke server has no relays to fall back to, because there's nothing to coordinate. Try the free tier before committing; it costs nothing, and two connections are a real deployment, not a demo. And if you're still on a managed mesh and this post hasn't bothered you at all, that's a perfectly good outcome too. Knowing what you're choosing is the point. Choosing convenience on purpose is very different from not realizing there was a choice. Frequently asked questions Can Tailscale see my traffic? Not the contents. Tailscale's data plane is WireGuard running peer-to-peer, encrypted end-to-end, and direct connections don't pass through Tailscale's infrastructure. Their coordination server does hold metadata: your device list, device names and operating systems, public keys, connection times, source IP addresses, and your access-control policy. And when a direct peer-to-peer path can't be established, traffic falls back to relaying through Tailscale-operated relay servers — still encrypted, but transiting their infrastructure. Is Tailscale open source? Partly. The client software is open source. The coordination server that runs the control plane is not, which is precisely why Headscale exists — it's a community-built open-source implementation of that server so people can self-host it. Is Tailscale free? There's a free personal tier with limits on users and devices. Those limits have changed several times, so check their current pricing page rather than trusting any blog post's numbers, including ours. Is Tailscale safe? Yes, in the sense that matters most: the cryptography is WireGuard's and it's sound, and the company has a good security track record. The questions raised in this post aren't about whether the encryption holds — it does. They're about who holds the metadata and who your access depends on. Is Tailscale down? This gets searched a lot, which is itself the interesting part. Any managed mesh puts your ability to reach your own devices behind a vendor's uptime, because new connections need the coordination server. Existing sessions typically survive an outage, but establishing new ones generally doesn't. A self-hosted server with no external control plane removes that dependency entirely — your access is only as available as your own hardware. What is Headscale, and how is it different from Tailscale? Headscale is an open-source, community-maintained implementation of Tailscale's coordination server, letting you self-host the control plane while still using the official Tailscale clients. Functionally, you get most of the mesh behavior with the control plane on your hardware. The differences that matter: it's not built or supported by Tailscale, feature parity with the managed product lags and shifts between releases, and support is a community issue tracker rather than a vendor. What are the downsides of Tailscale? The main architectural ones: a third party holds your network metadata and access policy, new connections depend on their control plane being reachable, and traffic relays through their servers when direct connection fails. Commercially, free-tier limits can change. None of these are defects — they're the cost of the convenience, and for many homelabs it's worth paying. Do I need a public IP to self-host a VPN server? For a hub-and-spoke server like Access Server, yes — it accepts inbound connections, so it needs a routable address and a forwarded port. If you're behind carrier-grade NAT or on Starlink, that won't work, and a cloud-delivered option that requires no inbound port is the better fit.

Tailscale Selfhosted in now Here! Why Headscale Easy? insanerask77/headscale-easy Headscale works well on its own, and Headscale Easy runs the official, unmodified Headscale binary — it is not a fork or a replacement. What takes time is the glue around it when you want a complete self-hosted setup for several people: >auth + DNS + HTTPS + device management + backups = a weekend project Headscale Easy packages that glue, in the spirit of wg-easy for WireGuard: - One container — Headscale, HTTPS and the console in a single image, set up from your browser; pull the new image to update. - A web console for everyday tasks, modelled on Tailscale's admin panel, where members manage only their own devices. - Centralised configuration — a few variables or the wizard, one domain. - Auth, DNS, HTTPS and backups set up with secure defaults. - Everything self-hosted — use the official Tailscale apps on every device; only the server is yours. If you are happy running Headscale by hand, you do not need this project. More in Why Headscale Easy?, including the end-to-end workflow. Headscale Easy and Headplane insanerask77/headscale-easy Headplane is an established, feature-complete web UI for an existing Headscale — a good choice if you already run Headscale. Headscale Easy installs and wires the whole stack (Headscale, HTTPS, local accounts with 2FA and invitations, backups) and includes its own console. See the detailed comparison. ✨ Features insanerask77/headscale-easy - 🖥️ Tailscale-style web console at /admin: machines, users, DNS, access controls, keys. Dark and light themes, works on phones. - 👤 Real user accounts built in: passwords, optional two-factor (TOTP), invitations, password-reset links and sign-up — or plug in your own OIDC provider (Authentik, Keycloak, Pocket ID, Google…). - 🔒 Every user gets their own private VPN: members only see and reach their own devices (ACL autogroup:self); admins manage everything. - 📱 Machines: status, addresses, OS and client version with update hints, rename, expire, remove, key expiry, tags, subnet routes and exit nodes, filters, search and CSV export. - 🐳 Docker tab in Add device: generates the docker run and docker-compose.yml for a Tailscale container (exit node, subnet routes, userspace mode, a pinned Tailscale version), keeps the auth key in a separate .env, gives the command to apply a changed option to a running container, and has a troubleshooting dropdown with eleven common problems. - ✅ Routes waiting for approval are flagged in the machine's badge, can be approved in one click, and administrators see a banner counting them. - 🔑 Auth keys (one-off, reusable, ephemeral) and API keys; register devices by auth ID. - 🌐 DNS: MagicDNS, tailnet domain, nameservers, split DNS, search domains — validated with headscale configtest and rolled back if Headscale refuses them. - 📝 Access controls: visual editor for rules, groups and tag owners, a test-access simulator ("can ana reach nas:445?"), and the raw HuJSON editor as a full fallback. - 🔐 HTTPS your way: Let's Encrypt, self-signed, behind your existing proxy (Nginx Proxy Manager, nginx, Traefik, Caddy — ready-made snippets), or plain HTTP on a LAN. - 🌍 English, Spanish, French, German and Portuguese in the console (more welcome!). - 💾 Daily backups of everything (database, keys, accounts, configuration) and a one-command restore, also on a new server. - 🪶 Lightweight: one container, about 70 MB of RAM; the console is plain Python standard library, no build step, no JavaScript framework.