dsmith44

Version 1.14.6 has been pushed as 1.14.6, 1.14 and latest. This fixes the issue with the IdentTrust DST Root CA X3 expiring.

You're absolutely right.

Hi, I'm afraid I can't help here, but I would point out that this was always specifically designed to not be used for a site to site VPN, and even more not as a VPN gateway. The purpose of this container was always to provide access to your host over tailscale only. We added the ability to pass custom arguments that could support this, but it still isn't a designed use and certainly not something I'm ever going to be testing in updates even if you can get it working. You might be better off just using the inbuilt wireguard support for VPN usage. EDIT: 🦈-> 🛡️

New build pushed 1.14.3 == 1.14 == latest.

1.12.3 has been released with some bug fixes. latest tag is now posting at 1.12.3 as is 1.12

1.12.1 has been released and tagged as 1.12.1 1.12 and latest

Typically within a week or so. Normally whenever I get a github notification to say there has been a new version released which isn't instanly. With something like a VPN I also tend to think it worth having a gap, especially as many people use latest tag. Pushing new builds to everyone doesn't seem a great idea as Tailscale often do very rapid minor point releases after bugs are found. Being a week or so off feels like the right approach. There are really not going to be any issues being one release behind either.

What video are you refering to? I've never made a setup video. That error is almost certainly not important, it is trying to get an IPv6 address as well as IPv4 and failing - I have that all the time without issue. I have never looked into providing IPv6 to docker containers on Unraid. Can you post more of your logfile?

1.10.2 1.10.2 has been released. Pull deasmi/unraid-tailscale:1.10.2 if using numbered builds. Those using deasmi/unraid-tailscale:latest should automatically update. Dean

I have changed the build process for this container to pull binaries from tailscale instead of building from source. This will prevent any future problems with versioning and means we are now using offical binaries. 1.10.1 is the first version where this is the case and is available as tags 1.10.1 1.10.1-BINARY latest latest will obviosuly move at a later date. Can I encourage everyone to switch to this builds as prior builds were not inline with official versions. Thank you

I need to ask for everyone's forgiveness as I am an idiot. At some point in the past I managed to change the build scripts so I was accidentally building HEAD instead of numbered versions of code. HEAD points to a development control plane hence the issues here. When they appear, which I hope will be this evening, please restore you saved state file and repoint to latest or 1.10.1. I will also push 1.10.1-FIXED if you want to make sure you pull the fixed version. I am now going back to git school, going to have lie down in a dark room and will then alter the build scripts to pull binaries instead of building from source. Apologies for all the trouble here.

Apologies, very poor testing on my part - I will ensure a ten minute+ test in future before pushing. I have rolled latest tag back to 1.8.3 and will investigate this.

Version 1.10.1 has been released and container updated.

I have no idea why you are seeing this, the repo with the template in has clear latest tag. I've just done a clean install and got latest tag. Can you totally remove the image and try? Latest tag in dockerhub tag is 1.6.0 - https://hub.docker.com/layers/deasmi/unraid-tailscale/latest/images/sha256-89c29de3e44120014a41b9399c09a97732794527b0aff5cc3fcd1d8bb28abd6d?context=repo

A couple of updates. I have changed the template to pull latest rather than versioned builds, tailscale itself is developing more slowly now so this feels appropriate. Please change the 'Repository' to deasmi/unraid-tailscale:latest to use this. Secondly I've merged in support for passing flags to tailscale. If you want to use this define a variable UP_FLAGS. These will be appended to the command that invokes tailscale. Please note if you are using UP_FLAGS I cannot provide support until it is removed, but I recognise some people may want to try subnet routing and the like. Thanks to @shayne for this. Dean

Looking at the Zerotier docker post that links here it looks like you got connectivity working, you can connect by IP to your unraid server's tailscale address. I do not believe that tailscale support multicast or broadcast traffic, so there won't be any way to get Bonjour working and have your Unraid appear as a browsable machine.

I believe ACL support is only available in the paid version, which I do not have, nor have a need for. As such I am not planning to look at ACLs. Sorry.

If the influx container is only listening on the ETH1 ip address, bridge mode, then I'm afraid this container probably isn't going to work for you. This will only allow you to access containers that listen on the tailscale interface ip address itself, not eth1, eth2 or any other interfaces. It is not providing a gateway to 'other networks' just exposing the Unraid server itself to tailscale.'other networks' in this context means absolutely anything that isn't the IP address of the tailscale interface. If you can make influxDB also bind to the tailscale interface then it will work. I'm not keen on trying to turn this into a VPN gateway solution, nor am I sure that's even possible with a docker container rather than a plugin.

I don't know what people have against the poor venerable while loop 😎, but I have changed to use a 'sleep infinity' instead which is slightly cleaner. Whilst your method will work, and is elegant, it's less 'obvious' about ordering, so I think I'll leave that alone.

Re: host vs bridge mode Having thought this through I feel host is the correct mode for this to operate in. Host means the networking is part of the base host networking so if the host can see the port tailscale will be able to as well. However that relies on the mapped ports listening on all addresses, which if I check my unraid server they do. root@unraid:~# ss -ltu Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process .. tcp LISTEN 0 128 *:8200 *:* .. However the only IP address that you'll be able to access through tailscale will be the tailscale ip address itself, trying to use a LAN address, a docker bridge network address or any other address is going to fail as we aren't doing subnet forwarding. I am not currently keen on even trying to add subnet forwarding to this container as it was never my intention to create a VPN gateway, just to allow access to Unraid services from tailscale. I am also not sure if this is even necessarily possible without additional steps outside of the container itself; if I look in the Apps list OpenVPN server is available as a plugin but not as a container. So building a plugin is likely a better route for someone to look at, but not something I'm going to get into. I would suggest using the built in wireshark support if you want to get a VPN connection to the whole network.

Fixed, bit embarrasing that one... thanks.

I will do some testing and perhaps change the definition to prefer bridge networking instead, my docker networking is a bit rusty so time for some reading I think.

Version 0.98.1 is now available which contains the upstream fix for the issues in 0.98 :latest will contain this fix, 0.98.1 will contain this fix.

My apologies, I shouldn't have pushed this as hadn't tested myself, thinking just a simple point update. This is broken currently and I don't know why. The STUN process isn't working in 0.98 in this docker container, I am going to build using their official Dockerfile and test outside of Unraid. If it doesn't work there either will submit a bug report, if it does then at least I can start narrowing down the cause. For now please use deasmi/unraid-tailscale:0.97 Update: I have recreated the issue on stand alone Ubuntu server and submitted issue to tailscale https://github.com/tailscale/tailscale/issues/368

Tailscale is, in my view, scratching a sligtly different itch. It is still wireguard, but it's wireguard plus NAT busting and zero management of many to many connections. I'm not just using this to connect to my unraid server, but also virtual servers. Unraid is joining my mesh here, this isn't providing access to my LAN remotely. If you want a hub and spoke model I'd suggest still using out of the box wireguard, if you want genuine point to point this is much easier to setup.