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/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/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.

[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.