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

ACLs don't work with host aliases or wildcard sources #264

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

Originally created by @madjam002 on GitHub (May 4, 2022).

Bug description

When using host aliases as a source/destination in ACL policies, or wildcards as the destination, ACL policies don't work and nodes will be unable to communicate with eachother.

My best guess is that this is because the peers aren't being calculated correctly when sending the peer list to each Tailscale client, as source nodes don't appear in the peer list when querying tailscale status on destination nodes (perhaps an issue in getFilteredByACLPeers).

To Reproduce

Given two nodes, node1 and node2 and the following ACL policy (not actually tested but is theoretical), and let's say node1 is authenticated with a user which is part of mygroup (excluded in the example below for brevity):

{
  "hosts": {
    "node1": "100.64.0.1",
    "node2": "100.64.0.2"
  },
  "acls": [{
    "action": "accept",
    "src": ["group:mygroup"],
    "dst": ["node2:22"]
  }]
}

Communication will not be possible from node1 -> node2 over port 22. tailscale status on node2 won't show node1 as a peer.

Changing the destination to the IP address itself:

    "dst": ["100.64.0.2:22"]

and communication will now be possible. tailscale status on node2 will show node1 as a peer. The issue exists in reverse as well, so if a host alias is used in the src, the destination node won't have any valid source nodes as a peer, whereas using the IP address directly works fine.

The same issue exists if the destination is set to *:22 as a wildcard, whereas e.g somenamespace:22 will work fine.

On a separate note, given node1 and node3, where node3 is advertised as an exit node, I've noticed that node3 does not appear in the peer list of node1 even if an ACL permits routes over the public internet, unless an ACL rule exists explicitly allowing access to a port of node3, e.g {"action":"accept","src":["100.64.0.1"],"dst":["100.64.0.2:1111"]} (some bogus port we don't actually use). I think this is a separate issue although it is similar in nature, and I'm not sure if this is expected behaviour compared to how Tailscale's official control plane operates. (actually this subnet router issue looks like it is covered by issue #502)

Context info

  • Tested with headscale commit 3fbfc5a649
  • Tailscale v1.22.2
  • OS Linux NixOS 22.05
  • Kernel version 5.15.34
Originally created by @madjam002 on GitHub (May 4, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the bug report in this language. --> **Bug description** When using host aliases as a source/destination in ACL policies, or wildcards as the destination, ACL policies don't work and nodes will be unable to communicate with eachother. My best guess is that this is because the peers aren't being calculated correctly when sending the peer list to each Tailscale client, as source nodes don't appear in the peer list when querying `tailscale status` on destination nodes (perhaps an issue in `getFilteredByACLPeers`). **To Reproduce** Given two nodes, `node1` and `node2` and the following ACL policy (not actually tested but is theoretical), and let's say `node1` is authenticated with a user which is part of `mygroup` (excluded in the example below for brevity): ``` { "hosts": { "node1": "100.64.0.1", "node2": "100.64.0.2" }, "acls": [{ "action": "accept", "src": ["group:mygroup"], "dst": ["node2:22"] }] } ``` Communication will not be possible from node1 -> node2 over port 22. `tailscale status` on `node2` won't show `node1` as a peer. Changing the destination to the IP address itself: ``` "dst": ["100.64.0.2:22"] ``` and communication will now be possible. `tailscale status` on `node2` will show `node1` as a peer. The issue exists in reverse as well, so if a host alias is used in the `src`, the destination node won't have any valid source nodes as a peer, whereas using the IP address directly works fine. The same issue exists if the destination is set to `*:22` as a wildcard, whereas e.g `somenamespace:22` will work fine. On a separate note, given `node1` and `node3`, where `node3` is advertised as an exit node, I've noticed that `node3` does not appear in the peer list of `node1` even if an ACL permits routes over the public internet, unless an ACL rule exists explicitly allowing access to a port of `node3`, e.g `{"action":"accept","src":["100.64.0.1"],"dst":["100.64.0.2:1111"]}` (some bogus port we don't actually use). I think this is a separate issue although it is similar in nature, and I'm not sure if this is expected behaviour compared to how Tailscale's official control plane operates. (actually this subnet router issue looks like it is covered by issue #502) **Context info** - Tested with headscale commit 3fbfc5a6492d1d60600508efce1ca8d8d1eb3331 - Tailscale v1.22.2 - OS Linux NixOS 22.05 - Kernel version 5.15.34
adam added the bug label 2025-12-29 01:25:17 +01:00
adam closed this issue 2025-12-29 01:25:18 +01:00
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#264
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?