On 11/6/2025 at 4:07 AM, Chengnan said:

curl -I login.tailscale.com

curl -I controlplane.tailscale.com

Both of these tell me, "failed to connect to login.tailscale.com port 80 after 9137ms: Could not connect to the server.

"

On 11/8/2025 at 4:44 PM, brian073 said:

Both of these tell me, "failed to connect to login.tailscale.com port 80 after 9137ms: Could not connect to the server.

"

I wonder if there is something in OPNSense blocking the server? I can't for the live of me find it.

Like somebody posted back in August, I'm also experiencing issues with tailscale losing connection after initial boot. After restarting the server it'll stay connected for a while and for some reason after a indeterminate amount of time it may lose connection with the tailscale service. If I load the plug-in settings page and wait, it will eventually load and show me unknown and error values. But if I restart it from this page, it will successfully reconnect and I will have access for another few hours until the connection drops again.

I did not have this issue until extremely recently, but it has started cropping up over the past few weeks, and impacting my ability to access my services outside of the home. I'm currently away from my home, or I would post my diagnostics, but I did go over them the other evening, and it doesn't show any obvious errors that I could identify.

Based on the number of users here that are reporting this, however, it seems like there's some kind of regression that's having an edge case interaction with the network. I advertise a subnet and I also host a pie hole on my network that runs my local DNS. Out of an abundance of caution, I removed the pihole DNS entry from Unraid gui and Unraid is using cloudflare and Google dns to make sure that it has a direct path to the tailscale domain without bringing the Pi hole into the equation.

I will share my diagnostic logs when I get home, but I am looking any input from someone who might have advice on what I can try. When within my local network I don't really notice any issues. The timing of this for me at least seems to correlate with tail scale adding the peer relay features and some of the other things from this year's fall update. And since I have tailscale installed as a sidecar for pihole, I was concerned that the server might be trying to relay to itself and getting caught in a loop.

Also of note, I can still access the dashboard and settings for my PI hole, which I have using its own container network and with its own tail scale daemon. So I know the network connection is up and I know that connection to tailscale from my home is possible. But specifically, the plug-in integration in the Unraid system is failing somehow.

7 hours ago, skywalker6705 said:

Like somebody posted back in August, I'm also experiencing issues with tailscale losing connection after initial boot. After restarting the server it'll stay connected for a while and for some reason after a indeterminate amount of time it may lose connection with the tailscale service. If I load the plug-in settings page and wait, it will eventually load and show me unknown and error values. But if I restart it from this page, it will successfully reconnect and I will have access for another few hours until the connection drops again.

I did not have this issue until extremely recently, but it has started cropping up over the past few weeks, and impacting my ability to access my services outside of the home. I'm currently away from my home, or I would post my diagnostics, but I did go over them the other evening, and it doesn't show any obvious errors that I could identify.

Based on the number of users here that are reporting this, however, it seems like there's some kind of regression that's having an edge case interaction with the network. I advertise a subnet and I also host a pie hole on my network that runs my local DNS. Out of an abundance of caution, I removed the pihole DNS entry from Unraid gui and Unraid is using cloudflare and Google dns to make sure that it has a direct path to the tailscale domain without bringing the Pi hole into the equation.

I will share my diagnostic logs when I get home, but I am looking any input from someone who might have advice on what I can try. When within my local network I don't really notice any issues. The timing of this for me at least seems to correlate with tail scale adding the peer relay features and some of the other things from this year's fall update. And since I have tailscale installed as a sidecar for pihole, I was concerned that the server might be trying to relay to itself and getting caught in a loop.

Sending logs via plugin diagnostics is best here... it's hard to guess what would cause that.

Since you mention subnet routes, one thing that I'll mention is to be careful with "Accept Routes" and "Accept DNS" on the server... those can both cause connectivity problems depending on how the network is set up. Neither is usually required (e.g., you can advertise routes without accepting them).

1 hour ago, EDACerton said:

Sending logs via plugin diagnostics is best here... it's hard to guess what would cause that.

Since you mention subnet routes, one thing that I'll mention is to be careful with "Accept Routes" and "Accept DNS" on the server... those can both cause connectivity problems depending on how the network is set up. Neither is usually required (e.g., you can advertise routes without accepting them).

This is good advice. I did check, and both of these are already off unfortunately.

