starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] Clients still contact log.tailscale.com when connected to headscale unless TS_NO_LOGS_NO_SUPPORT=true #1110

New Issue
Closed
opened 2025-12-29 02:28:19 +01:00 by adam · 8 comments
adam commented 2025-12-29 02:28:19 +01:00
Owner
Copy Link

Originally created by @word5355 on GitHub (Oct 13, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When headscale is configured with logtail disabled in config.yaml, Tailscale clients still attempt to contact log.tailscale.com (DNS and HTTP).
Clients only stop contacting log.tailscale.com and log the message You have disabled logging. Tailscale will not be able to provide support. when TS_NO_LOGS_NO_SUPPORT=true is set.

  • tcpdump excerpt showing DNS queries and TCP connection attempts
    Tailscale client is making DNS queries for log.tailscale.com and then attempting an HTTPS connection to the resolved IP (ec2-54-161-152-147.compute-1.amazonaws.com / 54.161.152.147).
$ sudo tcpdump -i eth0
00:49:05.493952 IP app-tailscale.42496 > 10.0.0.1.domain: 53657+ [1au] AAAA? log.tailscale.com. (46)
00:49:05.494001 IP app-tailscale.44366 > 10.0.0.1.domain: 58553+ [1au] A? log.tailscale.com. (46)
...
00:49:05.607264 IP 10.0.0.1.domain > app-tailscale.42496: 53657 1/0/1 AAAA 2600:1f18:429f:9305:590c:496f:7805:d86f (74)
00:49:05.607264 IP 10.0.0.1.domain > app-tailscale.44366: 58553 1/0/1 A 54.161.152.147 (62)
...
00:49:05.608147 IP app-tailscale.47306 > ec2-54-161-152-147.compute-1.amazonaws.com.https: Flags [S], seq 992247001, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
...

Expected Behavior

Clients connected to a headscale server with logtail disabled should not attempt to contact log.tailscale.com.

Steps To Reproduce

  1. Disable logtail in headscale's config.yaml.
  2. Start headscale.
  3. Connect a Tailscale client to headscale.
  4. Check DNS/HTTP requests from the client to log.tailscale.com.
  5. Set TS_NO_LOGS_NO_SUPPORT=true on the client and restart the client.
  6. Check the client logs show You have disabled logging. Tailscale will not be able to provide support. and requests to log.tailscale.com stop.

Environment

- OS: Debian 12
- Headscale version: 0.26.1
- Tailscale version: 1.35.181
- OS running Tailscale: Debian 12

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

Happy to provide logs or captures if needed.

Note:
This issue appears related to #835 but is not identical: it focuses only on DNS queries to log.tailscale.com.
This issue covers the broader behavior where the client attempts to contact log.tailscale.com (not just DNS) and only respects TS_NO_LOGS_NO_SUPPORT when it is explicitly set to true. For this reason I'm opening a separate issue.

Originally created by @word5355 on GitHub (Oct 13, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior When headscale is configured with logtail disabled in config.yaml, Tailscale clients still attempt to contact log.tailscale.com (DNS and HTTP). Clients only stop contacting log.tailscale.com and log the message `You have disabled logging. Tailscale will not be able to provide support.` when `TS_NO_LOGS_NO_SUPPORT=true` is set. - tcpdump excerpt showing DNS queries and TCP connection attempts Tailscale client is making DNS queries for log.tailscale.com and then attempting an HTTPS connection to the resolved IP (ec2-54-161-152-147.compute-1.amazonaws.com / 54.161.152.147). ```v $ sudo tcpdump -i eth0 00:49:05.493952 IP app-tailscale.42496 > 10.0.0.1.domain: 53657+ [1au] AAAA? log.tailscale.com. (46) 00:49:05.494001 IP app-tailscale.44366 > 10.0.0.1.domain: 58553+ [1au] A? log.tailscale.com. (46) ... 00:49:05.607264 IP 10.0.0.1.domain > app-tailscale.42496: 53657 1/0/1 AAAA 2600:1f18:429f:9305:590c:496f:7805:d86f (74) 00:49:05.607264 IP 10.0.0.1.domain > app-tailscale.44366: 58553 1/0/1 A 54.161.152.147 (62) ... 00:49:05.608147 IP app-tailscale.47306 > ec2-54-161-152-147.compute-1.amazonaws.com.https: Flags [S], seq 992247001, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 ... ``` ### Expected Behavior Clients connected to a headscale server with logtail disabled should not attempt to contact log.tailscale.com. ### Steps To Reproduce 1. Disable logtail in headscale's config.yaml. 2. Start headscale. 3. Connect a Tailscale client to headscale. 4. Check DNS/HTTP requests from the client to log.tailscale.com. 5. Set `TS_NO_LOGS_NO_SUPPORT=true` on the client and restart the client. 6. Check the client logs show `You have disabled logging. Tailscale will not be able to provide support.` and requests to log.tailscale.com stop. ### Environment ```markdown - OS: Debian 12 - Headscale version: 0.26.1 - Tailscale version: 1.35.181 - OS running Tailscale: Debian 12 ``` ### Runtime environment - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ### Debug information Happy to provide logs or captures if needed. Note: This issue appears related to #835 but is not identical: it focuses only on DNS queries to log.tailscale.com. This issue covers the broader behavior where the client attempts to contact log.tailscale.com (not just DNS) and only respects TS_NO_LOGS_NO_SUPPORT when it is explicitly set to true. For this reason I'm opening a separate issue.
adam added the bug label 2025-12-29 02:28:19 +01:00
adam closed this issue 2025-12-29 02:28:19 +01:00
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 15, 2025):

I think there is a misunderstanding that TS_NO_LOGS_NO_SUPPORT and the logtail.enabled option does the same. By this I mean both from our side, and the users (as we have written the wrong documentation in the config example).

As we cant really do anything about this, I propose we document that the option to disable telemetry is TS_NO_LOGS_NO_SUPPORT and that the internal flag is not completely covering.

logtail.enabled is also problematic for users using both headscale and tailscale with user switching, if the tailscale network requires logging, it will prevent the user from switching between the headscale and tailscale network.

wdyt @nblock?

@kradalby commented on GitHub (Oct 15, 2025): I think there is a misunderstanding that `TS_NO_LOGS_NO_SUPPORT` and the `logtail.enabled` option does the same. By this I mean both from our side, and the users (as we have written the wrong documentation in the config example). As we cant really do anything about this, I propose we document that the option to disable telemetry is `TS_NO_LOGS_NO_SUPPORT` and that the internal flag is not completely covering. `logtail.enabled` is also problematic for users using _both_ headscale and tailscale with user switching, if the tailscale network requires logging, it will prevent the user from switching between the headscale and tailscale network. wdyt @nblock?
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@word5355 commented on GitHub (Oct 15, 2025):

Thanks for the comment.
I'm not sure exactly, but from their statement, my understanding was that the option can disable logging and analytics (including on mobile apps)...
https://github.com/tailscale/tailscale/issues/7281#issuecomment-1430437613
https://github.com/tailscale/tailscale/pull/4437#issue-1207435654

@word5355 commented on GitHub (Oct 15, 2025): Thanks for the comment. I'm not sure exactly, but from their statement, my understanding was that the option can disable logging and analytics (including on mobile apps)... https://github.com/tailscale/tailscale/issues/7281#issuecomment-1430437613 https://github.com/tailscale/tailscale/pull/4437#issue-1207435654
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 15, 2025):

