Quick question about this great plugin!

I am able to connect directly when outside my network to devices inside my network, including unRAID.

However I have a Jellyfin docker that I cannot reach directly. It always ends up in RELAY mode via its Tailscale IP.

I can access unRAID through a Direct Connection. Guessing I messed something up with my config.

 

Jellyfin docker has Tailscale Enabled. Tailscale shows on the Docker Advanced view, and the device is visible in Tailscale Machines.

 

unRAID host is exposing its IP for subnet routing in the form x.x.x.x/32 - this has been approved in Tailscale web interface.

 

Is there something I need to do (or change) to allow the Jellyfin docker to accept Direct Connections?

Thanks

 

58 minutes ago, MediaMaan said:

Jellyfin docker has Tailscale

 

This thread is about the plugin and the sticky says specifically that docker integration issues need to be posted elsewhere.

 

That said, try disabling the docker integration. IMO, it's not needed.

I also wouldn't consider any form of outside access, even with Tailscale without also running my own DNS resolver and reverse proxy, which makes it much simpler to access everything by FQDN. Any container I access from outside (and everything with a WebUI in general) also runs on a custom br0 network with its own IP address inside my /23 LAN range.

 

 

Edited April 14, 20251 yr by Espressomatic

1 hour ago, Espressomatic said:

 

This thread is about the plugin and the sticky says specifically that docker integration issues need to be posted elsewhere.

 

That said, try disabling the docker integration. IMO, it's not needed.

I also wouldn't consider any form of outside access, even with Tailscale without also running my own DNS resolver and reverse proxy, which makes it much simpler to access everything by FQDN. Any container I access from outside (and everything with a WebUI in general) also runs on a custom br0 network with its own IP address inside my /23 LAN range.

 

 

Thanks for your replay @Espressomatic. I am using the Tailscale Plugin. I thought the sticky was referring to the Tailscale Docker, which I am not using. Apologies for posting in the wrong section. Unfortunately the sticky only mentions "Please make a post in the appropriate OS support forum". unRAID is my OS. What is the OS support forum I am requested to post in? I'll happily go there to ask my Jellyfin Docker integration questions.

I thought exposing only the Jellyfin Docker to other users over the Tailscale integration was a secure method of sharing. I do not other users having access to any other part of the unRAID machine. Accessing the Jellyfin container is all those users will be permitted to do. Sure - I can access directly using the unRAID IP, but I will not be revealing that IP to other users.

I am by no means a networking expert, just trying to make use of the functionality offered by the plugin. Which seems a lot simpler, and more secure, than allowing outside access by other means. At least for a less experienced user. But I'm happy to be pointed in a direction that makes better sense from a security standpoint, and that has easy-to-follow directions that would let me accomplish the same thing.

3 hours ago, MediaMaan said:

Thanks for your replay @Espressomatic. I am using the Tailscale Plugin. I thought the sticky was referring to the Tailscale Docker, which I am not using. Apologies for posting in the wrong section. Unfortunately the sticky only mentions "Please make a post in the appropriate OS support forum". unRAID is my OS. What is the OS support forum I am requested to post in? I'll happily go there to ask my Jellyfin Docker integration questions.

I thought exposing only the Jellyfin Docker to other users over the Tailscale integration was a secure method of sharing. I do not other users having access to any other part of the unRAID machine. Accessing the Jellyfin container is all those users will be permitted to do. Sure - I can access directly using the unRAID IP, but I will not be revealing that IP to other users.

I am by no means a networking expert, just trying to make use of the functionality offered by the plugin. Which seems a lot simpler, and more secure, than allowing outside access by other means. At least for a less experienced user. But I'm happy to be pointed in a direction that makes better sense from a security standpoint, and that has easy-to-follow directions that would let me accomplish the same thing.

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.

 

Quote

Clearly this was all working before you installed the Tailscale plugin right?

Correct

 

 

Quote

On the Unraid system, in Settings -> Management Access, are all the expected URLs included in the "Local access URLs" section?

 

Quote

And for one last sanity check, in Network Settings, something like this (with Bridging enabled and the primary interface bridged to Br0)

 

 

Both Management access and Network settings remain unchanged when I turn off Tailscale.

 

Quote

 