It seems to me like the tailscaled daemon is crashing, but I don't know why. Restarting it fixes everything, but only for a while.
I don't see anything in the syslog about the tailscale service or daemon erroring out, but I might just be looking in the wrong place.

Diagnostics attached. Happy to investigate further if you think of an area I can poke around in.

Edited November 11, 2025Nov 11 by skywalker6705

2 minutes ago, skywalker6705 said:

This is good advice. I did check, and both of these are already off unfortunately.

It seems to me like the tailscaled daemon is crashing, but I don't know why. Restarting it fixes everything, but only for a while.
I don't see anything in the syslog about the tailscale service or daemon erroring out, but I might just be looking in the wrong place.

Diagnostics attached. Happy to investigate further if you think of an area I can poke around in.

diagnostics.zip

Please install "Plugin Diagnostics" from CA, and then either upload the Tailscale diagnostics, or download/post them here. Those include the Tailscale-specific logs/data that I need, it doesn't log to syslog (this is a good thing, it can make syslog hard to read :D ).

Thanks, diagnostics from the plugin are posted here. I'm seeing some nonsense but I haven't had enough time to parse it.

Diagnostics Upload ID: 1624c3db9182d251ca2bda81d8ebc132

Edit: Had a second occurrence, uploaded a second log.
Diagnostics Upload ID 2: 734eeefb4a1b6d7ea26af72667ea9a8c

Edited November 13, 2025Nov 13 by skywalker6705

On 11/10/2025 at 11:22 PM, skywalker6705 said:

Thanks, diagnostics from the plugin are posted here. I'm seeing some nonsense but I haven't had enough time to parse it.

Diagnostics Upload ID: 1624c3db9182d251ca2bda81d8ebc132

Edit: Had a second occurrence, uploaded a second log.
Diagnostics Upload ID 2: 734eeefb4a1b6d7ea26af72667ea9a8c

It looks like either something is blocking most (but maybe not all?) of the Tailscale control plane, which is causing it to have issues:

2025/11/12 04:59:40 trying bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" ...
2025/11/12 04:59:42 bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" error: Get "https://derp1g.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 209.aaa.aaa.120:443: connect: no route to host
2025/11/12 04:59:42 trying bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" ...
2025/11/12 04:59:42 bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" error: Get "https://derp8d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a03:b0c0:1:d0::e08:e001]:443: connect: network is unreachable
2025/11/12 04:59:42 trying bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" ...
2025/11/12 04:59:43 health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Chicago' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
2025/11/12 04:59:43 health: connectivity impacted; triggering captive portal detection
2025/11/12 04:59:43 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): context deadline exceeded
2025/11/12 04:59:43 health(warnable=no-derp-connection): ok
2025/11/12 04:59:45 bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" error: Get "https://derp8f.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded
2025/11/12 04:59:45 trying bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" ...
2025/11/12 04:59:45 bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" error: Get "https://derp7e.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2600:3c18::2000:60ff:fe0f:6e83]:443: connect: network is unreachable
2025/11/12 04:59:45 trying bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" ...
2025/11/12 04:59:46 netcheck: netcheck: UDP is blocked, trying HTTPS
2025/11/12 04:59:46 netcheck: UDP is blocked, trying ICMP
2025/11/12 04:59:47 derphttp.Client.Recv: connecting to derp-12 (ord)
2025/11/12 04:59:48 bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" error: Get "https://derp21c.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded
2025/11/12 04:59:48 trying bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" error: Get "https://derp28b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a01:4f9:c012:d55c::1]:443: connect: network is unreachable
2025/11/12 04:59:48 trying bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" error: Get "https://derp8b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 46.aaa.aaa.201:443: connect: no route to host
2025/11/12 04:59:48 trying bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" error: Get "https://derp21d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2607:f740:50::ca4]:443: connect: network is unreachable
2025/11/12 04:59:48 trying bootstrapDNS("derp4i.tailscale.com", "185.aaa.aaa.53") for "log.tailscale.com" ...
2025/11/12 04:59:51 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): dial tcp6 [2607:f740:e::4c8]:443: connect: network is unreachable
2025/11/12 04:59:51 health(warnable=no-derp-connection): ok

Lots of stuff like that, and other things that would suggest that you're getting out of sync with the control plane, similar to what's described here:

https://tailscale.com/kb/1091/what-happens-if-the-coordination-server-is-down

3 hours ago, EDACerton said:

It looks like either something is blocking most (but maybe not all?) of the Tailscale control plane, which is causing it to have issues:

