EDACerton

The current version of the plugin is maintained for 7.0-7.1 (I maintain for the current and previous minor release). I can get a link in a little bit for the last 6.12 version.

There will be a fix for that in an upcoming update.

The general diagnostics don't include Tailscale-specific data, but I'm going to take a guess here that you might have run a command that looks like this at some point: tailscale serve - or - tailscale funnel Those commands will cause Tailscale to run a reverse proxy on port 443, which then interferes with the WebGUI. If you're not sure, you can run this: tailscale serve status If that shows that serve is enabled, you need to turn it off: tailscale serve reset tailscale funnel reset

You can just use the Tailscale plugin if you want to access containers in host mode.

The plugin disables Tailscale DNS by default. Unfortunately, one of the popular video tutorial makers put out a video a while back that directed people to turn it on, which is probably why you had the issue.

snat-subnet-routes is for subnet routers. TSDProxy / tailscale serve is actually a reverse proxy. What you should be looking for is the X-Forwarded-For header that gets added to the request.

Did you turn on Tailscale serve via the CLI at some point?

This isn't something that I intend to implement within the plugin. There's not really a way for injecting options like that into the file browser. It's also a very niche use case, which is probably served better by other tools.

What you're seeing is correct. The "Tailscale WebGUI" that you've seen in videos was removed from the plugin.

Most organizations also wouldn't apply updates fleet-wide immediately after release, and the "show stopper" issues tend to be more niche. In any case, that's not really relevant for this support thread. Relevant to the original question -- speed is affected by a number of factors. @Robert_dokatec: SMB itself can be slow, especially when dealing with lots of files. Make sure that you're getting good speeds locally before worrying about performance over a VPN. Relays will usually be slow. You should try to get a direct connection. https://tailscale.com/kb/1257/connection-types . Your boss might just need to adjust some settings on their router. If your boss is also behind CGNAT, they might be able to pay their ISP a little more to get a public IP. Alternately, make sure IPv6 is enabled/working on both sides, since this will bypass the CGNAT issue entirely.

Tailscale is very reliable and is used by many businesses.

The other tutorials are out of date. I keep updated instructions here: https://edac.dev/unraid/tailscale/plugin/

What do you mean by "not seeing the Tailscale Plugin Webgui"? Is it not showing up under Settings -> Network Services?

This is accurate. You need either TSDProxy or SWAG with the auto proxy mod Support for Traefik is in the works. I’m also open to requests if there’s another service that would benefit.

