Tailnet Lock Feature request #462

New Issue

adam · 2025-12-29T01:29:42+01:00

adam commented

2025-12-29 01:29:42 +01:00

Originally created by @lyc8503 on GitHub (Apr 2, 2023).

Feature request

The official Tailscale server introduced https://tailscale.com/blog/tailnet-lock/ feature.
I think implementing this feature could protect my private tailnet from being accessed even if the hosting server was compromised or there were undiscovered vulnerabilities in my setup. The feature can further improve the security and privacy of our tailnets through cryptographic means.

Originally created by @lyc8503 on GitHub (Apr 2, 2023).  **Feature request** The official Tailscale server introduced https://tailscale.com/blog/tailnet-lock/ feature. I think implementing this feature could protect my private tailnet from being accessed even if the hosting server was compromised or there were undiscovered vulnerabilities in my setup. The feature can further improve the security and privacy of our tailnets through cryptographic means.

adam added the enhancement no-stale-bot labels 2025-12-29 01:29:42 +01:00

adam commented

2025-12-29 01:29:43 +01:00

@loprima-l commented on GitHub (Apr 28, 2023):

Hi, I think that's not the priority now, plus adding this type of key is useful if you can't trust the server, but you can't trust the client, as you are using your own Headscale instance, if your server is compromised probably your clients are compromised too, because if you secure your network well the risk is almost none.

@loprima-l commented on GitHub (Apr 28, 2023): Hi, I think that's not the priority now, plus adding this type of key is useful if you can't trust the server, but you can't trust the client, as you are using your own Headscale instance, if your server is compromised probably your clients are compromised too, because if you secure your network well the risk is almost none.

adam commented

2025-12-29 01:29:43 +01:00

@codethief commented on GitHub (May 7, 2023):

@loprima-l I'm afraid I can't follow you. Would you mind rephrasing your comment?