2025/11/12 04:59:40 trying bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" ...
2025/11/12 04:59:42 bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" error: Get "https://derp1g.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 209.aaa.aaa.120:443: connect: no route to host
2025/11/12 04:59:42 trying bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" ...
2025/11/12 04:59:42 bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" error: Get "https://derp8d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a03:b0c0:1:d0::e08:e001]:443: connect: network is unreachable
2025/11/12 04:59:42 trying bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" ...
2025/11/12 04:59:43 health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Chicago' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
2025/11/12 04:59:43 health: connectivity impacted; triggering captive portal detection
2025/11/12 04:59:43 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): context deadline exceeded
2025/11/12 04:59:43 health(warnable=no-derp-connection): ok
2025/11/12 04:59:45 bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" error: Get "https://derp8f.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded
2025/11/12 04:59:45 trying bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" ...
2025/11/12 04:59:45 bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" error: Get "https://derp7e.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2600:3c18::2000:60ff:fe0f:6e83]:443: connect: network is unreachable
2025/11/12 04:59:45 trying bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" ...
2025/11/12 04:59:46 netcheck: netcheck: UDP is blocked, trying HTTPS
2025/11/12 04:59:46 netcheck: UDP is blocked, trying ICMP
2025/11/12 04:59:47 derphttp.Client.Recv: connecting to derp-12 (ord)
2025/11/12 04:59:48 bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" error: Get "https://derp21c.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded
2025/11/12 04:59:48 trying bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" error: Get "https://derp28b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a01:4f9:c012:d55c::1]:443: connect: network is unreachable
2025/11/12 04:59:48 trying bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" error: Get "https://derp8b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 46.aaa.aaa.201:443: connect: no route to host
2025/11/12 04:59:48 trying bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" ...
2025/11/12 04:59:48 bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" error: Get "https://derp21d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2607:f740:50::ca4]:443: connect: network is unreachable
2025/11/12 04:59:48 trying bootstrapDNS("derp4i.tailscale.com", "185.aaa.aaa.53") for "log.tailscale.com" ...
2025/11/12 04:59:51 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): dial tcp6 [2607:f740:e::4c8]:443: connect: network is unreachable
2025/11/12 04:59:51 health(warnable=no-derp-connection): ok

Lots of stuff like that, and other things that would suggest that you're getting out of sync with the control plane, similar to what's described here:

https://tailscale.com/kb/1091/what-happens-if-the-coordination-server-is-down

I'll have to keep monitoring it. I think given what you've shared, it may be an issue actually with some things on my ISP side recently. It works once I restart it, and it seems to have been working consistently for a little bit now. I want to see if there's a way for me to mirror the IPs into a Raspberry Pi Pi hole or something, so I have some fallback in case my ISP modem DNS doesn't properly identify these addresses.

Using the latest tailscale plugin on unraid 7.1.4, I can no longer access my NAS samba share from windows, I can ping the NAS, I can get into the web portal of Unraid using tailscale IP, but samba share is not accessable, with or without netbios enable. It seems port 445 is completely closed.

C:\Users\test >ping 100.aa.bb .77

Pinging 100.aa.bb.77 with 32 bytes of data:

Reply from 100.aa.bb.77: bytes=32 time=21ms TTL=64

Reply from 100.aa.bb.77: bytes=32 time=25ms TTL=64

C:\Users\test>telnet 100.aa.bb.77 445

Connecting To 100.aa.bb.77...Could not open connection to the host, on port 445: Connect failed

C:\Users\test >net use \\100.aa.bb.77\PCFileBackup /user:test "abcd1234"

System error 59 has occurred.

An unexpected network error occurred.

Please note that local Ip at port 445 works though

root@nas:~# telnet 10.0.1.249 445

Trying 10.0.1.249...

Connected to 10.0.1.249.

Escape character is '^]'.

^]

Just tailscale ip don't work

root@nas:~# telnet 100.aa.bb.77 445

Trying 100.aa.bb.77...

telnet: connect to address 100.aa.bb.77: Connection refused

The log show these

2025/11/19 10:35:05 open-conn-track: timeout opening (TCP 100.aa.bb.77:58871 => 37.19.5.139:6969); no associated peer node

2025/11/19 10:35:06 open-conn-track: timeout opening (TCP 100.aa.bb.77:59125 => 210.244.71.25:6969); no associated peer node

