3 hours ago, stridemat said:

 

Looks like the fix will be in the final build (it seems to be in rc7). 
 

Seems like a support headache though? 

I’ll need to look at this closer, but I expect that I’ll be able to make that simpler. 

I followed the instructions in the post, but did not add the script at the end and it survives a reboot just fine without the need to modify the go script.

EDIT: My interface name was "tailscale1", rather than 0 as in the instructions.

Edited June 8, 20233 yr by rogueosb

9 hours ago, rogueosb said:

I followed the instructions in the post, but did not add the script at the end and it survives a reboot just fine without the need to modify the go script.

EDIT: My interface name was "tailscale1", rather than 0 as in the instructions.

I'm glad to hear that.... means my job will hopefully be easy . There's probably a race condition related to when tailscale comes up vs. when ssh/nginx start, but I'll handle that in the startup script that Tailscale uses.

 

The plugin does use tailscale1 for the interface name... that helps when people accidentally install both the plugin and the docker container (docker creates tailscale0, so using tailscale1 avoids conflicts... you still can't run them together, but it makes fixing it easier).

Hi! I'm still trying to learn my way around Tailscale, and I'm trying to get the plugin to work correctly with my reverse proxy container.

 

I have a custom docker network which traefik and other app containers belong to. When I am connected to my LAN, I'm able to access the containers' web interfaces via my domain. When I am on an external network, none of the requests to my domain are being routed to the reverse proxy (no access logs on Traefik). I've already confirmed from my remote client that my DNS server correctly returns an A record with the Tailscale IP address of my unRAID server.

 

After browsing through this post, I wonder if the ability to listen in on interfaces would solve my problem.

Does anyone have any suggestions on what I might try to get this thing working?

2023.06.09

• Adds support for Unraid 6.12

This release adds a new setting to have Unraid services listen on the Tailscale interfaces (enabled by default). You don't need to do anything listed in the pre-release thread for 6.12rc7, the plugin handles all of it.

 

@Squid This resolves the compatibility issue with 6.12, you can remove that flag now.

Edited June 9, 20233 yr by EDACerton

My logs are full of this kind of line:

Jun 9 15:47:12 NAS tailscaled: 2023/06/09 15:47:07 wg: [rNaiD] - Failed to send handshake initiation: peer's node key has expired

all my devices on my tailscale network have valid key and my unRAID server has  Expiry disabled

what does these errors mean?

10 hours ago, EDACerton said:

@Squid This resolves the compatibility issue with 6.12, you can remove that flag now.

Done.  It'll take effect in ~1 hour

4 hours ago, milouz said:

My logs are full of this kind of line:

Jun 9 15:47:12 NAS tailscaled: 2023/06/09 15:47:07 wg: [rNaiD] - Failed to send handshake initiation: peer's node key has expired

all my devices on my tailscale network have valid key and my unRAID server has  Expiry disabled

what does these errors mean?

If all of your devices have a valid key, I’m not certain why you would get that message.

 

Feel free to post diagnostics and I’ll take a look at the logs. It seems like an internal Tailscale/Wireguard problem, though, so you might be better off posting over at Tailscale about it.

 

 

22 hours ago, JustMatt said:

Hi! I'm still trying to learn my way around Tailscale, and I'm trying to get the plugin to work correctly with my reverse proxy container.

 

I have a custom docker network which traefik and other app containers belong to. When I am connected to my LAN, I'm able to access the containers' web interfaces via my domain. When I am on an external network, none of the requests to my domain are being routed to the reverse proxy (no access logs on Traefik). I've already confirmed from my remote client that my DNS server correctly returns an A record with the Tailscale IP address of my unRAID server.

 

After browsing through this post, I wonder if the ability to listen in on interfaces would solve my problem.

Does anyone have any suggestions on what I might try to get this thing working?

The “listen on interface” changes wouldn’t help with this — that’s for Unraid services, not docker containers. 
 

Have you enabled “Host access to custom networks” in your docker settings?

3 hours ago, EDACerton said:

If all of your devices have a valid key, I’m not certain why you would get that message.

 

Feel free to post diagnostics and I’ll take a look at the logs. It seems like an internal Tailscale/Wireguard problem, though, so you might be better off posting over at Tailscale about it.

 

 

 

Thanks for your help.
I'll try to ask tailscale also.

nas-diagnostics-20230609-2323.zip

On 6/9/2023 at 5:27 PM, milouz said:

 

Thanks for your help.
I'll try to ask tailscale also.

nas-diagnostics-20230609-2323.zip 216.47 kB · 0 downloads

I took a look and didn't see anything that seems out of place. I recommend running a "tailscale bugreport" and provide the info from that to the folks over on the Tailscale side (that generates an identifier so they can check the logs).

2023.06.11a

• Increase delay when restarting Unraid services

My logs are littered with...

 

Jun 14 15:54:24 homegrown tailscaled: 2023/06/14 15:54:24 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:27 homegrown tailscaled: 2023/06/14 15:54:27 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:37 homegrown tailscaled: 2023/06/14 15:54:37 open-conn-track: timeout opening (TCP 100.71.223.5:47567 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:39 homegrown tailscaled: 2023/06/14 15:54:39 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:40 homegrown tailscaled: 2023/06/14 15:54:40 open-conn-track: timeout opening (TCP 100.71.223.5:47567 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:47 homegrown tailscaled: 2023/06/14 15:54:47 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:47 homegrown tailscaled: 2023/06/14 15:54:47 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node")
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node") (1 dropped)
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node

 

Everything seems to be working fine, but these lines are constantly repeating in the logs. Any insight?

1 hour ago, ramair02 said:

My logs are littered with...

 

Jun 14 15:54:24 homegrown tailscaled: 2023/06/14 15:54:24 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:27 homegrown tailscaled: 2023/06/14 15:54:27 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:37 homegrown tailscaled: 2023/06/14 15:54:37 open-conn-track: timeout opening (TCP 100.71.223.5:47567 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:39 homegrown tailscaled: 2023/06/14 15:54:39 open-conn-track: timeout opening (TCP 100.71.223.5:51675 => 172.64.96.12:443); no associated peer node
Jun 14 15:54:40 homegrown tailscaled: 2023/06/14 15:54:40 open-conn-track: timeout opening (TCP 100.71.223.5:47567 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:47 homegrown tailscaled: 2023/06/14 15:54:47 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:47 homegrown tailscaled: 2023/06/14 15:54:47 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node
Jun 14 15:54:50 homegrown tailscaled: 2023/06/14 15:54:50 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node")
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node") (1 dropped)
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 open-conn-track: timeout opening (TCP 100.71.223.5:54857 => 172.64.163.13:443); no associated peer node
Jun 14 15:55:02 homegrown tailscaled: 2023/06/14 15:55:02 open-conn-track: timeout opening (TCP 100.71.223.5:42959 => 45.154.253.8:80); no associated peer node

 

Everything seems to be working fine, but these lines are constantly repeating in the logs. Any insight?

I sent you a PM with some information... I think there is something else that is sending traffic places it shouldn't, which is why these error messages are ending up in the logs.

2 hours ago, EDACerton said:

I sent you a PM with some information... I think there is something else that is sending traffic places it shouldn't, which is why these error messages are ending up in the logs.

 

Thanks for the reply, EDACerton. I also saw your PM. I'm not sure what's going on -- everything I Google essentially says it is a bug with NetworkManager / ConnectivityCheck and doesn't affect the operation of Tailscale. However, it is annoying and I don't remember having this issue when I was using the Tailscale Docker Container. I'm not sure if the research I've done is related to the syslog being spammed with the above, but it's all I could find searching around.

 

https://github.com/tailscale/tailscale/issues/5175

https://forum.tailscale.com/t/ratelimit-format-open-conn-track-timeout-opening-v-no-associated-peer-node/1456/2

https://forum.tailscale.com/t/open-conn-track-timeout/2231

 

FWIW, unraid is setup as an exit node in Tailscale. I've also tested with Accept Routes on & off as well as Accept DNS on & off. Logs still get spammed with the same.

Edited June 15, 20233 yr by ramair02

On 6/14/2023 at 3:52 AM, EDACerton said:

2023.06.11a

• Increase delay when restarting Unraid services

Just wanted to let you know that this did not fix SSH for me, nor did the new stable Unraid release.

Were you able to reproduce this issue?

Hello

 

Just started using tailscale.  One problem I'm having is when I reboot my unraid server, tailscale status says "stopped" I then need to take off the plugin and reinstall.  Can anyone point me in the right direction?  I'm on the latest version as well as unrail 6.12.

 

Running: 

/etc/rc.d/rc.tailscale restart      

 

brings it back online.

 

Should i need to do this after every reboot?

 

Edited June 15, 20233 yr by Derek Watson

As of plugin version 2023.06.11a and/or 6.12.0-RC8/6.12.0, I'm encountering an issue where when I have the plugin installed, I'm unable to access any of my servers on their local IP (192.168.1.xxx) but am able to access them via their tailnet IP (100.xxx.xxx.xxx).

I'm going to do a bit more digging into what might be happening, but wanted to post a comment to see if this is an issue affecting more than myself.

 

EDIT:

I also noticed that when I uninstalled the plugin, I needed to toggle SSH in the "Management Access" section in Settings, or reboot to get SSH access to the server.

Edited June 15, 20233 yr by trevorstarick

9 minutes ago, ramair02 said:

 

Thanks for the reply, EDACerton. I also saw your PM. I'm not sure what's going on -- everything I Google essentially says it is a bug with NetworkManager / ConnectivityCheck and doesn't affect the operation of Tailscale. However, it is annoying and I don't remember having this issue when I was using the Tailscale Docker Container. I'm not sure if the research I've done is related to the syslog being spammed with the above, but it's all I could find searching around.

 

https://github.com/tailscale/tailscale/issues/5175

https://forum.tailscale.com/t/ratelimit-format-open-conn-track-timeout-opening-v-no-associated-peer-node/1456/2

https://forum.tailscale.com/t/open-conn-track-timeout/2231

 

FWIW, unraid is setup as an exit node in Tailscale. I've also tested with Accept Routes on & off as well as Accept DNS on & off. Logs still get spammed with the same.

The same thing may have still been happening with the docker container -- the difference is that the docker container tailscale logs are "hidden" within the container, while the plugin logs to syslog (making it more visible, e.g. in diagnostics).

 

In general, you're right that it doesn't affect the operation of Tailscale -- the messages are just Tailscale reporting that "something sent me traffic that I can't handle". The log spam is certainly annoying, though.

 

At some point, I'm going to do some overhaul work on the logging (which will at least help keep this from filling up syslog), but that's probably a few versions away.

41 minutes ago, trevorstarick said:

As of plugin version 2023.06.11a and/or 6.12.0-RC8/6.12.0, I'm encountering an issue where when I have the plugin installed, I'm unable to access any of my servers on their local IP (192.168.1.xxx) but am able to access them via their tailnet IP (100.xxx.xxx.xxx).

I'm going to do a bit more digging into what might be happening, but wanted to post a comment to see if this is an issue affecting more than myself.

 

EDIT:

I also noticed that when I uninstalled the plugin, I needed to toggle SSH in the "Management Access" section in Settings, or reboot to get SSH access to the server.

 

8 hours ago, Derek Watson said:

Hello

 

Just started using tailscale.  One problem I'm having is when I reboot my unraid server, tailscale status says "stopped" I then need to take off the plugin and reinstall.  Can anyone point me in the right direction?  I'm on the latest version as well as unrail 6.12.

 

Running: 

/etc/rc.d/rc.tailscale restart      

 

brings it back online.

 

Should i need to do this after every reboot?

 

 

11 hours ago, baujahr said:

Just wanted to let you know that this did not fix SSH for me, nor did the new stable Unraid release.

Were you able to reproduce this issue?

Please generate and post diagnostics.

Diagnostics attached - rebooted server tailscale service in a stopped state restarted with /etc/rc.d/rc.tailscale restart  hpgen8-diagnostics-20230616-1435.zip

1 hour ago, Derek Watson said:

Diagnostics attached - rebooted server tailscale service in a stopped state restarted with /etc/rc.d/rc.tailscale restart  hpgen8-diagnostics-20230616-1435.zip

Thanks for this. I can see the issue, should have a fix in the next release.

 

https://github.com/dkaser/unraid-tailscale/issues/54

2023.06.16a

• Fix notification when running on Unraid pre-6.12
• Wait for tailscaled to stop when restarting service

I don’t know if someone is like me. Using this plugin in unraid 6.12 will cause the SSH service to be closed after booting and cannot be opened

Just now, pteromyini said:

I don’t know if someone is like me. Using this plugin in unraid 6.12 will cause the SSH service to be closed after booting and cannot be opened

Can you please post diagnostics? I routinely use SSH.