FR: Add additional documentation about failing closed/implicit deny (particularly for subnet routers)

[nealf]

What are you trying to do?

Thanks for Tailscale! As a paying customer, we're enjoying using it more and more! One aspect is that I am evaluating moving some of our users off of our legacy VPN and onto Tailscale and ran into an issue that I was trying to figure out whether it was a bug or we had misconfigured ACLs when I saw this in another issue:

Philosophically, Tailscale generally chooses to fail closed. If something is blocked that doesn't mean remove it from the configuration, that means block it. So for example if a subnet router on the tailnet is advertising 192.168.0.0/16 and ACLs block a node from accessing 192.168.0.0/16, we don't ignore the subnet route on that node. Ignoring the denied subnet route would mean that attempts to access 192.168.1.1 wouldn't be blocked by ACLs, they might instead try to use the coffee shop wifi network the node is currently on which happens to use 192.168.1.0.

How should we solve this?

This may be something that should be called out more clearly in multiple sections of the documentation. I set up a subnet router, and configured acls for a small group of our users to test using Tailscale instead of our legacy VPN. I then started getting reports of users not in that test group/acl suddenly saying they couldn't access resources (which turned out to be because Tailscale was actively blocking those ip ranges). The subnets documentation doesn't mention that significant implication, and despite remembering having seen something about implicit deny's mentioned elsewhere in the docs, it didn't occur to me that it would also apply to entire subnets.

I understand the reason for doing it, but adding additional docs would be helpful! I didn't see a repo for the docs that I could contribute to, but if I missed it let me know! Thanks!

What is the impact of not solving this?

Other users are likely to experience similar situations, where they unknowingly block traffic for a portion of their users. I can see this particularly for hybrid environments, where there may be a "remote" group and an "on-prem" group, and the new Tailscale admins setup a subnet router and provide ACLs for just the remote group, while they expect on-prem users to continue to be able to route over the local network, and be surprised when all the on-prem users can no longer access anything!

Anything else?

No response