2025/11/19 10:35:06 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node")

2025/11/19 10:35:17 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node") (2 dropped)

2025/11/19 10:35:17 open-conn-track: timeout opening (TCP 100.aa.bb.77:43215 => 210.244.71.26:6969); no associated peer node

2025/11/19 10:35:17 open-conn-track: timeout opening (TCP 100.aa.bb.77:38011 => 173.254.204.71:1096); no associated peer node

2025/11/19 10:35:17 [RATELIMIT] format("open-conn-track: timeout opening %v; no associated peer node")

Edited November 19, 2025Nov 19 by SDUGoten

Edit: Downgraded to 7.2.0 seemed to fix the problem. I have Diagnostics before and after if anybody wants them. Two for Unraid Diagnostic and two for tailscale. before-after.zip

---

I just updated to Unraid 7.2.1 and before this i updated all plugins.

After the reboot i am seeing the same pattern.

I have my Plex and Overseer routed via tailscale to a VPS behind nginx proxy manager.

Uptime Kuma reports a pattern of up/down/up/down

Attached Plugin Diagnostics and Uptime Kuma Logs.

Tailscale Plugin Version 2025.11.20.0009

---

Status	DateTime	Message
Up	2025-11-20 23:23:08	200 - OK, keyword is found
Down	2025-11-20 23:15:08	timeout of 48000ms exceeded
Up	2025-11-20 23:04:08	200 - OK, keyword is found
Down	2025-11-20 23:00:08	timeout of 48000ms exceeded
Up	2025-11-20 22:53:08	200 - OK, keyword is found
Down	2025-11-20 22:49:08	timeout of 48000ms exceeded
Up	2025-11-20 22:41:08	200 - OK, keyword is found
Down	2025-11-20 22:34:08	timeout of 48000ms exceeded
Up	2025-11-20 22:23:08	200 - OK, keyword is found
Down	2025-11-20 22:22:08	timeout of 48000ms exceeded
Up	2025-11-20 22:12:08	200 - OK, keyword is found
Down	2025-11-20 21:57:08	Request failed with status code 502
Up	2025-11-17 03:21:51	200 - OK, keyword is found
Down	2025-11-17 03:18:51	timeout of 48000ms exceeded

bespin-tailscale-diag-20251120-232338.zip

tailscale diagnostics

root@bespin:~# tailscale version
1.90.8
tailscale commit: edc9d22455eb839bd411d1b0555da979d1fb4d75
long version: 1.90.8-tedc9d2245-ged5c52ee2
other commit: ed5c52ee2e5854e3bf8c3c06229198b17f0d3a77
go version: go1.25.3
root@bespin:~# tailscale status --peers=false
100.99.xx.xx bespin userid:1827769xxxxx linux idle; offers exit node
# Health check:
# - Some peers are advertising routes but --accept-routes is false
root@bespin:~# tailscale netcheck
2025/11/20 23:42:02 portmap: monitor: gateway and self IP changed: gw=10.10.10.1 self=10.10.10.108
Report:
* Time: 2025-11-20T22:42:03.19073032Z
* UDP: true
* IPv4: yes, 87.1xxxxx:42740
* IPv6: no, but OS has support
* MappingVariesByDestIP: false
* PortMapping:
* Nearest DERP: Amsterdam
* DERP latency:
- ams: 27.7ms (Amsterdam)
- fra: 28.6ms (Frankfurt)
- par: 32.4ms (Paris)
- nue: 34.1ms (Nuremberg)
- lhr: 37ms (London)
- waw: 42.2ms (Warsaw)
- mad: 45.3ms (Madrid)
- hel: 45.9ms (Helsinki)
- nyc: 101.5ms (New York City)
- iad: 107.6ms (Ashburn)
- tor: 114.5ms (Toronto)
- ord: 121.4ms (Chicago)
- mia: 127.9ms (Miami)
- den: 146ms (Denver)
- dfw: 157.1ms (Dallas)
- sfo: 163.8ms (San Francisco)
- lax: 173.3ms (Los Angeles)
- sea: 174.3ms (Seattle)
- hnl: 217.2ms (Honolulu)
- sao: 251.3ms (São Paulo)
- sin: (Singapore)
- syd: (Sydney)
- blr: (Bangalore)
- tok: (Tokyo)
- jnb: (Johannesburg)
- hkg: (Hong Kong)
- dbi: (Dubai)
- nai: (Nairobi)

