EDACerton

Upstream is supportive of Unraid and have merged several PRs from me specifically to improve functionality on Unraid. I opened that issue shortly before the holidays, so let’s give them a little time now to get caught up and take a look.

Can you post a fresh Tailscale diagnostics?

This is not an issue with the Tailscale plugin, please make a post in the pre releases forum: https://forums.unraid.net/bug-reports/prereleases/

This is not an issue with the Tailscale plugin, please make a post in the pre releases forum: https://forums.unraid.net/bug-reports/prereleases/

Eh, probably easier to migrate to something that’s not .win — I just happen to use .win because they’re cheap for long registrations. I doubt the snort people care about me 😂

It's not a one-or-the-other thing. The plugin gives you access to the WebGUI/NFS/SMB/bridged containers. The docker method lets you create unique Tailscale machines for different containers, which is useful if you want to share them with other people (but not your whole Unraid server). You can use either, or both, it all depends on what you want to do

https://selfhosters.net/remote/tailscale/docker/#running-tailscale-as-a-sidecar-container

If "no internet connection ever" is what you want, you would need to set up and trust a private CA.

In concept, this is true. In practice, though, it’s not a big deal. It is accurate that you need an internet connection to do an online CRL/OCSP check. However, some browsers don’t even do online checks by default (e.g., Chrome uses CRLSets instead of online checks), and browsers that do use online checks use a “soft-fail” mechanism (if the OCSP/CRL server can’t be reached, the certificate is assumed to be OK). While it is possible to force browsers into a hard-fail configuration, that’s not the default in anything that I’m aware of. So, even without internet, your browser will handle something like a LE certificate just fine.

This is not entirely accurate. When a subnet route is advertised over Tailscale, all traffic to that network is sent via the tailnet, even when you are on the same network. This is by design for Tailscale -- there are cases where you might connect to a network that uses the same private IP space as home (e.g., public wifi), and you don't want to lose access to your devices / connect to a device on the local network that you didn't want to. The traffic doesn't (shouldn't) go over the internet when you're on the same network, though. In that case, data will still flow through Tailscale, but the two devices should be able to negotiate a direct connection to transfer data (unless you have something on your network/router/firewall preventing them from talking to each other). The traffic between the devices should not traverse the WAN. All of the devices do need access to the control server, though -- so if your WAN is down, Tailscale won't work at all, and local access will operate as if Tailscale wasn't there. Tailscale behavior after losing internet access can be unpredictable. The client regularly communicates with the control plane. The best I can offer is that, depending on when the devices last talked to each other / control servers / etc., you *might* be able to make a connection, or you might not, or it might connect and then disconnect a short time later -- but I would expect failure after losing internet. In the case of subnet routes, it's kind of moot anyways, since if Tailscale disconnects you'd just be able to connect locally.

You're in the right place, you just need to switch to the editing mode, then you can select an exit node: https://selfhosters.net/remote/tailscale/advanced/

There can be lots of reasons for that... firewalls, etc. I'd recommend reading through Tailscale's documentation on firewalls to see if there's something there that would be helpful: https://tailscale.com/kb/1181/firewalls

That change is persisted in the Tailscale state.

You can share devices between tailnets. https://tailscale.com/kb/1084/sharing

That error shouldn't affect anything. The plugin already sets the GRO forwarding for the system interface, the warning is just for the Docker shim network.

Please take discussion about running Tailscale in LXC/VM to another thread, it’s out of scope for the plugin support thread.

FYI, it's fine to have multiple files with the same number. Your file wouldn't affect Tailscale at all.

Disclaimer: users should understand that by running Tailscale/NPM/(anything actually) in an LXC, they inherit any work required to update/maintain that installation. They will no longer get updates from containers, etc... they will have to either manually update the applications/LXC or set up automation to do so.

This isn't a support topic for the docker mod (issues with that should go to the Docker mod GitHub page, since I don't develop that), however: Routing traffic via an exit node requires that the container use Tailscale in "kernel networking" mode, not "userspace networking" mode. I don't know if the docker mod can be switched to use kernel networking. However, you could install Tailscale as a sidecar container with kernel networking: https://selfhosters.net/remote/tailscale/docker/#running-tailscale-as-a-sidecar-container

Installing Tailscale in an Ubuntu VM is outside of the scope of the Tailscale plugin for Unraid. You should take that question to either Ubuntu or Tailscale support communities.

Enabling --accept-routes on an Unraid server is almost always a bad idea. You shouldn’t enable that unless you understand the ramifications of turning it on. The plugin has some logic in it to help folks that turn it on anyways, but it’s not perfect. There’s a reason that the GUI option to enable it is in “Advanced” mode *and* includes a warning message.

The error is being created by MOTD, but that’s not the real issue here — it’s saying that you don’t have a /boot/config/share.cfg file. That file is generally required for Unraid to work properly, so if you’re missing that you have a larger problem with the system.

Yes. Welcome to Unraid development

As far as I know, Docker doesn't provide a simple way to do this with bridge networks. You'd probably need to switch that to br0 to avoid the exit node, although by doing so you'd lose connectivity to the container via the Tailscale plugin. However, if you're using the LSIO container, you could install the universal docker mod for Tailscale, which would allow it to register with Tailscale directly, even on the br0 network: https://github.com/tailscale-dev/docker-mod

If you click where it says "Viewing" in that picture, it will open an option to sign in. You can then use the web interface to select an exit node.