I think the challenge is how early it can do it, when the client starts, it might not know that setting, while if you pass the env var, its there from the beginning. The recommendation should be to use TS_NO_LOGS_NO_SUPPORT if they are concerned about this.

@kradalby commented on GitHub (Oct 15, 2025): I think the challenge is how early it can do it, when the client starts, it might not know that setting, while if you pass the env var, its there from the beginning. The recommendation should be to use `TS_NO_LOGS_NO_SUPPORT` if they are concerned about this.
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@word5355 commented on GitHub (Oct 16, 2025):

I see.
Could this be considered a bug in the Tailscale client?
If the logtail.enabled option does not disable logging, this contradicts their statement that logs can be disabled by disabling logtail in Headscale.
https://github.com/tailscale/tailscale/issues/7281#issuecomment-1430437613
Or maybe I just misunderstand their statement.

@word5355 commented on GitHub (Oct 16, 2025): I see. Could this be considered a bug in the Tailscale client? If the `logtail.enabled` option does not disable logging, this contradicts their statement that logs can be disabled by disabling logtail in Headscale. https://github.com/tailscale/tailscale/issues/7281#issuecomment-1430437613 Or maybe I just misunderstand their statement.
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 16, 2025):

(including on mobile apps)...

I think the way you would do this on mobile applications would be via MDM configuration, that is likely the way to set such options early enough to stop things from being configured.