root@bespin:~# # And again during a downtime with a ping to the VPS tailscale IP
root@bespin:~# tailscale netcheck
2025/11/20 23:53:19 portmap: monitor: gateway and self IP changed: gw=10.10.10.1 self=10.10.10.108

Report:
        * Time: 2025-11-20T22:53:20.213748272Z
        * UDP: true
        * IPv4: yes, 87.xxx.xxx.xxx:46833
        * IPv6: no, but OS has support
        * MappingVariesByDestIP: false
        * PortMapping: 
        * Nearest DERP: Nuremberg
        * DERP latency:
                - nue: 19ms    (Nuremberg)
                - fra: 24ms    (Frankfurt)
                - ams: 28.2ms  (Amsterdam)
                - waw: 33.7ms  (Warsaw)
                - par: 34ms    (Paris)
                - lhr: 35.2ms  (London)
                - mad: 48ms    (Madrid)
                - hel: 51ms    (Helsinki)
                - nyc: 99.5ms  (New York City)
                - iad: 107.7ms (Ashburn)
                - tor: 113.3ms (Toronto)
                - ord: 125.2ms (Chicago)
                - mia: 139.7ms (Miami)
                - den: 140.8ms (Denver)
                - dfw: 149.6ms (Dallas)
                - sfo: 167.2ms (San Francisco)
                - lax: 168.2ms (Los Angeles)
                - sea: 172.8ms (Seattle)
                - hnl: 210.3ms (Honolulu)
                - sao: 249.4ms (São Paulo)
                - sin:         (Singapore)
                - syd:         (Sydney)
                - blr:         (Bangalore)
                - tok:         (Tokyo)
                - jnb:         (Johannesburg)
                - hkg:         (Hong Kong)
                - dbi:         (Dubai)
                - nai:         (Nairobi)
root@bespin:~# ping 100.85.xx.xx
PING 100.85.71.13 (100.85.xx.xx) 56(84) bytes of data.
^C
--- 100.85.xx.xx ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4135ms 

Edited November 20, 2025Nov 20 by flipp

On 8/6/2025 at 3:24 PM, brecon1 said:

Within the past handful of days my funnel won't stay active. In the CLI I start it and 'status' says it's running then about 10 seconds later if I 'status' it again it says "No serve config". I've uninstalled and reinstalled but no change. In the plugin's log it says: "Tailscale funnel is enabled, but config does not allow it, resetting serve config". Nothing has changed that I know of otherwise. Thoughts? Thank you in advance!!!!

EDIT: Also my Node Attributes are the defaults, enabled funnels.

I am also having the same issue on 7.1.2.

The "fix" I've had is to leave a terminal window open after the command has been run. If I try to run with the --bg flag, the funnel goes down within seconds, but this is obviously not ideal and the terminal window either closes itself eventually or I restart, shut down, or put the computer I am accessing from to sleep.

Should upgrading to 7.2 resolve this problem?

Edited December 4, 2025Dec 4 by taaaylo

Tailscale plugin is acting up on Unraid 7.1.4.
Through Tailscale I can access the web UI and applications in containers, but there is no internet inside the containers themselves. For example, as soon as Tailscale is enabled, monitoring in Uptime Kuma starts timing out.
I also noticed that there is no internet on the Apps/Community Applications repository page.

On 12/4/2025 at 8:15 AM, taaaylo said:

I am also having the same issue on 7.1.2.

The "fix" I've had is to leave a terminal window open after the command has been run. If I try to run with the --bg flag, the funnel goes down within seconds, but this is obviously not ideal and the terminal window either closes itself eventually or I restart, shut down, or put the computer I am accessing from to sleep.

Should upgrading to 7.2 resolve this problem?

I've found a way around this issue.

Seems to stem from the unRAID gui and Tailscale both utilizing port 443.

Updated to 7.2.2 and attempted to enable the funnel and then try again, but no luck. I didn't really feel comfortable moving the unRAID gui off of 443, so I eliminated that from a list of options. I tried several configurations to allow Tailscale to avoid the use of 443, but also no go.

I'm not completely sure what the correct and proper answer is, but I utilized nohup since leaving the terminal up allowed the funnel to persist.

Would love a proper answer on this as it is currently my only way past CGNAT.

Bonus: if someone could explain to me if using funnel on my OPNsense router and somehow routing the traffic through my tailnet to unRAID/Plex is possible/viable, I'm all ears. I like the idea of moving these types of services OFF of my server.

