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

[Bug] autogroup:self will cover other ACL rules #1127

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

Originally created by @hanzec on GitHub (Oct 30, 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 following ACL rules applied

    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self:*"]
    },
    {
      "action": "accept",
      "src": ["group:home"],
      "dst": ["192.168.2.0/24:*",
                  "tag:router:*"]
    }

running tailscale status on nodes register by user in group:home only return current user's node.

Expected Behavior

running tailscale status should return following nodes:

  • current user's node
  • nodes with tag:route

Steps To Reproduce

inserting above to ACL Rules, tailscale status only return current user's node.
removing autogroup rules, tailscale status return nodes with tag:router

Environment

- OS: client node running MacOS 26.0.1, router node using OPNSense
- Headscale version: 0.27.0
- Tailscale version: client 1.91.26, router 1.88.3

Runtime environment

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

Debug information

full configuration log:

{
  "groups": {
    "group:infer-admin": ["test-1@example.com"],
    "group:home": ["test-1@example.com", "test-2@example.com"]
  },

  "tagOwners": {
    "tag:home": ["group:home"],
    "tag:home-router": ["group:infer-admin"]
  },

  "acls": [
    {
      "action": "accept",
      "src": ["sa-headplane@example.com"],
      "dst": ["*:*"]
    },
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self:*"]
    },
    {
      "action": "accept",
      "src": ["group:home"],
      "dst": ["192.168.2.0/24:*",
              "tag:home-router:*"]
    }
  ]
}
Originally created by @hanzec on GitHub (Oct 30, 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 following ACL rules applied ``` { "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] }, { "action": "accept", "src": ["group:home"], "dst": ["192.168.2.0/24:*", "tag:router:*"] } ``` running `tailscale status` on nodes register by user in group:home only return current user's node. ### Expected Behavior running `tailscale status` should return following nodes: - current user's node - nodes with tag:route ### Steps To Reproduce inserting above to ACL Rules, `tailscale status` only return current user's node. removing autogroup rules, `tailscale status` return nodes with tag:router ### Environment ```markdown - OS: client node running MacOS 26.0.1, router node using OPNSense - Headscale version: 0.27.0 - Tailscale version: client 1.91.26, router 1.88.3 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information full configuration log: ``` { "groups": { "group:infer-admin": ["test-1@example.com"], "group:home": ["test-1@example.com", "test-2@example.com"] }, "tagOwners": { "tag:home": ["group:home"], "tag:home-router": ["group:infer-admin"] }, "acls": [ { "action": "accept", "src": ["sa-headplane@example.com"], "dst": ["*:*"] }, { "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] }, { "action": "accept", "src": ["group:home"], "dst": ["192.168.2.0/24:*", "tag:home-router:*"] } ] } ```
adam added the bugno-stale-botpolicy 📝 labels 2025-12-29 02:28:25 +01:00
adam closed this issue 2025-12-29 02:28:25 +01:00
adam commented 2025-12-29 02:28:26 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Oct 30, 2025):

I just tested this with a quick test file i wrote with help of Cursor and i can't seem to replicate this issue in the tests, i used the exact acl you provided for the test and this was the outcome.

Test Configuration

  • User1 has 2 devices (laptop + phone)
  • Router owned by router-owner (different user)
  • Router tagged with tag:home-router

ACL allows:

  • autogroup:member -> autogroup:self (same-user connectivity)
  • group:home -> tag:home-router (cross-user connectivity to tagged router)

Results

user1 device1 peers: [2, 3]  // sees device2 (same user) + router (cross-user)
user1 device2 peers: [1, 3]  // sees device1 (same user) + router (cross-user)
@vdovhanych commented on GitHub (Oct 30, 2025): I just tested this with a quick test file i wrote with help of Cursor and i can't seem to replicate this issue in the tests, i used the exact acl you provided for the test and this was the outcome. **Test Configuration** - User1 has 2 devices (laptop + phone) - Router owned by router-owner (different user) - Router tagged with tag:home-router **ACL allows:** - autogroup:member -> autogroup:self (same-user connectivity) - group:home -> tag:home-router (cross-user connectivity to tagged router) **Results** ``` user1 device1 peers: [2, 3] // sees device2 (same user) + router (cross-user) user1 device2 peers: [1, 3] // sees device1 (same user) + router (cross-user) ```
adam commented 2025-12-29 02:28:26 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Oct 30, 2025):

