EDACerton

I've released some tweaks on the preview branch that might help: 2024.02.04 (Preview) Detect if nginx does not reload correctly after Tailscale comes up Add diagnostic information: ip routing and open ports

Have you rebooted since you removed the Docker plugin? Some folks have had weird issues when switching that only cleared up after rebooting.

Have either of you tried restarting your server? I think this is related to a problem I've been chasing related to when Tailscale is initially logged in, but if that's the case a reboot should fix it.

Tailscale0 is for the docker container, not the plugin. The plugin adds “tailscale1” to extra interfaces.

Yes, you’ll have to use the CLI to connect (tailscale up --login-server)

Please download diagnostics from inside the plugin settings.

I don’t have a lot of great insight on this one… there’s a lot going on there. Tailscale does watch for changes to network adapters, so it’s possible that something weird is happening if you have one that resets every night. If that’s the case, the simplest fix might be to use user scripts to restart Tailscale after the nightly reconnect: /usr/local/emhttp/plugins/tailscale/restart.sh

Enable advanced view in the settings, it will then have an option to enable/disable Tailscale.

If you can’t get to the WebGUI/SSH, there’s not much you can do.

Have you enabled host access to custom networks in your docker settings?

I've decided to start using a two-stage release. The "preview" version will get new updates as soon as they are ready -- new Tailscale versions, UI updates, etc. The "regular" version will update more slowly (this will probably be about a week later than the preview version, although that's not set in stone). It's easy to switch between the two versions, too -- just install the one you want from Community Applications, it will remove the old one as it installs.

2024.01.24b Update Tailscale to 1.58.2

*facepalms* Give me a few minutes 😀

I took a look at this, and the problem that I saw in the first diagnostic was corrected (nginx wasn't listening on the Tailscale IP, it is now). As far as I can tell, everything looks normal. Can you get in via something other than your phone? Also, just as an FYI -- there's a known issue with mobile devices and the WebGUI, if you log in from a mobile device and forget to close the page, it can eventually crash the WebGUI.

2024.01.24 Update Tailscale to 1.58.1 Adds localization support If you'd like to help with translating the plugin, please visit https://crowdin.com/project/unraid-tailscale/

That was fast... give it about 5 minutes, if it's still not working run another diagnostic for me. The services can take a couple minutes to update configuration and restart.

I'd start by using the "Restart" button in Tailscale settings, that'll probably fix it for you.

Ultimately, my goal was to keep the localization files inside the repositories for the plugin; I have existing tools / workflows for localization projects which I'd like to keep using . Now I know that my original approach won't work as cleanly as I would have liked it to, but I have a plan B that will work nicely for me. Thanks for the info!

I've been working on adding localization to the Tailscale plugin, but ran across a weird behavior with Community Apps / language pack installation and would like to understand how to make this work best. Per the multi-language design guide, "The translation text file(s) which comes with a plugin needs to be manually stored in the corresponding language sub-directory." I know that some plugins have their translations included in the Unraid language pack itself, but I would prefer to keep translations in my repository. Based on the the design guide, I tried adding /usr/local/emhttp/languages/es_ES/tailscale.txt to my package. This works fine for loading the translations, but has a problematic side effect: it causes CA to believe that the entire language pack is installed (presumably CA is detecting the presence of the es_ES folder instead of the file in /boot/config/plugins). As a result, the language pack cannot be completely installed if a user wants to do to after installing the plugin. Are language packs guaranteed to install before plugins? If so, I could rely on detecting the presence of the language folders and only load my translation if it already exists. This creates a small sequencing bug (if someone installed the language pack after the plugin, the plugin translations wouldn't be loaded until after the next reboot), but that might be something I could live with. Alternately, I have a cron job that I could have "monitor" for language folders and copy the translations in, but that's a very ugly solution to the problem that I'd prefer not to use. Or is there another solution that I'm missing?

Note: Tailscale has paused distribution of 1.58.0, so I'm pausing updates to plugin version 2024.01.18. The issue appears to be that some NAT-PMP/UPnP responses can crash tailscaled. If you have already updated to that version, you don't need to do anything unless you're having issues with Tailscale crashing completely. If you have upgraded and encounter this problem, you should be able to roll back by uninstalling the Tailscale plugin and then reinstalling via community apps.

I actually had already added an orange warning banner to the plugin settings if NetBIOS is enabled (even before your post ). It'll go out in the next update.

The tailscale web interfaces (the pages with the "Viewing" button, etc.) are entirely contained within Tailscale, so if the "Viewing" button doesn't work right I can offer advice to help understand what's happening, but ultimately can't do much to fix it. You could try checking your Javascript console when you are loading the interface in Unraid to see if anything interesting shows up. I don't have a way to collect those logs since they're actually browser logs, not Unraid logs. If you can get to tailscaleip:5252 and that works, though, I probably wouldn't spend too much time worrying about it if I were you.

The routing entries for Tailscale don't appear in the route table that is shown in the WebGUI, they're in a separate table that you can view by running this in the CLI: ip route show table 52 However, in your case I don't think that's going to have the information that you're looking for. Your questions have been about advertising your Unraid server as an exit node / subnet router. You can do that by running this in the CLI: tailscale set --advertise-exit-node --advertise-routes=your.network.address.here/size The results of that won't show up in the local routing tables, but you should see the advertisements in your Tailscale admin console to approve.

@oxyg3n @VampyreVK @bmpreston @letum00 @adaughe2 I promise that I didn't forget about all of you, it's just been a busy week for me I looked through all of the logs, and there's nothing that immediately stands out to me as being a problem -- services are listening on the correct interfaces, etc. From everything I can see in the config files / logs, it seems like things should be working, but aren't. You could try following the steps that @Todo88 mentioned a few posts ago, that seems like a good start. If that doesn't work, I'm wondering if there might be some kind of routing problem that's manifesting in your setups. I noticed that all of the diagnostics show either (or both) of these things configured: "Use Tailscale Subnets" set to "Yes" Wireguard tunnels created with a default route For "Use Tailscale Subnets": this setting is very rarely required, but can be a bit confusing. "Use Tailscale Subnets" tells Unraid to follow routes advertised by other devices in the tailnet. It has no effect on advertising routes from Unraid. Unless you have some need for Unraid to initiate connections to other tailnet devices (e.g., backing up files to a remote server connected via Tailscale), you're better off turning this setting off. The other thing that might be useful is if someone could give me the output from this command in the Unraid console: ip route show table all That's not something that I currently collect in diagnostics, but might be helpful for figuring out what's happening (I will probably add this to the diagnostics in an upcoming update too).

Thanks for this info! Hopefully it will be of use to folks