Can you open a terminal/control panel on each machine and check this out specifically? Check current IP, gateway/router and DNS (even though DNS isn't required for IP or mDNS connections)

 

Unraid:

root@[REDACTED]:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq master bond0 state UP group default qlen 1000
    link/ether 9c:6b:00:12:1c:0c brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether 9c:6b:00:12:1c:0c brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:6b:00:12:1c:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.9/24 brd 192.168.2.255 scope global dynamic noprefixroute br0
       valid_lft 46469sec preferred_lft 35669sec
[REDACTED]
67: tailscale1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq state UNKNOWN group default qlen 500
    link/none 
    inet [REDACTED]/32 scope global tailscale1
       valid_lft forever preferred_lft forever
    inet6 [REDACTED]/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 [REDACTED]/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever
[REDACTED]
root@[REDACTED]:~# ip route
default via 192.168.2.254 dev br0 proto dhcp src 192.168.2.9 metric 1005 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev br-45768f7136a9 proto kernel scope link src 172.18.0.1 linkdown 
172.19.0.0/16 dev br-24e2ea19d2ed proto kernel scope link src 172.19.0.1 linkdown 
192.168.2.0/24 dev br0 proto dhcp scope link src 192.168.2.9 metric 1005 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
root@[REDACTED]:~# cat /etc/resolv.conf
# Generated by dhcpcd from br0.dhcp
domain home
nameserver 192.168.2.254
root@[REDACTED]:~# 

 

Windows 11 PC

C:\Users\[REDACTED]>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : [REDACTED]
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : [REDACTED].ts.net
                                       home

Unknown adapter Eddie:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : WireGuard Tunnel
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd7d:76ee:e68f:a993:165c:4222:93b2:f69c(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.185.109.78(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : fd7d:76ee:e68f:a993::1
                                       10.128.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Unknown adapter Tailscale:

   Connection-specific DNS Suffix  . : [REDACTED].ts.net
   Description . . . . . . . . . . . : Tailscale Tunnel
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : [REDACTED](Preferred)
   Link-local IPv6 Address . . . . . : [REDACTED](Preferred)
   IPv4 Address. . . . . . . . . . . : [REDACTED](Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Disabled
   Connection-specific DNS Suffix Search List :
                                       [REDACTED].ts.net

Ethernet adapter Ethernet 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Intel(R) Ethernet Controller (3) I225-V #2
   Physical Address. . . . . . . . . : D8-BB-C1-96-CB-F7
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Intel(R) Ethernet Controller (3) I225-V
   Physical Address. . . . . . . . . : D8-BB-C1-96-CB-F6
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2a02:a459:9298:0:1b16:e70e:5582:dd07(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:a459:9298:1:c562:4e54:72fe:123(Preferred)
   IPv6 Address. . . . . . . . . . . : fd5a:5445:4547:0:aa5f:1bc:6684:80c9(Preferred)
   Temporary IPv6 Address. . . . . . : 2a02:a459:9298:0:382e:e578:6923:b22e(Preferred)
   Temporary IPv6 Address. . . . . . : 2a02:a459:9298:1:382e:e578:6923:b22e(Preferred)
   Temporary IPv6 Address. . . . . . : fd5a:5445:4547:0:382e:e578:6923:b22e(Preferred)
   Link-local IPv6 Address . . . . . : fe80::6a1e:c2bc:5713:c092%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 15 April, 2025 08:25:48
   Lease Expires . . . . . . . . . . : 16 April, 2025 08:25:48
   Default Gateway . . . . . . . . . : 192.168.2.254
   DHCP Server . . . . . . . . . . . : 192.168.2.254
   DHCPv6 IAID . . . . . . . . . . . : 114867137
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2D-E0-93-85-D8-BB-C1-96-CB-F6
   DNS Servers . . . . . . . . . . . : fd7d:76ee:e68f:a993::1
                                       10.128.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       home

Wireless LAN adapter Wi-Fi:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6E AX211 160MHz
   Physical Address. . . . . . . . . : 60-DD-8E-0F-11-76
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 9:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physical Address. . . . . . . . . : 60-DD-8E-0F-11-77
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 10:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
   Physical Address. . . . . . . . . : 62-DD-8E-0F-11-76
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:284a:364:107d:e8:2a67:4419(Preferred)
   Link-local IPv6 Address . . . . . : fe80::107d:e8:2a67:4419%15(Preferred)
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 251658240
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2D-E0-93-85-D8-BB-C1-96-CB-F6
   NetBIOS over Tcpip. . . . . . . . : Disabled

C:\Users\[REDACTED]>

Does anything seem off?

 

Quote

What happens when after turning it OFF you also uninstall the plugin?

 

When I turn Tailscale off, login on my phone and uninstall the Tailscale plugin there, I still can't connect to unraid using my PC. When I then reinstall it, Tailscale is still turned off and still can't connect on my PC, obviously. I re-enable it then on my phone, and I can connect to unraid again on my PC.

Edited April 15, 20251 yr by PaulieW

16 hours ago, MediaMaan said:

I thought exposing only the Jellyfin Docker to other users over the Tailscale integration was a secure method of sharing.

 

1. Edit your Jellyfin Docker Container settings
2. Set its Network Type to: Custom br0
3. Give it a non-conflicting IP address within your usable range (make sure it's outside the DHCP range)
4. DISABLE Use Tailscale

 

You should be good to go now. Do the above for any/all containers you want anyone to access from outside your LAN - they'll need Tailscale on their device(s) and need to be part of your Tailnet.

 

IMO, never use the Tailscale option in a container's docker settings for any container or for any reason.

 

 

Edited April 15, 20251 yr by Espressomatic

6 hours ago, PaulieW said:

When I turn Tailscale off, login on my phone and uninstall the Tailscale plugin there, I still can't connect to unraid using my PC. When I then reinstall it, Tailscale is still turned off and still can't connect on my PC, obviously. I re-enable it then on my phone, and I can connect to unraid again on my PC.

 

I see a few things which stick out to me as "odd" in what you posted in the reply, but I'm going to let EDA look over it as my knowledge is like a grain of sand compared to his beach.

 

But, this part that I quoted here confirms that you can continue to access your Unraid system from your phone, right? That ties into the oddities I mentioned - the issue looks like it's specifically with the settings on your Windows machine, not Tailscale on Unraid.

 

 

13 minutes ago, Espressomatic said:

 

But, this part that I quoted here confirms that you can continue to access your Unraid system from your phone, right? That ties into the oddities I mentioned - the issue looks like it's specifically with the settings on your Windows machine, not Tailscale on Unraid.

Correct, so yea this definitely seems like a Windows problem. Let's see if EDA has something to add. Thank you for your help.

 

I might as well mention what I find odd: any mention of 10.*.*.* IP ranges, including DNS of 10.128.0.1 for your ethernet adapter.

 

Your wireguard interface is also on a different 10.185.*.* subnet

 

If that's what your Windows machine is using all the time, you won't be able to reach anything on 192.168.2.* right?

 

All my systems are on a consistent subnet whether Tailscale is or isn't being used, including the same DNS. So systems can always resolve IPs and connect to each other by name or direct IP.

 

 

 

Edited April 15, 20251 yr by Espressomatic

6 hours ago, Espressomatic said:

I might as well mention what I find odd: any mention of 10.*.*.* IP ranges, including DNS of 10.128.0.1 for your ethernet adapter.

 

Your wireguard interface is also on a different 10.185.*.* subnet

 

If that's what your Windows machine is using all the time, you won't be able to reach anything on 192.168.2.* right?

Wireguard's IPv4 is 10.185.*.* apparently, what's the problem with that?

 

When I turn off wireguard the behaviour is the same; can't connect to 192.168.2.9 when I disable Tailscale, when I re-enable I can connect to it. So I don't think the wireguard interface is the problem.

 

Edited April 15, 20251 yr by PaulieW

2 hours ago, PaulieW said:

Wireguard's IPv4 is 10.185.*.* apparently, what's the problem with that?

 

When I turn off wireguard the behaviour is the same; can't connect to 192.168.2.9 when I disable Tailscale, when I re-enable I can connect to it. So I don't think the wireguard interface is the problem.

 

 

Worth a try: Disable all VPN/tunnels on your PC. There should then be no reason you can't connect to your Unraid system.

 

If your PC is still using some tunnel to some server or control plane - how is it going to connect to anything on the rest of your LAN that isn't also set up for that?

 

 

Edited April 15, 20251 yr by Espressomatic

22 hours ago, Espressomatic said:

 

Worth a try: Disable all VPN/tunnels on your PC. There should then be no reason you can't connect to your Unraid system.

 

If your PC is still using some tunnel to some server or control plane - how is it going to connect to anything on the rest of your LAN that isn't also set up for that?

 

 

With Tailscale enabled, and I run "route print" in cmd on my Windows PC I see this:

C:\Users\[REDACTED]>route print
===========================================================================
Interface List
  8...........................Tailscale Tunnel
  7...d8 bb c1 96 cb f7 ......Intel(R) Ethernet Controller (3) I225-V #2
 11...d8 bb c1 96 cb f6 ......Intel(R) Ethernet Controller (3) I225-V
 17...60 dd 8e 0f 11 76 ......Intel(R) Wi-Fi 6E AX211 160MHz
 14...60 dd 8e 0f 11 77 ......Microsoft Wi-Fi Direct Virtual Adapter
 21...62 dd 8e 0f 11 76 ......Microsoft Wi-Fi Direct Virtual Adapter #2
  1...........................Software Loopback Interface 1
 15...00 00 00 00 00 00 00 e0 Microsoft Teredo Tunneling Adapter
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.2.254     192.168.2.13     25
    100.79.[REDACTED]  255.255.255.255         On-link      100.93.[REDACTED]      5
     100.93.[REDACTED]  255.255.255.255         On-link      100.93.[REDACTED]    261
    100.99.[REDACTED]  255.255.255.255         On-link      100.93.[REDACTED]      5
  100.100.100.100  255.255.255.255         On-link      100.93.[REDACTED]      5
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.2.0    255.255.255.0         On-link      192.168.2.13    281
      192.168.2.0    255.255.255.0  100.100.100.100     100.93.[REDACTED]      5
     192.168.2.13  255.255.255.255         On-link      192.168.2.13    281
    192.168.2.255  255.255.255.255         On-link      192.168.2.13    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.2.13    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.2.13    281
===========================================================================

 

These two lines I think that are of interest:

      192.168.2.0    255.255.255.0         On-link      192.168.2.13    281
      192.168.2.0    255.255.255.0  100.100.100.100     100.93.[REDACTED]      5

 

Do I understand correctly that Windows currently redirects all connections on 192.168.2.0/24 to the tailscale network over the on-link one, because it has a lower metric value of 5 compared to the on-link one of 281? If I increase the metric from 5 to 300, would the PC then always take the on-link route? I'm a bit cautious to mess around with this.

 

Curious to see what other people have in their output when they run "route print" and whether my setup differs a lot or not.

Edited April 16, 20251 yr by PaulieW

I'm not sure why you're messing around with routing nor why any of the private IPs are being redacted.

 

If you have to change any routing options, then there's a failure somewhere (else) and you need to start over. None of that is necessary to look at or change.

10 hours ago, Espressomatic said:

I'm not sure why you're messing around with routing nor why any of the private IPs are being redacted.

 

If you have to change any routing options, then there's a failure somewhere (else) and you need to start over. None of that is necessary to look at or change.

You were correct not to mess around in routing tables.

 

I tried uninstalling Tailscale on Windows, and after I had done that, I could enable/disable Tailscale on unraid and I would still connect to it on my PC using 192.168.2.9. So that confirms it was a Tailscale-on-Windows issue.

 

After a bit more back and forth with ChatGPT, I found the solution (I think?) by simply unticking this setting in the Windows app:

• Use Tailscale subnets

 

With this unticked, I can now enable/disable Tailscale on unraid and I can still connect to it on my PC using 192.168.2.9. And I can also still connect to all the devices using the tailnet on PC.

 

When I additionally untick "Use Tailscale DNS settings", I can still connect to unraid on my PC using 192.168.2.9 regardless of whether Tailscale is enabled/disabled on unraid, but then I can't browse to unraid.my-tailnetname.ts.net/login anymore. So I have to keep this ticked.

 

Is the problem potentially coming from my unraid server is advertising routes? I just followed spaceinvaderone's yt guide, didn't think much of it so I just did it. This wouldn't explain the fact that I can still access 192.168.2.9 (when unraid's Tailscale is disabled) through my phone though.

 

Edited April 17, 20251 yr by PaulieW
added picture

That'll do it.

 

Here's my take on it, based on how I've seen it working and how I'm using Tailscale.

 

Use Tailscale DNS: You can/should use this *IF* your "always-works" DNS server is specified in your Tailscale Admin settings. Example: the inclusion of your own DNS server or forwarder in the Tailscale Global DNS setting. I put my AdGuard Home IP in there - the same DNS handed out by my DHCP server. I keep this option enabled to make sure that when Tailscale is ON on any particular system, that the DNS used is exactly the same as when it's OFF (ADG's IP)

 

Subnets / Advertise Subnets: You should advertise your LAN (or other required) subnet(s) *IF* you have other systems that are not part of this subnet using Tailscale and they will need access to other systems on this subnet. I advertise my LAN range, 10.8.0.0/23 - otherwise don't include anything and don't advertise from any system.

 

Use Tailscale Subnets: You should NOT have this enabled for any system that already lives on or has access to the subnet(s) being advertised (systems on your LAN) - so this needs to be OFF for every Unraid server or other machine on your premises. I turn this ON for systems such as VPS that live on the Internet that I want to have access to my other LAN systems.

 

One would think that using an advertised subnet (in the case of your PC) that matches your LAN's existing subnet should "just work" - but obviously it's causing issues. Just follow the suggestions above - OFF for all systems on LAN. *

 

* This is why this setting is #1 in the FAQ linked at the top of every page of this thread:

 

  

On 3/25/2023 at 1:51 PM, EDACerton said:

Common Issues

• I can't access the WebGUI after logging in to Tailscale

  • This is usually caused by enabling the "Use Tailscale Subnets" feature. This feature isn't needed for most installs

 

 

Edited April 17, 20251 yr by Espressomatic

2 hours ago, Espressomatic said:

One would think that using an advertised subnet (in the case of your PC) that matches your LAN's existing subnet should "just work" - but obviously it's causing issues. Just follow the suggestions above - OFF for all systems on LAN. *

 

* This is why this setting is #1 in the FAQ linked at the top of every page of this thread:

My god! Then why is it turned ON by default in Windows installation. I thought this was a fool-proof/VPN-for-dummies program, i.e. for me!  

Edited April 17, 20251 yr by PaulieW

Windows development is "special" and on the other side of the same coin, Windows developers are "special" 🤪

 

 

On 4/15/2025 at 8:28 AM, Espressomatic said:

 

1. Edit your Jellyfin Docker Container settings
2. Set its Network Type to: Custom br0
3. Give it a non-conflicting IP address within your usable range (make sure it's outside the DHCP range)
4. DISABLE Use Tailscale

 

You should be good to go now. Do the above for any/all containers you want anyone to access from outside your LAN - they'll need Tailscale on their device(s) and need to be part of your Tailnet.

 

IMO, never use the Tailscale option in a container's docker settings for any container or for any reason.

 

 

OK, I have performed these actions.

I enabled subnet LAN functionality on my router.

I can achieve a Direct Connection to the router, and I assume it is a Direct Connection to other internal IPs, since it would be going through the router.

 

My next question is about bolstering security.

I would like to permit access to Jellyfin, via Tailscale, to other family users with whom I share the machine.

However I do not want them having access to any other IP on the subnet.
The "Use Tailscale" implementation made this easy - a Tailscale IP was supplied to the container, which I could provide to family.
 

What would be the best way to implement this now? Or is that beyond the scope of this plugin?

 

You may be better served by not using only Tailscale on Unraid and instead using Pangolin which combines a number of services. You can use both if you want.

 

https://github.com/fosrl/pangolin

 

This is especially true if you're not already using a reverse proxy (which you absolutely should) and an auth server which I'm about to suggest in 3....2....

 

26 minutes ago, MediaMaan said:

My next question is about bolstering security.

 

Authentication server - but I'd not bother if Jellyfin is the only thing you're planning to expose. I'd only bother if I had at least a half dozen services I wanted to share and ALSO wanted my members to be able to sign on to any/all of them with ONE login.

 

As far as hardening against outside attack, don't open any ports and continue to use Tailscale. No one can gain access to your network under any circumstances from the outside without your permission.

 

26 minutes ago, MediaMaan said:

What would be the best way to implement this now? Or is that beyond the scope of this plugin?

 

Tailnet access control lists I'd think:

 

https://tailscale.com/kb/1018/acls

 

But the above aside...

 

Are you worried about family members brute-force attacking IP addresses on your network?

 

If so, then I'd never consider giving any of them access to anything, including Jellyfin with or without Tailscale.

 

If not, then what are you worried about? Don't give out IP addresses at all to anyone. Give them a domain name for any web services you want them to access:  jellyfin.mycoolserver.com

 

And for anything you don't give them that you think one of them might one day stumble upon, enable authentication on it - most things that need auth already have it. If you have far more services that don't have their own or you want single sign-on, then back to my previous suggestion (Authelia, Authentik, Pangolin).

 

I however don't even bother with Tailscale ACL for personal and family use. IMO, it'd be a giant waste of time to manage. Services that I share (or don't) have their own authentication and user spaces, like VaultWarden, Immich, Unraid, etc. Even things like QBittorrent, JDownloader, pyLoad. I don't keep any auth on Krusader and that has access to all my NAS file systems - do I worry about that? no.

 

I get frustrated with the way the team at Plex completely reinvents the wheel every year, but no matter what they've done, I still can't bring myself to using Jellyfin. You don't need any self-managed tunnels to have family use Plex.

 

 

 

Edited April 19, 20251 yr by Espressomatic

21 minutes ago, Espressomatic said:

 
Authentication server - but I'd not bother if Jellyfin is the only thing you're planning to expose.

 

Thanks for all the help.

Yes, it's just Jellyfin I want to expose to the Tailnet. However, with my current setup (subnet available through router), every device on the LAN is potentially exposed to the Tailnet. That is fine for my usage, and how I want it for me as the admin. However I don't want that level of exposure to a shared device for family members.

 

21 minutes ago, Espressomatic said:

Tailnet access control lists I'd think:

 

Are you worried about family members brute-force attacking IP addresses on your network?

 

Not so much - more concerned if their personal devices were compromised or stolen. No point in having my entire LAN exposed.

 

I tried reading up on the Tailnet ACLs, but was unsuccessful in creating a file that worked. I intend to return to this idea though.

 

21 minutes ago, Espressomatic said:

 If not, then what are you worried about? Don't give out IP addresses at all to anyone. Give them a domain name for any web services you want them to access:  jellyfin.mycoolserver.com

Hmm - that is also not something I am familiar with.
Is it possible to create a DNS address like that, accessible only over my Tailnet?

How would I link that to the Container IP address, and not the entire unRAID server?

Edited April 19, 20251 yr by MediaMaan

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).

 

 

1 hour ago, MediaMaan said:

Is it possible to create a DNS address like that, accessible only over my Tailnet?

 

Yes, because while you can use a legitimate and registered domain name, all IP resolution will be done internally by your DNS resolver or forwarder. No DNS server on the internet will ever know anything about your subdomains - and you don't have to point the secondary domain to your public IP address either.

 

This obviously requires that you're running a local resolver or forwarder and that it's the only DNS defined for your devices (and those of your family members) - this can be accomplished by Tailscale when it's ON if you make sure to use its DNS option. Devices hit the provided DNS address and resolve local/private addresses before queries are sent out to upstream/public DNS.

 

So you're looking at Unbound, maybe PiHole or AdGuard Home for black-hole filtering and then optionally a reverse proxy like Nginx Proxy Manager or Traefik (which will make managing a lot of subdomains easier along with automatically redirecting to HTTPS and obtaining/renewing/managing certificates). Or like mentioned in my earlier reply, Pangolin offers all this - except black-hole filtering.

 

In your shoes, since there's no requirement to share anything else with anyone, I'd REALLY skip all this for others, get rid of Jellyfin, buy Plex Pass Lifetime, and use Plex instead. Make an account for each person you want to use your Plex library and then give access on an account-by-account bases. MUCH easier to set up, SO much easier to manage, not ever going to have any hiccups that prevents access to your family members. I'd do this even if Plex Pass cost US$500 - it's simply so much less of a headache.

 

Run Tailscale for yourself only.

 

1 hour ago, EDACerton said:

TSDProxy + Label Manager is a great option for anything that runs via a browser.

 

I haven't looked into it in detail, but how does this omit the requirement to restrict access to only the newly made machine using Tailscale ACL?

 

Author's description for TSDProxy:

 

Quote

TSDProxy simplifies the process of securely exposing services and Docker containers to your Tailscale network by automatically creating Tailscale machines for each tagged container. This allows services to be accessible via unique, secure URLs without the need for complex configurations or additional Tailscale containers.

 

"Simple and easy" (always debatable) access to services via unique and secure URLs can be handled by any reverse proxy without having any Tailscale machines representing services, nor using any Tailscale-specific domain names or IPs.

 

So while I get what TSDProxy does and offers, I can't come up with a reason to use it over NPM (for example). Maybe if someone's only alternative were Traefik (ugh). And I really (REALLY) don't want Tailscale doing anything with certificates or Let's Encrypt.

 

 

 

Edited April 19, 20251 yr by Espressomatic

6 hours ago, EDACerton said:

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.

 

OK, this looks like a great option, so I decided to give it a try.

I put Jellyfin container back into Bridge mode.

I set up TSDProxy & Label Manager in unRAID.
TSDProxy kept stopping. I think because I didn't have HTTPS enabled in Tailscale. Once I enabled that it seemed to stay running.

 

Jellyfin TSDProxy machine appeared in Tailscale Machines.

However when dropping my phone onto 5G, connecting to Tailscale, 2 things happen.

 

1 - I cannot connect to Jellyfin using the TS IP address using either http or https. I am unable to use Tailscale DNS on my phone as it knocks out my Private DNS settings for Secure DoT DNS. Jellyfin is accessible from the LAN.

 

2 - Although I can't connect to the Jellyfin server via the app or web interface on my phone, the Tailscale App allows me to Ping the Jellyfin "machine". This shows a relayed connection, when all other devices on the LAN now show Direct Connection.

 

I tried changing the Labal Manager settings (Advanced) to https, and with 8096 in the container port, but this didn't seem to help either.

 

TSDProxy logs show several errors, including

1:22AM ERR error host=x.x.ts.net method=GET module=proxymanager proxyname=jellyfin status=502 url=/
http: proxy error: read tcp 172.17.0.5:33764->172.17.0.1:8096: read: connection reset by peer

 

Any ideas on what I'm missing?

5 hours ago, Espressomatic said:

 

Yes, because while you can use a legitimate and registered domain name, all IP resolution will be done internally by your DNS resolver or forwarder.

 

Ah - I am not running a DNS server at home. I'm using a third-party Secure DNS service. Although I expect it might be possible to create entries using that service, that could point to TS IP addresses.

 

5 hours ago, Espressomatic said:

 

In your shoes, since there's no requirement to share anything else with anyone, I'd REALLY skip all this for others, get rid of Jellyfin, buy Plex Pass Lifetime, and use Plex instead.

 

I generally only hear bad things about Plex. Especially relating to stopping people getting access to their own media on their own servers. So I am quite hesitant to make the switch.

 

I actually only use Jellyfin because it does a better job with Profiles & Sharing across devices the Kodi. Kodi had been my goto for 10+ years. Played everything I threw at it, without needing to transcode. But, times are changing, and I am using way more Android devices these days (compared to devices flashed with LibreElec / CoreElec back in the day). This way I can access the myriad of other streaming platforms.

 

I believe Plex has a very similar backend to Jellyfin, since it came first. But that means transcoding etc as well. If Plex could provide a bloat-free player that could handle the various codecs & subs without needing to transcode, I could possibly become interested.

 

For now though - I'd just like to get Jellyfin working well and securely through Tailscale sharing. The TSDProxy solution looks fairly decent to me. I would need to read up a lot more on NPM and other solutions (Caddy is another I've heard of) before going down that route. The less open to the internet the machine is, the better. At least with TS, it is only visible to other TS users if I share them in. That means only a few devices in the entire globe can ever "find" my TS instance. That sounds fairly secure to me...

5 minutes ago, MediaMaan said:

Ah - I am not running a DNS server at home. I'm using a third-party Secure DNS service. Although I expect it might be possible to create entries using that service, that could point to TS IP addresses.

 

I generally only hear bad things about Plex. Especially relating to stopping people getting access to their own media on their own servers. So I am quite hesitant to make the switch.

 

I actually only use Jellyfin because it does a better job with Profiles & Sharing across devices the Kodi. Kodi had been my goto for 10+ years. Played everything I threw at it, without needing to transcode. But, times are changing, and I am using way more Android devices these days (compared to devices flashed with LibreElec / CoreElec back in the day). This way I can access the myriad of other streaming platforms.

 

I believe Plex has a very similar backend to Jellyfin, since it came first. But that means transcoding etc as well. If Plex could provide a bloat-free player that could handle the various codecs & subs without needing to transcode, I could possibly become interested.

 

For now though - I'd just like to get Jellyfin working well and securely through Tailscale sharing. The TSDProxy solution looks fairly decent to me. I would need to read up a lot more on NPM and other solutions (Caddy is another I've heard of) before going down that route. The less open to the internet the machine is, the better. At least with TS, it is only visible to other TS users if I share them in. That means only a few devices in the entire globe can ever "find" my TS instance. That sounds fairly secure to me...

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/