I'm seeing something similar which is 100% reproducible for me when autogroup:member/self is used in an ACL. This may get a little long but take this scenario:

A test user:

And three nodes:

Two personal untagged nodes owned by "user@domain.com":

  • personal1
  • personal2

One server node tagged with "server" not owned by "user@domain.com":

  • tagged-server

Then start with an ACL like:

{
  "action": "accept",
  "src": [
    "user@domain.com"
  ],
  "dst": [
    "user@domain.com:*",
    "tag:server:*"
  ]
}

  • Restart Headscale (to work around the tagged ACL not getting picked up until a restart).

  • Then connect all three nodes. "personal1" can tailscale ping both "personal2" and "tagged-server" as expected.

  • This is also stable between ACL updates (that don't include any autogroup:member/self)

  • Now add and apply an autogroup:member/self rule to the ACL like:

{
  "action": "accept",
  "src": [
    "autogroup:member"
  ],
  "dst": [
    "autogroup:self:*"
  ]
}
  • After the ACL update "personal1" can still tailscale ping "personal2" but can no longer reach "tagged-server".

The only way for it to access "tagged-server" again is to either disconnect/reconnect Tailscale on "personal1" or remove the autogroup:member/self rule from the ACL.

If Tailscale on "personal1" is disconnected/reconnected (with the autogroup rule still in place) it will be able to reach "tagged-server" until any sort of ACL update happens -- even just saving the ACL with no changes at all.

I know that's confusing, but if there are questions ask away.

@Codelica commented on GitHub (Oct 30, 2025): I'm seeing something similar which is 100% reproducible for me when `autogroup:member/self` is used in an ACL. This may get a little long but take this scenario: A test user: - user@domain.com And three nodes: Two personal **untagged** nodes **owned** by "user@domain.com": - personal1 - personal2 One server node **tagged** with "server" **not owned** by "user@domain.com": - tagged-server Then start with an ACL like: ```json { "action": "accept", "src": [ "user@domain.com" ], "dst": [ "user@domain.com:*", "tag:server:*" ] } ``` - Restart Headscale (to work around the tagged ACL not getting picked up until a restart). - Then connect all three nodes. "personal1" can `tailscale ping` both "personal2" and "tagged-server" as expected. - This is also stable between ACL updates (that don't include any autogroup:member/self) - Now **add** and apply an autogroup:member/self rule to the ACL like: ```json { "action": "accept", "src": [ "autogroup:member" ], "dst": [ "autogroup:self:*" ] } ``` - After the ACL update "personal1" can still `tailscale ping` "personal2" but **can no longer reach** "tagged-server". The only way for it to access "tagged-server" again is to either disconnect/reconnect Tailscale on "personal1" or remove the autogroup:member/self rule from the ACL. If Tailscale on "personal1" is disconnected/reconnected (with the autogroup rule still in place) it will be able to reach "tagged-server" **until any sort of ACL update happens** -- even just saving the ACL with **no changes** at all. I know that's confusing, but if there are questions ask away.
adam commented 2025-12-29 02:28:26 +01:00
Author
Owner
Copy Link

@hanzec commented on GitHub (Oct 31, 2025):

I just tested this with a quick test file i wrote with help of Cursor and i can't seem to replicate this issue in the tests, i used the exact acl you provided for the test and this was the outcome.

Test Configuration

  • User1 has 2 devices (laptop + phone)
  • Router owned by router-owner (different user)
  • Router tagged with tag:home-router