Edited December 5, 2025Dec 5 by taaaylo

On 12/4/2025 at 9:15 AM, taaaylo said:

I am also having the same issue on 7.1.2.

The "fix" I've had is to leave a terminal window open after the command has been run. If I try to run with the --bg flag, the funnel goes down within seconds, but this is obviously not ideal and the terminal window either closes itself eventually or I restart, shut down, or put the computer I am accessing from to sleep.

Should upgrading to 7.2 resolve this problem?

This is happening because you're creating a port conflict between Serve/Funnel and the WebGUI. This works OK at first, but eventually causes the WebGUI to break. You need to pick a different port for either one or the other.

(Also, you should have a notification in the WebGUI that the config was reset -- this is the plugin protecting you from yourself :) )

This was strange because I had no issues previously with running this exact command tailscale funnel 32400 and was never given a notification in the webGUI about a conflict or a config reset because of it. I guess it was the result of a new tailscale version along with updating the plugin.

Sat down and spent some time reading through the --help and new syntax. Didn't realize that tailscale was defaulting to 443 (or that there was a conflict issue until this problem presented itself) as the initial indications was that the funnel was disabled without any other notifications (until I was able to replicate the issue and generate the webGUI alert). Also wasn't quite understanding how to switch the port tailscale was using because of the new funnel syntax.

Long story short, for anyone having this particular issue, running tailscale --bg --https 8443 127.0.0.1:32400 is the command I was looking for to avoid the unRAID port conflict and resolve the problem.

Pretty annoying, but I guess I learned a little bit from it.

Edited December 7, 2025Dec 7 by taaaylo

I'm having the same issue @skywalker6705 reported a month ago.

The Tailscale plugin has worked perfectly fine until very recently. Stopped working twice now within three weeks or so. Only difference is my Tailscale does not drop the connection after a couple of hours again, it usually works fine for at least a week and then randomly stops working again.

If I access my server via local IP I can see the Tailscale plugin only reporting "Unknown" and when I try to load the plugin settings page it just keeps loading forever. Reboot fixes the problem and Tailscale is up for another 7-14 days again. I have now installed the Plugin Diagnostics as suggested above, obviously cannot contribute any logs as of right now before it happens again but just wanted to let you know.

On 11/10/2025 at 8:53 PM, skywalker6705 said:

Like somebody posted back in August, I'm also experiencing issues with tailscale losing connection after initial boot. After restarting the server it'll stay connected for a while and for some reason after a indeterminate amount of time it may lose connection with the tailscale service. If I load the plug-in settings page and wait, it will eventually load and show me unknown and error values. But if I restart it from this page, it will successfully reconnect and I will have access for another few hours until the connection drops again.

I did not have this issue until extremely recently, but it has started cropping up over the past few weeks, and impacting my ability to access my services outside of the home. I'm currently away from my home, or I would post my diagnostics, but I did go over them the other evening, and it doesn't show any obvious errors that I could identify.

Based on the number of users here that are reporting this, however, it seems like there's some kind of regression that's having an edge case interaction with the network. I advertise a subnet and I also host a pie hole on my network that runs my local DNS. Out of an abundance of caution, I removed the pihole DNS entry from Unraid gui and Unraid is using cloudflare and Google dns to make sure that it has a direct path to the tailscale domain without bringing the Pi hole into the equation.

I will share my diagnostic logs when I get home, but I am looking any input from someone who might have advice on what I can try. When within my local network I don't really notice any issues. The timing of this for me at least seems to correlate with tail scale adding the peer relay features and some of the other things from this year's fall update. And since I have tailscale installed as a sidecar for pihole, I was concerned that the server might be trying to relay to itself and getting caught in a loop.

I am also currently experiencing this issue, Please confirm if you found a fix.

t started happening after upgrading to7.2.2

On 12/5/2025 at 4:02 PM, RAMMs said:

Tailscale plugin is acting up on Unraid 7.1.4.
Through Tailscale I can access the web UI and applications in containers, but there is no internet inside the containers themselves. For example, as soon as Tailscale is enabled, monitoring in Uptime Kuma starts timing out.
I also noticed that there is no internet on the Apps/Community Applications repository page.

still need help

4 hours ago, RAMMs said:

still need help

Usually this is related to enabling “Accept DNS”. Otherwise, please provide plugin diagnostics.

