Skip to main content Docker container ignoring TS vars? : r/Tailscale
r/Tailscale icon
Go to Tailscale
•

Docker container ignoring TS vars?

Help Needed

Hey all,

I deployed tailscale to my local network to a lab rpi running pontainer - no surprises here....

The problem is, that the tailscale daemon running inside the container seems to b given the TF_ROUTES in my compose file. Nope.... It exposed nothing until I connected to the container and ran `tailscale set --advertise-routes= providing the authkey as an argument. 

version: "3.3"
services:
  tailscale:
      privileged: true
      hostname: tailscale
      network_mode: host
      container_name: tailscale
      image: tailscale/tailscale:latest
      volumes:
          - "/mnt/tailscale/var:/var/lib"
          - "/dev/net/tun:/dev/net/tun"
      cap_add:
        - NET_ADMIN
        - NET_RAW
      environment:
        - PUID=1000
        - PGID=1000
        - TS_USERSPACE=true
        - TS_AUTHKEY=aaa
        - TS_ROUTES=192.168.1.0/24
        - TS_HOSTNAME=tailscale
        - TS_STATE_DIR=/var/lib/tailscale
      command: tailscaled
      restart: unless-stopped

The problem is, that the tailscale daemon running inside the container seems to be ignoring the TS vars provided - this means, the device did not authorized, unless I exec'ed to the container and run the tailscale command manually, providing the authkey as an argument.

The same with the routes - I was expecting the device would expose 192.168.1.0/24 given the the TF_ROUTES in my compose file. Nope.... It exposed nothing until I connected to the container and ran `tailscale set --advertise-routes=192.168.1.0/24` - after doing so, the route works as expected and was available for an approval in the web ui.

Any idea why? I thought I am providing the env variables correctly and these will be used by tailscaled but these seem to be ignored..

Thanks for any help!

Upwork’s AI tools help you search through thousands of candidates to find and hire the right freelancer for the job.
Sign Up
upwork.com
Thumbnail image: Upwork’s AI tools help you search through thousands of candidates to find and hire the right freelancer for the job.
Sort by:
Best
Open comment sort options
• • Edited

When you bring the tailscale docker container up and look at the docker logs do you see any errors?

•

Nothing obvious. The only thing I noticed was 

2024/01/03 11:52:32 health("router"): error: setting up filter/ts-input: running [/sbin/ip6tables -t filter -N ts-input --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.8.9 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)`

which I resolved by adding `TS_DEBUG_FIREWALL_MODE=auto` (and the firewall mode changed to `nft-inuse` from `ipt-default`).

Worth mentioning that after setting this variable what apparently helped tailscaled to perform `wgengine: Reconfig: configuring DNS` and do its DNS thing and it look ok'ish now (I don't have a way how to check as the subnet is already exposed after running the manual command I mentioned earlier), yet I'd still expect the device to register automatically using the provided authky as this is likely happening in an earlier stage.

;tldr not sure if the firewall mode was blocking the login and other tasks as these worked fine when issued manually inside the container.

More replies More replies
• • Edited

Here's the docker-compose I use with Portainer-Stacks, which has generally worked quite well for me across numerous Docker hosts: 

version: '3.9'
services:
  tailscale:
    image: tailscale/tailscale:${TAG}
    container_name: tailscaled
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      #- TS_HOSTNAME=${TS_HOSTNAME} # Usually not necessary for your hostname to be the same name on the tailscale network
      #- TS_AUTHKEY=${TS_AUTHKEY} # Generate auth keys here: https://login.tailscale.com/admin/settings/keys
      #- TS_AUTH_ONCE=${TS_AUTH_ONCE}
      - TS_ROUTES=${TS_ROUTES} # Creates a subnet router for Tailscale. Use your subnet's CIDR in the form: 192.168.1.0/24
      - TS_ACCEPT_DNS=${TS_ACCEPT_DNS} # Set to false for Pi-hole Docker setups
      - TS_SOCKET=${TS_SOCKET}
      - TS_EXTRA_ARGS=${TS_EXTRA_ARGS} # Add any other supported arguments in the docker commandline style: e.g. --advertise-exit-node
      - TS_STATE_DIR=${TS_STATE_DIR} # Required to create a persistent container state that will survive reboots
    volumes:
      - ${HOST_DIR}:/var/lib # Creates a tailscale directory under HOST_DIR for persistence
      - /dev/net/tun:/dev/net/tun
    network_mode: host
    restart: unless-stopped

And, some sample env variables 

TAG=latest
TS_ROUTES=192.168.1.0/24
TS_ACCEPT_DNS=false
TS_SOCKET=/var/run/tailscale/tailscaled.sock
TS_EXTRA_ARGS=--advertise-exit-node
TS_STATE_DIR=/var/lib/tailscale
HOST_DIR=/data

A few notes:

I've found that not using TS_AUTHKEY is more convenient for me. Simply look in the Portainer-Log for the container after starting it, and the usual auth link can be found there, which can be copied and pasted into your browser.

My example is from a Pi-hole DNS server, which has been setup to also be a subnet router and exit node. TS_ACCEPT_DNS=false, is required for this Pi-hole example, but normally would not be used.

I would suggest removing privileged:, PUID=, GUID= and command: as none of these are required, and could have unintended consequences.

•

Hi, would you know which env variables should I use for --snat-subnet-routes=false?

I tried running it with TS_EXTRA_ARGS=--snat-subnet-routes=false and also docker exec tailscale tailscale up --snat-subnet-routes=false but nothing is happening.

More replies More replies
• • Edited

You're not alone, I have this issue as well. Experimenting in the last 48 hours, I can also see that a docker compose is passing environment variables such as TS_AUTHKEY to the current tailscale/tailscale latest container and the container is stuck waiting on auth as if it's not looking at this (or any other variable provided).

Edit : don't execute the daemon direct. See other post

•

Funny stuff.... I was migrating my tailscale container to a different server and hit exactly the same issue as the one I reported. This time, I made sure I put `TS_DEBUG_FIREWALL_MODE=auto` in so I am sure the container wouldn't interrupt the init phase because of some dumb network config issue but nope - `TS_AUTHKEY` and also `TS_ROUTES` were simply happily ignored even this time and I had to exec to the container and run the respective commands manually...

More replies
•

command: tailscaled

Remove this. You want the docker to execute the wrapper it's built with - that's what pulls the env var's into a CLI line - you're calling the daemon direct which will ignore the env vars.

Made the same mistake :P

•

Ah makes sense! I was under impression that `tailscaled` reads the env variables of the container. Thanks for head up! :)

•

This, thank you. I was with the same problem I got the docker run command from the original doc and it was not working like the OP, once I removed the command from compose the exitnode and subnets were there!

thanks!

More replies