ACL allows:

  • autogroup:member -> autogroup:self (same-user connectivity)
  • group:home -> tag:home-router (cross-user connectivity to tagged router)

Results

user1 device1 peers: [2, 3]  // sees device2 (same user) + router (cross-user)
user1 device2 peers: [1, 3]  // sees device1 (same user) + router (cross-user)

Is there any other information I could provide to help identify this potential bug?

right now I have four users:

  1. test-1@example.com
  2. test-2@example.com
  3. sa-opnsense@example.com
  4. sa-headplane@example.com

and following nodes:

  1. device-A (MacOS, test-1@example.com, no ACL tag)
  2. device-B (MacOS, test-1@example.com, no ACL tag)
  3. router-a (OPNSense, sa-opnsense@example.com, tag:home-router)
  4. device-C (Linux, sa-headplane@example.com, no ACL tag)

router-a has 192.168.2.0/24 routing, and its tag is added by head scale command line

@hanzec commented on GitHub (Oct 31, 2025): > I just tested this with a quick test file i wrote with help of Cursor and i can't seem to replicate this issue in the tests, i used the exact acl you provided for the test and this was the outcome. > > **Test Configuration** > > * User1 has 2 devices (laptop + phone) > * Router owned by router-owner (different user) > * Router tagged with tag:home-router > > **ACL allows:** > > * autogroup:member -> autogroup:self (same-user connectivity) > * group:home -> tag:home-router (cross-user connectivity to tagged router) > > **Results** > > ``` > user1 device1 peers: [2, 3] // sees device2 (same user) + router (cross-user) > user1 device2 peers: [1, 3] // sees device1 (same user) + router (cross-user) > ``` Is there any other information I could provide to help identify this potential bug? right now I have four users: 1. test-1@example.com 2. test-2@example.com 3. sa-opnsense@example.com 4. sa-headplane@example.com and following nodes: 1. device-A (MacOS, test-1@example.com, no ACL tag) 2. device-B (MacOS, test-1@example.com, no ACL tag) 3. router-a (OPNSense, sa-opnsense@example.com, tag:home-router) 4. device-C (Linux, sa-headplane@example.com, no ACL tag) router-a has 192.168.2.0/24 routing, and its tag is added by head scale command line
adam commented 2025-12-29 02:28:26 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Oct 31, 2025):

Ok i can replicate it now, i think i know what is the issue i'll try to create PR with a fix.

@vdovhanych commented on GitHub (Oct 31, 2025): Ok i can replicate it now, i think i know what is the issue i'll try to create PR with a fix.
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Oct 31, 2025):

Great! If a dev Docker image can be built with the change I'd be glad to test it. 👍

@Codelica commented on GitHub (Oct 31, 2025): Great! If a dev Docker image can be built with the change I'd be glad to test it. 👍
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Nov 2, 2025):

Fixed in af2de35b6c

@nblock commented on GitHub (Nov 2, 2025): Fixed in af2de35b6caebd4665f2fcc74a0f3fe1b1b094fe
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Nov 11, 2025):