On 12/11/2025 at 12:29 PM, Zak501 said:

I am also currently experiencing this issue, Please confirm if you found a fix.

t started happening after upgrading to7.2.2

Please provide plugin diagnostics.

I am curious whether it is possible to connect two Unraid servers in different locations over Tailscale. And then access their respective arrays inside their dockers (docker in unraid server a accesses docker of unraid server b). This would require me to mount the unraid a array in unraid b?

On 12/11/2025 at 11:29 AM, Zak501 said:

I am also currently experiencing this issue, Please confirm if you found a fix.

t started happening after upgrading to7.2.2

Hi, I'll share what I did so I hope it helps. One step I took was to remove my custom DNS from the loop to simplify troubleshooting, and have Unraid connect direct to a known good external DNS to resolve tailscale control plane addresses. This was essential because near as I can tell, the issue in my case turned out to be something in my local dns either on the router level or in my cached IPs in pihole expiring. I refreshed my pihole and cleared my caches, restarted my whole network, and on the Unraid side set the system DNS to use a specific IP outside my network (1.1.1.1) and I did a full safe shutdown and reboot so the system would drop anything in the cached memory. After all of the above, I've seen the issue go away.

I use Pihole on my network devices still, and my home router uses it to resolve addresses, so only Unraid OS itself uses a non-filtered DNS, which works fine for me for now. Anything not on "Host" network will be filtered as before, which is like 99% of my containers. I suspect this was an issue with dns propagation within my network falling out of step with the tailscale control plane. Somewhere in my network it was being cached, and remained out of date. But I can't say for sure.

I realize that is vague, but I do hope it helps in your diagnosis. 1. Known good and up to date DNS 2. Clear caches 3. Removing any ad-blocking or filtering from the loop.

Best of luck.

Edited December 17, 2025Dec 17 by skywalker6705

Hi,

I've been having problems with the Tailscale plugin for a while now. I don't remember when it first happened, but I'm sure the tailscale plugin updated at least 1 time.

I'll try to explain as best I can.

I've been using the Tailscale plugin for years to connect to the server when I'm away from home.

I also installed the Docker version as a backup, but it's never turned on, only installed.

A few months ago, the developer changed the access methods for vaultwarden (Docker), which now requires an HTTPS connection to work.

I then activated magicDNS and the HTTPS certificate in the admin console of tailscale.

I configured Tailscale for HTTPS access as follows:

tailscale serve --bg --https=4744 localhost:4743

If I run the command: "tailscale serve status":

https://pixelnas.tailf****.ts.net:4744 (tailnet only)

|-- / proxy http://localhost:4743

About a month after making this change (without any problems or further changes to any configuration), my power went out. I have a UPS, and the server shut down normally.

When I turned it back on, I couldn't access the WEB GUI (ERR_CONNECTION_REFUSED).

The only way I can access the WEB GUI is to log in via SSH, perform a "tailscale down" and then a "/etc/rc.d/rc.nginx start".

If tailscale is "up", after a few minutes, the GUI shuts down, and trying "/etc/rc.d/rc.nginx start" again it fails.

I solved the problem by deleting the snippet showing the tailscale status from the dashboard.

A few days ago, I had to restart the server again.

Now the problem has returned: if tailscale is up, after a while the GUI forcefully terminates.

If I try to start the GUI with tailscale up, it fails:

root@PixelNAS:~# tailscale up

root@PixelNAS:~# /etc/rc.d/rc.nginx start

rc.nginx: Starting Nginx server daemon...

Starting Unraid API service...

Starting flash backup service...

Starting the Unraid API

[PM2][WARN] Applications unraid-api not running, starting...

[PM2][WARN] App unraid-api has option 'wait_ready' set, waiting for app to be ready...

[PM2] App [unraid-api] launched (1 instances)

+--- unraid-api

namespace : default

version : 4.28.2+d13a1f61

pid : 2146051

pm2 id : 0

status : online

mode : fork

restarted : 0

uptime : 2s

memory usage : 229.9mb

error log : /var/log/graphql-api.log

watching : no

PID file : /var/log/.pm2/pids/unraid-api-0.pid

Starting nchan processes...

rc.nginx: Nginx server daemon... Failed.

If I stop tailscale (tailscale down), the command reactivates the GUI and stay UP.

I don't know what else to try to fix the problem.

Thanks

pixelnas-diagnostics-20251219-1014.zip