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

Updating to 0.22.2 causes all devices to see each other, regardless of ACLs #506

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

Originally created by @networkException on GitHub (May 11, 2023).

Bug description

After updating to 0.22.0, running tailscale status on any connected machine shows a list of all devices in the tailnet, even if machine A doesn't have any ACL allowing access to machine B.

Environment

  • OS: Linux
  • Headscale version: 0.22.2
  • Tailscale version: 1.40.0
  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

To Reproduce

  • Run headscale 0.22.2
  • Run tailscale status on a connected machine
  • See all devices in the tailnet
Originally created by @networkException on GitHub (May 11, 2023). <!-- Before posting a bug report, discuss the behaviour you are expecting with the Discord community to make sure that it is truly a bug. The issue tracker is not the place to ask for support or how to set up Headscale. Bug reports without the sufficient information will be closed. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Bug description <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> After updating to 0.22.0, running `tailscale status` on any connected machine shows a list of all devices in the tailnet, even if machine A doesn't have any ACL allowing access to machine B. ## Environment <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output --> - OS: Linux - Headscale version: 0.22.2 - Tailscale version: 1.40.0 <!-- We do not support running Headscale in a container nor behind a (reverse) proxy. If either of these are true for your environment, ask the community in Discord instead of filing a bug report. --> - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ## To Reproduce <!-- Steps to reproduce the behavior. --> - Run headscale 0.22.2 - Run `tailscale status` on a connected machine - See all devices in the tailnet
adam added the stalebug labels 2025-12-29 02:19:16 +01:00
adam closed this issue 2025-12-29 02:19:16 +01:00
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@pkrivanec commented on GitHub (May 12, 2023):

Hi, I do not see this behavior in my environment.
Can you provide a minimal ACL file where the problem occurs?

@pkrivanec commented on GitHub (May 12, 2023): Hi, I do not see this behavior in my environment. Can you provide a minimal ACL file where the problem occurs?
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@networkException commented on GitHub (May 12, 2023):

{
    "hosts": {
        "a": "fd7a:115c:a1e0::4",
        "b": "fd7a:115c:a1e0::6",
    },
    "acls": [
        {
            "action": "accept",
            "proto": "tcp",
            "src": ["b"],
            "dst": ["a:8001"]
        },
    ],
}
@networkException commented on GitHub (May 12, 2023): ```jsonc { "hosts": { "a": "fd7a:115c:a1e0::4", "b": "fd7a:115c:a1e0::6", }, "acls": [ { "action": "accept", "proto": "tcp", "src": ["b"], "dst": ["a:8001"] }, ], } ```
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@pkrivanec commented on GitHub (May 13, 2023):

Hi, yes I can confirm that, the problem occurs as soon as a hosts entry is used.

@pkrivanec commented on GitHub (May 13, 2023): Hi, yes I can confirm that, the problem occurs as soon as a hosts entry is used.
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@statkashaman commented on GitHub (Jun 7, 2023):

