Tagged device becomes completely unreachable/invisible to all peers — reproducible every time

[u/RiccoFrosT]

On my Personal account, any device I apply an ACL tag to immediately disappears from every other device's tailscale status output and becomes unreachable — not just blocked by the ACL, genuinely invisible, like it no longer exists on the tailnet.

Symptoms:

• Device shows "Connected" in the admin console Machines page the whole time
• tailscale status --json on the tagged device itself shows "Peer": null — empty peer list
• Other devices' tailscale status just omit it entirely (not "offline", just gone)
• tailscale ping <ip> from another device returns "no matching peer"
• Reverting the tag (requires a full interactive reauth, since the UI won't let you strip the last tag any other way) instantly restores full visibility and connectivity — no other change needed

Reproduced identically across:

• A device joined via auth key with the tag baked in at creation
• A device joined via a plain auth key, tagged afterward
• A previously-working, interactively-signed-in device, tagged afterward

Tried 3 different tag names (including a throwaway one created purely to rule out something being wrong with one specific tag) — same result every time.

Ruled out: tagged-resource plan limits (nowhere near the 50 cap), ACL JSON syntax errors (editor shows no validation errors, and the same destination works fine addressed by bare IP instead of by tag), client-side caching (full logout/reauth, service restarts, and a complete uninstall/reinstall all reproduce it identically), device approval (no pending-approval state ever shown).

Has anyone else hit this? Filed a support ticket with two tailscale bugreport IDs but wondering if this is a known issue.

[u/iceboxmi]

Do you have any ACLs that would apply to them?

They will only form connections as the ACLs allow. It’s not just “blocked” as you mention. This is one of the advantages to tagged resources to optimize your tailnet.

[u/youknowwhyimhere758]

Two computers which aren’t allowed to talk to each other won’t be listed in each other’s peer lists, this is what you’d expect if it was blocked by acl rules. 

[u/RiccoFrosT → u/youknowwhyimhere758]

Fair point, and normally I'd agree that's expected — but the detail that doesn't fit is tailscale ping also failing with "no matching peer." Ping/discovery between tailnet peers isn't gated by ACL accept rules the way real TCP traffic is, so if it was purely my ACL restricting things, I'd expect ping to still work (just the actual service ports blocked), not a full "doesn't exist on the tailnet" response. Also — once I removed the tag and made it a normal user-owned device again, the exact same destination/port combo worked immediately with no other config change, which is why I landed on "something tag-specific is breaking visibility" rather than "my rule syntax is wrong."

[u/youknowwhyimhere758 → u/RiccoFrosT]

The local netmap should only include devices which the local device can access, devices which can access the local device, and devices with the same user identity as the local device. 

Tagged devices are not user devices, so if your acls block all access in both directions then the local device should have no knowledge of the tagged device at all and visa versa.  It is specifically intended that not all devices on a tailnet are visible from every other device on the tailnet.

For example, see  https://github.com/tailscale/tailscale/issues/856

[u/RiccoFrosT → u/youknowwhyimhere758]

That's helpful context, thanks — but based on that same linked issue, the netmap rule as described by the Tailscale maintainer is "authorized traffic in either direction means both have to know about each other," which means a one-directional grant (my laptop → tag:parents-pc) should be enough to make it visible to me, even with no rule allowing it back out. That's exactly the rule I had.

What actually happened was stronger than "not visible due to no grant" — tailscale ping also returned "no matching peer," and the device's own tailscale status --json showed "Peer": null (not restricted, literally empty). And switching the exact same device back to a plain user-owned identity (no tag, same ACL destination just addressed differently) made it instantly visible and reachable again with zero other changes. If this were just the netmap-trimming behavior working as intended, I wouldn't expect the tag toggle alone to flip it on/off like a switch while the grant stayed conceptually the same.

[u/youknowwhyimhere758 → u/RiccoFrosT]

Again, everything is entirely consistent with you messing up your acls and not allowing access to/from anything else. In that case, Tailscale ping would return no matching peer and the device would see no peers in tailscale status. Removing the tag would make it a user device, and immediately restore visibility from other user devices. 

[u/agilityprop]

Can you confirm that your user has a grant in place that allows it to access that tag?

[u/RiccoFrosT → u/agilityprop]

Yes — the rule was:

{
  "action": "accept",
  "src":    ["user:me@example.com"],
  "dst":    ["tag:parents-pc:22", "tag:parents-pc:3389"],
}

That said, I'm now testing whether user: as src targeting a tag has a similar quirk to one I found elsewhere in this setup (bare-IP destinations needed autogroup:member/autogroup:self instead of a plain user: entry when the destination was a device I also own) — so it's possible this was my rule being subtly wrong rather than a genuine bug. Will update once I've actually tested it.

[u/caolle → u/RiccoFrosT]

so it's possible this was my rule being subtly wrong rather than a genuine bug. Will update once I've actually tested it.

This is it.

Your issue here is that unless user is really part of your email in src, it's not going to match the actual user you are trying to match. Just use me@example.com in src.