I'm afraid I'm still seeing this behavior in 0.27.1. Basically once there is a autogroup:member/self rule in the ACL any updates to the ACL will cause connected nodes to not be able to reach any non-personal nodes until they disconnect and reconnect. (ie. tailscale ping some-server won't work on acl update until Tailscale client is restarted)

@Codelica commented on GitHub (Nov 11, 2025): I'm afraid I'm still seeing this behavior in 0.27.1. Basically once there is a autogroup:member/self rule in the ACL any updates to the ACL will cause connected nodes to not be able to reach any non-personal nodes until they disconnect and reconnect. (ie. `tailscale ping some-server` won't work on acl update until Tailscale client is restarted)
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Nov 12, 2025):

I'm afraid I'm still seeing this behavior in 0.27.1. Basically once there is a autogroup:member/self rule in the ACL any updates to the ACL will cause connected nodes to not be able to reach any non-personal nodes until they disconnect and reconnect. (ie. tailscale ping some-server won't work on acl update until Tailscale client is restarted)

Could you please provide all the required details to reproduce it?

@nblock commented on GitHub (Nov 12, 2025): > I'm afraid I'm still seeing this behavior in 0.27.1. Basically once there is a autogroup:member/self rule in the ACL any updates to the ACL will cause connected nodes to not be able to reach any non-personal nodes until they disconnect and reconnect. (ie. `tailscale ping some-server` won't work on acl update until Tailscale client is restarted) Could you please provide all the required details to reproduce it?
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Nov 12, 2025):

That looks to be a different issue. It will likely be related to cache clearing, as using autogroup:self results in a different structure, which differs somewhat from the rest of the policy caching clearing. Is the original issue resolved for you? Meaning, if all nodes are connected, you have the autogroup:self in the ACLS. Do you see the nodes, and can you communicate between them as expected? Besides the issue you describe here.

@vdovhanych commented on GitHub (Nov 12, 2025): That looks to be a different issue. It will likely be related to cache clearing, as using autogroup:self results in a different structure, which differs somewhat from the rest of the policy caching clearing. Is the original issue resolved for you? Meaning, if all nodes are connected, you have the autogroup:self in the ACLS. Do you see the nodes, and can you communicate between them as expected? Besides the issue you describe here.
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Nov 12, 2025):

Sorry for the delay, have to help with an urgent issue today but will respond later with detailed example.

But yes, it's only when an ACL update is pushed after autogroup:member/self exists in the ACL. If there is no autogroup:member/self in the ACL you can modify the ACL without issue as expected. Once autogroup:member/self is in the ACL any future ACL changes/updates (even just updating ACL with no functional changes) causes connected clients who could normally communicate via rules outside of autogroup:member/self not to be able to until they restart Tailscale. They can see each other via tailscale status, but can't tailscale ping each other.

@Codelica commented on GitHub (Nov 12, 2025): Sorry for the delay, have to help with an urgent issue today but will respond later with detailed example. But yes, it's only when an ACL update is pushed **after** `autogroup:member/self` exists in the ACL. If there is no `autogroup:member/self` in the ACL you can modify the ACL without issue as expected. Once `autogroup:member/self` is in the ACL any future ACL changes/updates (even just updating ACL with no functional changes) causes connected clients who could normally communicate via rules outside of `autogroup:member/self` not to be able to until they restart Tailscale. They can see each other via `tailscale status`, but can't `tailscale ping` each other.
adam commented 2025-12-29 02:28:27 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Nov 12, 2025):

I have a potential fix for this, it should hopefully resolve it.

@vdovhanych commented on GitHub (Nov 12, 2025): I have a potential fix for this, it should hopefully resolve it.
adam commented 2025-12-29 02:28:28 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Nov 30, 2025):

I've made a rc.1 release for 0.27.2 with fixes, would be great if you can test this.

@kradalby commented on GitHub (Nov 30, 2025): I've made a [rc.1 release for 0.27.2](https://github.com/juanfont/headscale/releases/tag/v0.27.2-rc.1) with fixes, would be great if you can test this.
adam commented 2025-12-29 02:28:28 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Dec 1, 2025):

Seems to be working for me on my personal system. 👍 Won't be able to try it on our (larger) company system for a few days.

@Codelica commented on GitHub (Dec 1, 2025): Seems to be working for me on my personal system. 👍 Won't be able to try it on our (larger) company system for a few days.
adam commented 2025-12-29 02:28:28 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Dec 5, 2025):

Unfortunately I won't be able to update our larger install this week. Our salespeople are to blame ;) But it's been working well on my personal system where I've made several acl changes.

@Codelica commented on GitHub (Dec 5, 2025): Unfortunately I won't be able to update our larger install this week. Our salespeople are to blame ;) But it's been working well on my personal system where I've made several acl changes.
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 no-stale-bot policy 📝
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#1127
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?