Hi, with this configuration, users also began to see each other, although previously they saw only exit nodes. This happened after updating from 0.21.0 to 0.22.3.

        ---
        tagOwners:
          tag:exitnode:
            - exitnodes
        acls:
          - action: accept
            src:
              - "*"
            dst:
              - "tag:exitnode:*"
          - action: accept
            src:
              - "*"
            dst:
              - "0.0.0.0/0:*"```
@statkashaman commented on GitHub (Jun 7, 2023): Hi, with this configuration, users also began to see each other, although previously they saw only exit nodes. This happened after updating from 0.21.0 to 0.22.3. ``` headscale-acl.yaml: |- --- tagOwners: tag:exitnode: - exitnodes acls: - action: accept src: - "*" dst: - "tag:exitnode:*" - action: accept src: - "*" dst: - "0.0.0.0/0:*"```
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jun 7, 2023):

{
    "hosts": {
        "a": "fd7a:115c:a1e0::4",
        "b": "fd7a:115c:a1e0::6",
    },
    "acls": [
        {
            "action": "accept",
            "proto": "tcp",
            "src": ["b"],
            "dst": ["a:8001"]
        },
    ],
}

To clarify, the issue is that after version 0.22.2, when you run tailscale status on host a or b, both a and b will be listed?

Previously, when you ran tailscale status on host a, you did not see host b in the list?

@kradalby commented on GitHub (Jun 7, 2023): > ```js > { > "hosts": { > "a": "fd7a:115c:a1e0::4", > "b": "fd7a:115c:a1e0::6", > }, > "acls": [ > { > "action": "accept", > "proto": "tcp", > "src": ["b"], > "dst": ["a:8001"] > }, > ], > } > ``` To clarify, the issue is that after version `0.22.2`, when you run `tailscale status` on host `a` or `b`, both `a` and `b` will be listed? Previously, when you ran `tailscale status` on host `a`, you did _not_ see host `b` in the list?
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jun 15, 2023):

If the case is as mentioned above, this is intended behaviour, this is because a one way direction needs to be present on both nodes even if one node cannot actually access the other. This was previously wrongly implemented in Headscale, giving the wrong impression of how it should work.

If this is not the case, please reopen with a reply to the previous comment.

@kradalby commented on GitHub (Jun 15, 2023): If the case is as mentioned above, this is intended behaviour, this is because a one way direction needs to be present on both nodes even if one node cannot actually access the other. This was previously wrongly implemented in Headscale, giving the wrong impression of how it should work. If this is _not_ the case, please reopen with a reply to the previous comment.
adam commented 2025-12-29 02:19:17 +01:00
Author
Owner
Copy Link

@networkException commented on GitHub (Jun 15, 2023):

Sorry for only coming back to this now. (I also don't seem to be able to reopen the issue)

{
    "hosts": {
        "a": "fd7a:115c:a1e0::4",
        "b": "fd7a:115c:a1e0::6",
    },
    "acls": [
        {
            "action": "accept",
            "proto": "tcp",
            "src": ["b"],
            "dst": ["a:8001"]
        },
    ],
}

To clarify, the issue is that after version 0.22.2, when you run tailscale status on host a or b, both a and b will be listed?

Previously, when you ran tailscale status on host a, you did not see host b in the list?

They would both see each other perfectly fine previously, this is just the minimal reproducible config to trigger the issue.

What was not clear from my example is that there were actually a lot more devices in the tailnet, hence my "all devices in the tailnet" description initially. Just those don't need to be mentioned in the hosts or acls for the issue to accur, as such I left them out when reducing.

The following config would be a more "complete" example, hinting at the other devices existing. Running tailscale status on any one of those (also ones that are not explicitly listed in the hosts section would yield a list of all nodes in the entire network, again regardless of acls.

{
    "hosts": {
        "1": "fd7a:115c:a1e0::1",
        "2": "fd7a:115c:a1e0::2",
        "3": "fd7a:115c:a1e0::3",
        "a": "fd7a:115c:a1e0::4",
        "5": "fd7a:115c:a1e0::5",
        "b": "fd7a:115c:a1e0::6",
    },
    "acls": [
        {
            "action": "accept",
            "proto": "tcp",
            "src": ["b"],
            "dst": ["a:8001"]
        },
    ],
}
@networkException commented on GitHub (Jun 15, 2023): Sorry for only coming back to this now. (I also don't seem to be able to reopen the issue) > > ```js > > { > > "hosts": { > > "a": "fd7a:115c:a1e0::4", > > "b": "fd7a:115c:a1e0::6", > > }, > > "acls": [ > > { > > "action": "accept", > > "proto": "tcp", > > "src": ["b"], > > "dst": ["a:8001"] > > }, > > ], > > } > > ``` > > To clarify, the issue is that after version `0.22.2`, when you run `tailscale status` on host `a` or `b`, both `a` and `b` will be listed? > > Previously, when you ran `tailscale status` on host `a`, you did _not_ see host `b` in the list? They would both see each other perfectly fine previously, this is just the minimal reproducible config to trigger the issue. What was not clear from my example is that there were actually a lot more devices in the tailnet, hence my "all devices in the tailnet" description initially. Just those don't need to be mentioned in the hosts or acls for the issue to accur, as such I left them out when reducing. The following config would be a more "complete" example, hinting at the other devices existing. Running `tailscale status` on any one of those (also ones that are not explicitly listed in the `hosts` section would yield a list of all nodes in the entire network, again regardless of acls. ```js { "hosts": { "1": "fd7a:115c:a1e0::1", "2": "fd7a:115c:a1e0::2", "3": "fd7a:115c:a1e0::3", "a": "fd7a:115c:a1e0::4", "5": "fd7a:115c:a1e0::5", "b": "fd7a:115c:a1e0::6", }, "acls": [ { "action": "accept", "proto": "tcp", "src": ["b"], "dst": ["a:8001"] }, ], } ```
adam commented 2025-12-29 02:19:18 +01:00
Author
Owner
Copy Link

@networkException commented on GitHub (Aug 11, 2023):

@kradalby could you please take another look at this?

@networkException commented on GitHub (Aug 11, 2023): @kradalby could you please take another look at this?
adam commented 2025-12-29 02:19:18 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Aug 11, 2023):

Ive reopened this, but I don't expect to get to it in a while.

@kradalby commented on GitHub (Aug 11, 2023): Ive reopened this, but I don't expect to get to it in a while.
adam commented 2025-12-29 02:19:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 15, 2023):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Dec 15, 2023): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 23, 2023):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Dec 23, 2023): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:19:18 +01:00
Author
Owner
Copy Link

@disconn3ct commented on GitHub (Dec 23, 2023):

Did stalebot fix this bug? Or just close it?

@disconn3ct commented on GitHub (Dec 23, 2023): Did stalebot fix this bug? Or just close it?
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 stale
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#506
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?