Back to the topic at hand: I agree with @lyc8503, Tailscale Lock would be great. Otherwise, IIUC if the Headscale server gets compromised, the entire Tailnet will be, too. (Unless, of course, you've deployed further authentication measures beyond Tailscale.)

@codethief commented on GitHub (May 7, 2023): @loprima-l I'm afraid I can't follow you. Would you mind rephrasing your comment? Back to the topic at hand: I agree with @lyc8503, Tailscale Lock would be great. Otherwise, IIUC if the Headscale server gets compromised, the entire Tailnet will be, too. (Unless, of course, you've deployed further authentication measures beyond Tailscale.)

adam commented

2025-12-29 01:29:44 +01:00

@loprima-l commented on GitHub (May 7, 2023):

My point is : Yes it'll be an enhancement. But Headscale is not actually suitable for a sensitive environnement, and even if the point is to avoid security issues, securing more the product is not the current step. We can't take tail scale as an example, they introduced it only recently.

Maybe this would be a nice feature when Headscale is stabilized as for now the performances don't made it suitable for a large/sensitive environment. Headscale is fun to experiment or if you don't actually have the choice, your network shouldn't be exposed only by connecting to your instance, it's always necessary to have a secure infrastructure at all the levels.

@loprima-l commented on GitHub (May 7, 2023): My point is : Yes it'll be an enhancement. But Headscale is not actually suitable for a sensitive environnement, and even if the point is to avoid security issues, securing more the product is not the current step. We can't take tail scale as an example, they introduced it only recently. Maybe this would be a nice feature when Headscale is stabilized as for now the performances don't made it suitable for a large/sensitive environment. Headscale is fun to experiment or if you don't actually have the choice, your network shouldn't be exposed only by connecting to your instance, it's always necessary to have a secure infrastructure at all the levels.

adam commented

2025-12-29 01:29:44 +01:00

@juanfont commented on GitHub (May 8, 2023):

I might do this at a later stage, as I am very curious about the implementation of Tailnet Lock. Because of this curiosity-driven development, for the time being I won't be accepting contributions on it.

Please consider Tailscale's SaaS if your use-case really requires this kind of security feature.

@juanfont commented on GitHub (May 8, 2023): I might do this at a later stage, as I am very curious about the implementation of Tailnet Lock. Because of this curiosity-driven development, for the time being I won't be accepting contributions on it. Please consider Tailscale's SaaS if your use-case really requires this kind of security feature.

adam commented

2025-12-29 01:29:44 +01:00

@nokados commented on GitHub (Oct 5, 2024):

@juanfont So, a year and a half later, are there any plans to implement this critical feature in the near future?

And it is really important, because in a private network, where all devices do not have a public IP and access from the outside, the coordinating server is the most vulnerable part. Moreover, many people have it located in a VPS (https://github.com/juanfont/headscale/issues/1072 ) that have root access to all their virtual machines. Without the ability to sign nodes, the network is completely open to the VPS provider and all his "friends", not to mention the possible hacking of the server itself through any vulnerabilities.

If you are still not ready to implement it yourself, maybe you will give it to contributors?

@nokados commented on GitHub (Oct 5, 2024): @juanfont So, a year and a half later, are there any plans to implement this critical feature in the near future? And it is really important, because in a private network, where all devices do not have a public IP and access from the outside, the coordinating server is the most vulnerable part. Moreover, many people have it located in a VPS (https://github.com/juanfont/headscale/issues/1072 ) that have root access to all their virtual machines. Without the ability to sign nodes, the network is completely open to the VPS provider and all his "friends", not to mention the possible hacking of the server itself through any vulnerabilities. If you are still not ready to implement it yourself, maybe you will give it to contributors?

adam commented

2025-12-29 01:29:45 +01:00

@juanfont commented on GitHub (Oct 10, 2024):

@nokados I have to admit that some of my (happy) life events prevent me from spending time on this.

If anyone is interested, please proceed with a design doc proposal + subsequent implementation? 😄

@juanfont commented on GitHub (Oct 10, 2024): @nokados I have to admit that some of my (happy) life events prevent me from spending time on this. If anyone is interested, please proceed with a design doc proposal + subsequent implementation? 😄

adam commented

2025-12-29 01:29:45 +01:00

@cchance27 commented on GitHub (Dec 2, 2024):

Glad to hear your having good life events, hopefully someone can take this up as its a huge missing feature currently for headscale

@cchance27 commented on GitHub (Dec 2, 2024): Glad to hear your having good life events, hopefully someone can take this up as its a huge missing feature currently for headscale

adam commented

2025-12-29 01:29:45 +01:00

@kradalby commented on GitHub (Dec 2, 2024):

A response to:

a huge missing feature currently for headscale

and

are there any plans to implement this critical feature in the near future?

I think this is a bit exaggerated, Tailnet Lock is a featured designed by Tailscale to be able to not trust that the managed service as they do not allow you to self-host.

Since Headscale is a self-hosted service which you deploy on your own infra, the whole idea is that you use it because you trust yourself.

The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution.

Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails.

My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle before needing this feature.

@kradalby commented on GitHub (Dec 2, 2024): A response to: > a **huge** missing feature currently for headscale and > are there any plans to implement this **critical** feature in the near future? I think this is a bit exaggerated, Tailnet Lock is a featured designed by Tailscale to be able to not trust that the managed service as they do not allow you to self-host. Since Headscale is a self-hosted service which you deploy on your own infra, the whole idea is that you use it because you trust yourself. The complexity of the feature and more importantly the risk and impact of it being implemented _wrongly_ means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution. Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails. My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle before needing this feature.

adam commented

2025-12-29 01:29:45 +01:00

@lyc8503 commented on GitHub (Dec 2, 2024):

if you do not trust your own infra, then that seem like a problem to tackle before needing this feature

I use Google Cloud Platform myself and I trust their VPS, the probability of an infra being compromised is really low when configured correctly. But as someone mentioned above, it is possible that some people are using VPS products from unknown/suspicious vendors for hosting tailnet for budgetary reasons. (For the price of a one-month VPS at GCP you can buy a one-year VPS with the same performance at these vendors.) If we can put all the trusts on the client, we can confidently deploy Headscale anywhere, without having to constantly worry about “will my hosting provider access / hack into my private network”.

The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me.

I agree with you, it's annoying to have to rebuild the whole tailnet if I get locked out due to a configuration/implementation error. Perhaps the risks of doing this could be stated in the documentation, or label it as a BETA feature at first.

@lyc8503 commented on GitHub (Dec 2, 2024): > if you do not trust your own infra, then that seem like a problem to tackle before needing this feature I use Google Cloud Platform myself and I trust their VPS, the probability of an infra being compromised is really low when configured correctly. But as someone mentioned above, it is possible that some people are using VPS products from unknown/suspicious vendors for hosting tailnet for budgetary reasons. (For the price of a one-month VPS at GCP you can buy a one-year VPS with the same performance at these vendors.) If we can put all the trusts on the client, we can confidently deploy Headscale anywhere, without having to constantly worry about “will my hosting provider access / hack into my private network”. > The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me. I agree with you, it's annoying to have to rebuild the whole tailnet if I get locked out due to a configuration/implementation error. Perhaps the risks of doing this could be stated in the documentation, or label it as a BETA feature at first.

adam commented

2025-12-29 01:29:46 +01:00

@codethief commented on GitHub (Dec 2, 2024):

My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle before needing this feature.

(emphasis mine)

The whole point is that Tailnet Lock would allow one to tackle the problem of not trusting one's own infra. :)

Either way, I think the Lock feature would be very valuable since the security implications of an attacker taking over the Headscale server could be quite severe from what I've been able to tell? (Related: https://github.com/juanfont/headscale/issues/1432)

@codethief commented on GitHub (Dec 2, 2024): > My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle **before needing** this feature. (emphasis mine) The whole point is that Tailnet Lock would allow one to tackle the problem of not trusting one's own infra. :) Either way, I think the Lock feature would be very valuable since the security implications of an attacker taking over the Headscale server could be quite severe from what I've been able to tell? (Related: https://github.com/juanfont/headscale/issues/1432)

adam commented

2025-12-29 01:29:46 +01:00

@echobom commented on GitHub (Mar 7, 2025):

This is a very important security feature. I hope some contributors can support this feature. I appreciate it very much.

@echobom commented on GitHub (Mar 7, 2025): This is a very important security feature. I hope some contributors can support this feature. I appreciate it very much.

adam commented

2025-12-29 01:29:46 +01:00

@lynatic1337 commented on GitHub (Apr 8, 2025):

The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution.

Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails.

From what I've figured while reading through the whitepaper the entire point of Tailnet lock seems to be that this is mainly a thing bootstrapped and enforced by the nodes while the control planes only role is distributing updates signed by the nodes, the verification magic has to happen at the client level.
Tailnet lock builds on AUMs (Authority update messages). These are in essence comparable to signed git commits that contain info which public keys are allowed to be in the Tailnet and which TLKs (tailnet lock key, each node has their own for signing AUMs) are allowed to author/sign "commits". A AUM will only be accepted by a node if it is signed by a TLK that the was listed as a trusted key in the previous AUM.

Basically it looks like we just have to make the control plane be able to distribute AUMs, everything cryptographically more complicated that happens with those AUMs should be handled by the nodes/clients (for which Tailscale Inc. already does provide secure implementations).

Say if someone wanted to reverse engineer how the AUM distribution works and hack that into headscale for testing purposes, what would be the most efficient way to reverse engineer Tailscale for that? MITMing network traffic?

@lynatic1337 commented on GitHub (Apr 8, 2025): > The complexity of the feature and more importantly the risk and impact of it being implemented _wrongly_ means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution. > > Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails. From what I've figured while reading through the whitepaper the entire point of Tailnet lock seems to be that this is mainly a thing bootstrapped and enforced by the nodes while the control planes only role is distributing updates signed by the nodes, the verification magic has to happen at the client level. Tailnet lock builds on AUMs (Authority update messages). These are in essence comparable to signed git commits that contain info which public keys are allowed to be in the Tailnet and which TLKs (tailnet lock key, each node has their own for signing AUMs) are allowed to author/sign "commits". A AUM will only be accepted by a node if it is signed by a TLK that the was listed as a trusted key in the previous AUM. Basically it looks like we just have to make the control plane be able to distribute AUMs, everything cryptographically more complicated that happens with those AUMs should be handled by the nodes/clients (for which Tailscale Inc. already does provide secure implementations). Say if someone wanted to reverse engineer how the AUM distribution works and hack that into headscale for testing purposes, what would be the most efficient way to reverse engineer Tailscale for that? MITMing network traffic?

adam commented

2025-12-29 01:29:46 +01:00

@unusualevent commented on GitHub (Sep 13, 2025):

I can see about building this. I'll need some guinea pigs to try out the feature on windows and iOS though.

@unusualevent commented on GitHub (Sep 13, 2025): I can see about building this. I'll need some guinea pigs to try out the feature on windows and iOS though.

adam commented

2025-12-29 01:29:47 +01:00

@zaid-marji commented on GitHub (Sep 24, 2025):

The point of self-hosting is indeed that you trust your own infrastructure more than other service providers. Moreover, the point of using VPNs or VPN-like products is to keep your infrastructure behind firewalls.

Headscale by necessity needs to be publicly exposed, and so, by necessity it is much more exposed and vulnerable than other services. Therefore, whether Headscale is hosted in a DMZ inside your infrastructure or a VPS (which is a respectable place to host such a service), Tailnet Lock is useful and arguably necessary feature. Many ISPs also use CGNAT which is another use-case that Tailscale/Headscale is designed to help with, which makes the use of VPS a requirement (or pay extra for a dedicated IP).

Either way, there are legitimate reasons why people may need the additional security that Tailnet lock provides, either because they host the Headscale server outside of their infrastructure, or in an inherently less secure DMZ.

@zaid-marji commented on GitHub (Sep 24, 2025): The point of self-hosting is indeed that you trust your own infrastructure more than other service providers. Moreover, the point of using VPNs or VPN-like products is to keep your infrastructure behind firewalls. Headscale by necessity needs to be publicly exposed, and so, by necessity it is much more exposed and vulnerable than other services. Therefore, whether Headscale is hosted in a DMZ inside your infrastructure or a VPS (which is a respectable place to host such a service), Tailnet Lock is useful and arguably necessary feature. Many ISPs also use CGNAT which is another use-case that Tailscale/Headscale is designed to help with, which makes the use of VPS a requirement (or pay extra for a dedicated IP). Either way, there are legitimate reasons why people may need the additional security that Tailnet lock provides, either because they host the Headscale server outside of their infrastructure, or in an inherently less secure DMZ.

adam commented

2025-12-29 01:29:47 +01:00

@warnspread commented on GitHub (Nov 21, 2025):

Just to step in here: I would love to use Headscale over Tailscale, but since tailnet lock is not available i will not use it. Sadly, since its free, this is not an agument for the developers to implement it, but just to show how important the feature is for some people.

I want to trust the devices in my home not the device in someones datacenter.

@warnspread commented on GitHub (Nov 21, 2025): Just to step in here: I would love to use Headscale over Tailscale, but since tailnet lock is not available i will not use it. Sadly, since its free, this is not an agument for the developers to implement it, but just to show how important the feature is for some people. I want to trust the devices in my home not the device in someones datacenter.

adam commented

2025-12-29 01:29:48 +01:00

@CloudmarkGIT commented on GitHub (Dec 21, 2025):

Hello everyone,

It has been over two years since this feature request was opened, but the value of a Zero Trust control plane remains high.

I would like to request a re-evaluation of this feature's feasibility. To facilitate this, I have prepared a technical specification for a "lightweight" implementation. The proposed architecture minimizes server-side complexity by adopting an "Agnostic Storage" approach - delegating validation logic to the clients and treating Headscale primarily as a reliable transport for TKA messages.

Please find the design document attached for a quick assessment of the implementation complexity: Headscale-Tailnet-Lock-Design_Implementation.pdf

Thank you for your time and for all the hard work on Headscale!

@CloudmarkGIT commented on GitHub (Dec 21, 2025): Hello everyone, It has been over two years since this feature request was opened, but the value of a Zero Trust control plane remains high. I would like to request a re-evaluation of this feature's feasibility. To facilitate this, I have prepared a technical specification for a "lightweight" implementation. The proposed architecture minimizes server-side complexity by adopting an "Agnostic Storage" approach - delegating validation logic to the clients and treating Headscale primarily as a reliable transport for TKA messages. Please find the design document attached for a quick assessment of the implementation complexity: [Headscale-Tailnet-Lock-Design_Implementation.pdf](https://github.com/user-attachments/files/24280216/Headscale-Tailnet-Lock-Design_Implementation.pdf) Thank you for your time and for all the hard work on Headscale!

Sign in to join this conversation.

Branches Tags

main

update_flake_lock_action

gh-pages

kradalby/release-v0.27.2

dependabot/go_modules/golang.org/x/crypto-0.45.0

dependabot/go_modules/github.com/opencontainers/runc-1.3.3

copilot/investigate-headscale-issue-2788

copilot/investigate-visibility-issue-2788

copilot/investigate-issue-2833

copilot/debug-issue-2846

copilot/fix-issue-2847

dependabot/go_modules/github.com/go-viper/mapstructure/v2-2.4.0

dependabot/go_modules/github.com/docker/docker-28.3.3incompatible

kradalby/cli-experiement3

doc/0.26.1

doc/0.25.1

doc/0.25.0

doc/0.24.3

doc/0.24.2

doc/0.24.1

doc/0.24.0

kradalby/build-docker-on-pr

topic/docu-versioning

topic/docker-kos

juanfont/fix-crash-node-id

juanfont/better-disclaimer

update-contributors

topic/prettier

revert-1893-add-test-stage-to-docs

add-test-stage-to-docs

remove-node-check-interval

fix-empty-prefix

fix-ephemeral-reusable

bug_report-debuginfo

autogroups

logs-to-stderr

revert-1414-topic/fix_unix_socket

rename-machine-node

port-embedded-derp-tests-v2

port-derp-tests

duplicate-word-linter

update-tailscale-1.36

warn-against-apache

ko-fi-link

more-acl-tests

fix-typo-standalone

parallel-nolint

tparallel-fix

rerouting

ssh-changelog-docs

oidc-cleanup

web-auth-flow-tests

kradalby-gh-runner

fix-proto-lint

remove-funding-links

go-1.19

enable-1.30-in-tests

0.16.x

cosmetic-changes-integration

tmp-fix-integration-docker

fix-integration-docker

configurable-update-interval

show-nodes-online

hs2021

acl-syntax-fixes

ts2021-implementation

fix-spurious-updates

unstable-integration-tests

mandatory-stun

embedded-derp

prtemplate-fix

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/headscale#462