Accept dns, accept routes, taildrop are enabled by default.

Enable + disable: yeah, sadly this is a HA UI (!!!) bug, it shows unused, undefined options as disabled instead of grayed out, when you enable it, only then inserts it into the YAML, save, then you can disable it, save, restart... This UI bug is known for years... I never use the UI for configuration editing, I always edit the YAML. We should add after each option, that "don't use the UI editor, edit the yaml", but I think that wouldn't be merged.

Docs: There are a few open PR-s to update the docs, you can see the planned version below. Please check, what's left out, because as a first time user, you can spot bugs in it, that we never notice. And the DNS (referenced in this doc) is a long story: #455

Option: userspace_networking

The add-on uses [userspace networking mode][tailscale_info_userspace_networking]
to make your Home Assistant instance (and optionally the local subnets)
accessible within your tailnet.

When not set, this option is enabled by default.

If you need to access other clients on your tailnet from your Home Assistant
instance, disable userspace networking mode, which will create a tailscale0
network interface on your host.

To be able to address other clients on your tailnet not only with their tailnet
IP, but with their tailnet name, see the "DNS" section of this documentation.

If you want to access other clients on your tailnet even from your local subnet,
follow steps in the [Site-to-site networking][tailscale_info_site_to_site] guide
(Note: The add-on already handles "IP address forwarding" and "Clamp the MSS to
the MTU" for you).

Note: In case your local subnets collide with subnet routes within your
tailnet, your local network access has priority, and these addresses won't be
routed toward your tailnet. This will prevent your Home Assistant instance from
losing network connection. This also means that using the same subnet on
multiple nodes for load balancing and failover is impossible with the current
add-on behavior.

Note: The userspace_networking option can remain enabled if you only need
one-way access from tailnet clients to your local subnet, without requiring
access from your local subnet to other tailnet clients.

Note: If you implement Site-to-site networking, but you are not interested
in the real source IP address, i.e. subnet devices can see the traffic
originating from the subnet router, you don't need to disable the
snat_subnet_routes option, this can simplify routing configuration.

I think this works for the docs section. I'm a PM for a developer platform by day.

After searching for how to make this work for hours and reading all kinds of forums, I think it be helpful to have a guide for the most common use cases that just tells you what to do.

Connecting two HA instance in different networks seems to be a common thing. So I'd just add a section for this and put the config in there to copy paste.

I'm happy to open a PR if you tell me where this docs should live.

Disclaimer: I'm just a contributor for this add-on, though contributed a lot.

If I understand correctly, you wanted to disable userspace networking, a few clicks, and it should work, but didn't... And a long battle started...

Solutions:

• Disable userspace by default - a few years ago this would be dangerous, I had to write elaborate protection against users soft bricking their devices (two 192.168.1.x subnet, enable routing on the admin page, bummm, HA is gone). The protection seems to be working, but this is not my decision to disable userspace by default. And we have to reword a lot in the docs.
  • This doesn't solve the issue with all other options.
  • We are a few clicks away from disaster (soft bricking HA), because the protection uses supervisor functions that has bugs (Supervisor forgets the default interface's static network addresses after router restart (but not always) home-assistant/supervisor#5361), so the protection is not rock solid.
  • So personally I'm against it.
• Add the default values to the add-on config yaml. It was rejected in Add default values to config #397: "This is an issue with HA not the add-on; I am against solving UX problems in the backend." And I agree with it. Currently the config is quite clean, users edit only what they need.
• Notify users, that the UI is broken, and use the YAML config editor. Sadly I think we should add a big exclamation to the add-on docs at the beginning. :(
  • I will create a PR, let see how it works out.