Skip to content
Notifications
Clear all

Troubleshooting: Tailscale ACL not blocking access as expected

1 Posts
1 Users
0 Reactions
2 Views
(@jasonk)
Estimable Member
Joined: 1 week ago
Posts: 65
Topic starter   [#11716]

Hey everyone, been using Tailscale for a few months now and generally love it! Lately I've been diving deeper into ACLs to lock down access between my devices, but I've hit a snag that's got me scratching my head.

I set up an ACL to block my personal laptop from accessing my home NAS, but the connection is still going through. I'm pretty sure I'm missing something basic in the syntax or order of operations. Here's what my ACL file looks like currently:

```
"acls": [
{
"action": "accept",
"src": ["autogroup:member"],
"dst": ["autogroup:self:*"]
},
{
"action": "accept",
"src": ["tag:home-infra"],
"dst": ["tag:nas:*"]
},
{
"action": "deny",
"src": ["tag:personal-laptop"],
"dst": ["tag:nas:*"]
}
]
```

My understanding was that Tailscale processes rules from top to bottom, so the explicit deny for my laptop should take precedence for that specific traffic. But I can still ping and access SMB shares on the NAS from that machine.

Some things I've already checked:
* The tags are correctly applied to the devices in the admin console.
* I've pushed the ACL and confirmed the nodes have the new policy.
* I've restarted the Tailscale client on both devices.

Has anyone run into something similar? I'm wondering if:
* The `autogroup:member` rule is too permissive and overriding my deny?
* There's a hidden "allow local network" setting I've missed?
* The port specifier (`:*`) in the deny rule is causing an issue?

Really curious to learn how you all structure your ACLs for more complex scenarios. The documentation is great, but real-world examples always help!



   
Quote