Could this be considered a bug in the Tailscale client?

I would not say it is. It becomes a chicken and egg problem, there might be things that would be necessary to log early in the startup process, before the client reaches the control server and since we disable this from the control server, it cant be turned off early enough.

The way I would look at it is that the clients are first and foremost designed to provide debugging opportunities for engineers working on them, and not for "us".

From the linked issue:

If there is anything private in there, that's a bug.

The information that might be logged, and particularly before the connection to the server should not be of any concern.

@kradalby commented on GitHub (Oct 16, 2025): > (including on mobile apps)... I think the way you would do this on mobile applications would be via MDM configuration, that is likely the way to set such options early enough to stop things from being configured. > Could this be considered a bug in the Tailscale client? I would not say it is. It becomes a chicken and egg problem, there might be things that would be necessary to log early in the startup process, before the client reaches the control server and since we disable this _from_ the control server, it cant be turned off early enough. The way I would look at it is that the clients are first and foremost designed to provide debugging opportunities for engineers working on them, and not for "us". From the linked issue: > If there is anything private in there, that's a bug. The information that might be logged, and particularly before the connection to the server should not be of any concern.
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Oct 16, 2025):

If the logtail.enabled option does not disable logging, this contradicts their statement that logs can be disabled by disabling logtail in Headscale.

Have you checked if the client sends logs to log.tailscale.com after it established a connection with Headscale or does establish a connection on startup and stops sending logs as soon as it receives its configuration from Headscale.

@nblock commented on GitHub (Oct 16, 2025): > If the `logtail.enabled` option does not disable logging, this contradicts their statement that logs can be disabled by disabling logtail in Headscale. Have you checked if the client sends logs to log.tailscale.com after it established a connection with Headscale or does establish a connection on startup and stops sending logs as soon as it receives its configuration from Headscale.
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@word5355 commented on GitHub (Oct 16, 2025):

@kradalby

clients are first and foremost designed to provide debugging opportunities for engineers...

I agree. It's common and necessary for client software to have such features built-in.
However, there are people like me who prefer not to rely on external servers and want to minimize that dependency.
I believe that aligns with the design goal of headscale as well.

@nblock
Yes, it seems to be continuously attempting to connect to the log server, even though a connection to Headscale has been established and it is successfully connected to a remote node.

Image
@word5355 commented on GitHub (Oct 16, 2025): @kradalby > clients are first and foremost designed to provide debugging opportunities for engineers... I agree. It's common and necessary for client software to have such features built-in. However, there are people like me who prefer not to rely on external servers and want to minimize that dependency. I believe that aligns with the design goal of headscale as well. @nblock Yes, it seems to be continuously attempting to connect to the log server, even though a connection to Headscale has been established and it is successfully connected to a remote node. <img width="1100" height="618" alt="Image" src="https://github.com/user-attachments/assets/dd153bdd-cb08-4387-9e49-bf31ff12f20a" />
adam commented 2025-12-29 02:28:19 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 16, 2025):

However, there are people like me who prefer not to rely on external servers and want to minimize that dependency.
I believe that aligns with the design goal of headscale as well.

This is fair, but it does not rely on it, if you block them, you will still be fine.

@kradalby commented on GitHub (Oct 16, 2025): > However, there are people like me who prefer not to rely on external servers and want to minimize that dependency. > I believe that aligns with the design goal of headscale as well. This is fair, but it does not rely on it, if you block them, you will still be fine.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1110
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?