If you're not using Tailscale DNS, TSDProxy isn't as great of an option, because Tailscale internally relies on SNI (Server Name Indication) for `tailscale serve` connections (in other words, going to an IP won't work -- you have to go to service.tailnet.ts.net). The sidecar would probably be a better technique in that setting: https://edac.dev/unraid/tailscale/docker-sidecar/

Moving containers to br0 + sharing the subnet + adding ACLs is one way to share containers with others, but certainly not the only valid way. I agree that "Use Tailscale" in Docker settings should never be used, because it's a bad implementation (modifying the underlying container and taking over init, which is bad practice). Sharing an individual container as its own Tailscale device can be a useful tool though, and saves the complexity of configuring Tailscale ACLs to restrict access. There are a number of good ways to do this, which I've documented here: https://edac.dev/unraid/tailscale/docker-options/ TSDProxy + Label Manager is a great option for anything that runs via a browser. Sidecar containers are great for things that need more ports (e.g., I run Minecraft via a sidecar container to share with friends).

Update

I encountered this issue on another thread (see below), and the root issue is slightly different: This container maps all of /var/run from the host into the container. This appears to be so that the container can access the docker socket (/var/run/docker.sock), but the container actually gets all of the data in /var/run, including the Tailscale socket in /var/run/tailscale/tailscaled.sock. The "correct" way to fix the issue is to remove the "Docker Socket" mapping from the template. If you need the Docker socket, you can instead map it directly by creating a new mapping for /var/run/docker.sock -> /var/run/docker.sock

I see the issue with this container. It has a mapping for "Docker Socket", but instead of mapping /var/run/docker.sock, it is mapping the entirety of /var/run. /var/run/tailscale/tailscaled.sock is the socket that Tailscale uses to communicate with itself. This means that the container is mapping the host socket into the container, which then causes the chaos you have encountered. If you remove the mapping for /var/run and replace it with one for /var/run/docker.sock, it should work better. (Or, if you're not using the Docker socket for anything, just remove the mapping.)

This is an unfortunately confusing part of how Unraid implemented Tailscale in dockerMan. The Tailscale plugin (installed via Community Apps, and managed via Settings -> Tailscale) is what this thread is for. The "Use Tailscale" feature in Docker is a completely separate feature that shares nothing with the Tailscale plugin. (Speaking plainly, I consider it an option of last resort. It modifies the underlying container, which is bad practice, and there are other/better ways to accomplish the same thing without the bad behavior.) However, to make your life a little easier, I'll give some general advice that applies to Tailscale in containers, no matter how you do it When you install Tailscale in a bridge-mode container, some features that Tailscale uses to help establish direct connections (like NAT-PMP / UPnP) don't work because they're now communicating via an internal router. In some cases that's not a big deal (e.g., if the other device can facilitate the direct connection instead), but in other cases that will result in a relay connection. There are a couple techniques that can help solve this issue: Switch the container from bridge to ipvlan/macvlan (where it gets its own IP), which will allow it to use NAT-PMP/etc. (although with other drawbacks, such as losing container networking / container DNS / port publishing). Publish an additional high port from the container, configure Tailscale (in the container -- not the plugin) to use that port for Wireguard, then forward that port from your gateway to the server.

I’m already helping them, please don’t confuse matters.

You should put br0 back in the listen interfaces. Instructions to download diagnostics are here: https://edac.dev/unraid/plugin-diagnostics/usage/#downloading-diagnostics-gui

As you mentioned, MagicDNS is one of the big benefits of installing Tailscale on every device. There are a variety of other benefits too: You can use Tailscale Serve / HTTPS, which allow you to generate signed HTTPS certificates for the MagicDNS name that browsers, etc. will accept as valid (instead of using self-signed certificates, manually configuring Let's Encrypt with a custom domain name, etc.). Increases resilience, since with a subnet router, that device is a single point of failure (if it goes down, you lose access to everything via Tailscale). It distributes the encryption/decryption work across every device, which can be helpful if your subnet router is running on weaker hardware. (Modern hardware handles encryption well, but if you're running Tailscale on something like a Pi/router/etc., it could make a difference.) Provides better visibility in logs/etc. to see where traffic is coming from (traffic coming via a subnet router is SNAT'ed by default, this can be changed but doing so requires extra configuration on routers/endpoints/etc. to route Tailscale traffic back to the subnet router -- which kind of defeats the point of "easy" ). There's probably some other stuff that I'm not thinking of, but that's a good start

Plugin diagnostics are always helpful: https://edac.dev/unraid/plugin-diagnostics/usage/ ChatGPT doesn't understand how "listening interfaces" works. Removing br0 removes the local interfaces from serving the WebGUI/SSH/etc., so if all you have is "tailscale1", the WebGUI/etc. only being accessible via Tailscale is expected behavior. The plugin automatically adds tailscale1 to that list. If you want to temporarily disable Tailscale, the best way to do it is to set "Enable Tailscale" to "No" in the advanced settings of the plugin. However, using `tailscale down` shouldn't result in odd behavior. Is your Unraid server set up to advertise a subnet? I have to guess here (since I don't have the plugin diagnostics ) but my initial thought would be that the Unraid server is advertising the local subnet, and the unpredictability is being caused by devices not yet realizing that the subnet router is down (so they're trying to send traffic to Unraid's local IP via the now-shut-down subnet router).

It seems like somehow Tailscale didn't connect correctly after the restart. When you redid the login, it replaced the key for the server, so there's no way to make the server register as the "old" machine now. What you can do is delete the old machine from the Tailscale admin console, then use the "Edit machine name" and "Edit machine IPv4" options to make it look like the old one.