RFC: Implementing Wireguard Support

[haugene]

Hello there 👋

I decided to start a new discussion to get feedback on the implementation and hopefully some testing of my proposed implementation of Wireguard support. The previous Wireguard discussion is a bit outdated and other related discussions also exist, for example here and here

This thread is about this proposed PR: #2607

A summary of what it does:

• First of all it adds Wireguard support in a separate image: haugene/transmission-wireguard
• In its current form it changes this repository to a monorepo that will produce haugene/transmission-wireguard, haugene/transmission-openvpn and a common base image haugene/transmission-base
• It implements Wireguard with "The New Namespace Solution" described here to separate Torrent traffic and local traffic to the UI
• It produces a working image ready to test (works on my machine)

Current limitations and room for improvement:

• This is a first draft and it's supposed to work, and support setting PUID/PGID - that's it.
• The new image does not support privoxy, ufw and probably a bunch of other functionality yet
• After starting Transmission we don't get any logs. I was actually expecting them to go to stdout since we're running Transmission in the foreground now, but no. Have to look more at that.
• It produces a huge image, installing Wireguard increases the image size from the base image of ~200MB to the current one at around 1GB. Very interested if someone has a suggestion for a fix here, but disk space is not critical for now.
• It will need some templating at startup to support other images/containers using its network stack to route traffic (due to the new namespace solution used)

If you have any comments about the image naming, common base image, and what we should name the GitHub repository that would also be great. Using a common base image will help us reduce build time of the main images because we now build Transmission from source and it takes a long time. With this setup all changes to the main images will be quick. After merging this we should change the openvpn image to use the same base. I would then also suggest renaming the GitHub repo to haugene/docker-transmission-vpn to not lock into the openvpn name.

CALL TO ACTION: Please test it, and read the PR if you're up for that. Any report of bugs 🐛 or suggestions for improvement is very welcomed. I've made a docker-compose.yml example to get you started. For reference I've used Mullvad when setting it up. Had some issues with PIA initially, but that's probably worth another shot now.

Thanks to @warlo for helping out with the implementation 🙌

[braymullo]

Fantastic.

Can't help with the 1gb image size, only to suggest peeking in thrnz/docker-wireguard-pia GitHub and seeing how they implement it. That image is 32mb.

I'm running thrnz (32mb) into qbittorrent (200mb). It passes the forwarded port from PIA into qbittorrent using the PORT_SCRIPT env.

Naturally this is PIA, and the beauty of your image is compatibility between so many providers. But maybe there's something to gleam from there.

p.s. I moved from transmission to qbittorrent as I need BitTorrent v2, and the version of transmission here didn't support it. edit I see you support transmission 4.x now, so this is no longer an issue

[1ttric]

Looking forward to this!

When running the latest haugene/transmission-wireguard:wg image in k8s (with Calico) I'm seeing there's no broadcast address set on the pod's NIC, which causes a crash at startup due to an invalid $INT_BRD

The set -x debug output from /opt/wireguard/start.sh:

root@transmission-0:/# /opt/wireguard/start.sh
+ [[ -n e7f80133eac179e45560d3541e22ecc43cf90195 ]]
+ echo 'Image revision: e7f80133eac179e45560d3541e22ecc43cf90195'
Image revision: e7f80133eac179e45560d3541e22ecc43cf90195
+ [[ -n 1956659863844c01214c280689e467bba4315e2e ]]
+ echo 'Base image revision: 1956659863844c01214c280689e467bba4315e2e'
Base image revision: 1956659863844c01214c280689e467bba4315e2e
+ echo 'Current public IP is:'
Current public IP is:
+ curl --silent -w '\n' ipecho.net/plain
123.123.123.123
+ ip netns ls
+ grep -q physical
++ /sbin/ip route list match 0.0.0.0
++ awk '{print $3}'
+ GW=169.254.1.1
++ /sbin/ip route list match 0.0.0.0
++ awk '{print $5}'
+ INT=eth0
++ ip -f inet addr show eth0
++ awk '/inet / {print $2}'
+ INT_IP=192.168.0.26/32
++ ip -f inet addr show eth0
++ awk '/inet / {print $4}'
+ INT_BRD=global
+ echo 'Found default container interface, will use this in setup:'
Found default container interface, will use this in setup:
+ echo 'Interface: eth0'
Interface: eth0
+ echo 'Gateway: 169.254.1.1'
Gateway: 169.254.1.1
+ echo 'Interface address: 192.168.0.26/32'
Interface address: 192.168.0.26/32
+ echo 'Interface broadcast: global'
Interface broadcast: global
+ cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
+ echo 'nameserver 1.1.1.1'
+ ip netns ls
+ ip netns add physical
+ ip link set eth0 netns physical
+ ip -n physical link add wg0 type wireguard
+ ip -n physical link set wg0 netns 1
+ ip -n physical addr add 192.168.0.26/32 dev eth0 brd global
Error: inet address is expected rather than "global".

Container network info:

root@transmission-0:/# ip a
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
3: eth0@if69: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether 56:fd:31:00:65:d1 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.26/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::54fd:31ff:fe00:65d1/64 scope link
       valid_lft forever preferred_lft forever

[Sabb0]

Just want to say, I really appreciate everyone's effort that goes into developing this container. Wireguard support would be the cherry on the top, as in my own experience, it is consistently much faster than OVPN. I will test the container when I get a chance!

[rakuri255]

The waiting time was simply too long for me until this implementation is ready. I went a different way and it is currently running very stable for me. Especially since Wireguard is not in the kernel of a Synology NAS, something else is needed anyway.
I simply run an extra container for the VPN connection.
Maybe this will help as an example to stabilise and finish this project.

version: "3.7"
services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: vpn_gluetun
    cap_add:
      - NET_ADMIN
    ports:
      - 9091:9091/tcp # Transmission UI
    volumes:
      # ...
    environment:      
      # Wireguard:
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - WIREGUARD_PRESHARED_KEY=${WIREGUARD_PRESHARED_KEY}
      - WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
      - WIREGUARD_MTU=1320
      - DNS_ADDRESS=${WIREGUARD_DNS}
      - FIREWALL_VPN_INPUT_PORTS=${VPN_PORT}

  transmission:
    image: lscr.io/linuxserver/transmission:latest
    container_name: transmission
    depends_on:
      - gluetun
    network_mode: "service:gluetun" # when used in same compose file
    #network_mode: "container:vpn_gluetun" # when used in external compose file
    environment:
     # ...
    volumes:
     # ...
    restart: unless-stopped

[moonraker2]

Out of curiosity, did you get port forwarding to work as well?

[rakuri255]

Yes. Its FIREWALL_VPN_INPUT_PORTS=${VPN_PORT}

[rakuri255]

I still running this 2 service docker images because you get the latest updates of both words!
You are at the official image source of Transmission and glutun (vpn service).

And you are not dependent on something where there are rarely updates or no further development like this haugene project.

[moonraker2]

Ok, and have you taken some steps to secure the solution? I believe some security features such as vpn killswitch are built into haugenes solution via special iptables rules.
I'm personally a bit paranoid when it comes to torrenting, so want to ensure that the solution I use is as secure and privacy focused, as possible :)

For port forwarding, do you have this fully automated, or are you manually updating the port in transmission daemon according to the currently forwarded port?

[rakuri255]

gluetun already has iptables for security.
If you don't have a vpn connection, the torrent image simply has no internet connection.
I use a fixed port. Read the gluetun docu, maybe you can make it dynamic.

And about your Panaroia. Gluetun is regularly updated and the security is regularly increased.

[bijfy]

Just tried and it's working great. First tried fastestvpn conf and it was based on nameservers rather than ip address so it didn't work. Then used vpnunlimited wireguard config and it worked great.

[paulr24]

I'm trying to run this on a Synology NAS. Used the provided yml (https://github.com/haugene/docker-transmission-openvpn/blob/wg/wireguard/docker-compose.yml) but I'm getting:

mount --make-shared /run/netns failed: Permission denied

I could be way off in my setup since there isn't much documentation (understandably), but does anyone know how I might be able to get past this?

[pkishino]

Got the wireguard up and running but cannot open any port..checked with privatevpn and they don't support port forwarding for the wireguard, just wanted to check if other providers have this working?

[Uzurka]

Hey !
Just got Optical Fiber recently and noticed speeds with OpenVPN (Provider: PIA) were kinda slow...
Found that thread, inactive since OCt 2019
Any new on this project ? ^^

[conclusionlogic]

I've set it up with PIA, deployed to Kubernetes using this old chart, seems to work fine.

[nebula-it]

@conclusionlogic Can you please share your values.yaml, I'm looking to deploy this to k8s so that'd make it easy for me.

[conclusionlogic]

Sure, no problem.
At the time of posting my above comment here, those were the parameters used with the haugene/transmission-wireguard:wg image:

values.yaml

# -- Number of replicas to run. Chart is not designed to scale horizontally, use at your own risk
replicaCount: 1

# -- Use host network
hostNetwork: false

hostPort:
  # -- Use host port for the application
  enabled: false
  # -- Host port to bind to
  port: 9091

# -- Common labels for all resources of the chart
commonLabels: {}

# -- Additional port definitions for the pod
additionalPorts: []

# -- Additional port definitions for the service
additionalServicePorts: []

image:
  # -- Image repository
  repository: haugene/transmission-wireguard
  # -- Image pull policy
  pullPolicy: IfNotPresent
  # -- Image tag (if not specified, defaults to the chart's appVersion)
  tag: wg

# -- Image pull secrets
imagePullSecrets: []
# -- String to partially override fullname template with a string (will prepend the release name)
nameOverride: ""
# -- String to fully override fullname template with a string
fullnameOverride: ""

serviceAccount:
  # -- Specifies whether a service account should be created
  create: true
  # -- Annotations to add to the service account
  annotations: {}
  # -- The name of the service account to use. If not set and create is true, a name is generated using the fullname template
  name: ""

# -- Annotations for the pods
podAnnotations: {}

# -- Security context for the pods
podSecurityContext: {}
#  runAsUser: 0
#  runAsGroup: 0

# -- Security context for the container. NET_ADMIN capability is required for the VPN to work properly.
securityContext:
  capabilities:
    add:
      - NET_ADMIN
      - SYS_ADMIN

# -- Deployment strategy
strategy:
  type: Recreate

service:
  # -- Type of the service
  type: ClusterIP
  # -- Port for the service to use
  port: 80
  # -- Service annotations
  annotations: {}
  # -- clusterIP for the service
  clusterIP: ""
  # -- loadBalancerIP for the service
  loadBalancerIP: ""
  # -- externalName for the service
  externalName: ""
  # -- loadBalancerClass for the service
  loadBalancerClass: ""

ingress:
  # -- Expose the app using an ingress
  enabled: false
  # -- Ingress class name
  className: ""
  # -- Annotations for the ingress
  annotations: {}
  # -- Ingress hosts configuration
  # @default -- see [values.yaml](values.yaml)
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  # -- The TLS configuration for the Ingress
  tls: []

# -- The resource requests and limits of the container
resources: {}

# -- The node selector for the deployment
nodeSelector: {}

# -- Tolerations for the pod assignment
tolerations: []

# -- Affinity for the pod assignment
affinity: {}

persistence:
  # -- Enable persistence
  enabled: false
  # -- Persistence type is pvc. When `false`, data volume definition is read from `persistence.dataVolume`
  isPvc: true
  # -- Name of the existing claim to be used
  existingClaim: ""
  # -- Storage class for the data volume
  storageClass: ""
  # -- Volume name override for the pvc
  volumeName: ""
  # -- Annotations for the claim
  annotations: {}
    # helm.sh/resource-policy: keep
  # -- Access modes for the claim
  accessModes:
    - ReadWriteOnce
  # -- Size for the claim
  size: 64Gi
  # -- Alternative data volume definition (e.g. nfs, hostPath). Used when `persistence.isPvc` is `false`
  dataVolume: {}
    # hostPath:
    #   path: /path/on/host

# -- Non-sensitive environment variables to be set in the pods. See the [application docs](https://haugene.github.io/docker-transmission-openvpn/config-options/)
env:
  CONFIG_FILE: /wg-config/my_wg.conf
  LOCAL_NETWORK: "192.168.1.0/24"
  LOG_TO_STDOUT: "true"
  TRANSMISSION_CACHE_SIZE_MB: "4"
  TRANSMISSION_HOME: /data/transmission-home
  TRANSMISSION_RATIO_LIMIT: "0.5"
  TRANSMISSION_RATIO_LIMIT_ENABLED: "true"
  TRANSMISSION_RPC_HOST_WHITELIST: <INGRESS_HOSTNAME>
  TRANSMISSION_RPC_PASSWORD: <RPC_PASSWORD>
  TRANSMISSION_RPC_USERNAME:  <RPC_USERNAME>
  TRANSMISSION_RPC_WHITELIST: "10.244.0.*"  # PodSubnet
  TRANSMISSION_SEED_QUEUE_ENABLED: "true"
  TRANSMISSION_SEED_QUEUE_SIZE: "1"
  TRANSMISSION_WATCH_DIR: "/data/ingest"
  TRANSMISSION_WATCH_DIR_ENABLED: "true"
  WEBPROXY_ENABLED: "false"
  # OPENVPN_PROVIDER: my_value
  # CREATE_TUN_DEVICE: "true"
  # TRANSMISSION_SPEED_LIMIT_UP: "2048"
  # PUID: "1000"
  # PGID: "1000"

# -- Sensitive environment variables to be set in the pods. See the [application docs](https://haugene.github.io/docker-transmission-openvpn/config-options/)
secretEnv: []

# -- Mount the /dev/net/tun device into the pod. Required by OpenVPN when a `tun` device is used
mountTunDevice: false

# -- DNS configuration for the pod
dnsConfig: {}

# -- DNS policy for the pod
dnsPolicy: ClusterFirst

# -- Arbitrary extra volume definitions for the pod
extraVolumes:
  - name: wg-config
    emptyDir: {}
  # - name: custom-provider-config
  #   secret:
  #     defaultMode: 420
  #     secretName: openvpn-custom

# -- Arbitrary extra volume mounts for the pod
extraVolumeMounts:
  - mountPath: /wg-config/
    name: wg-config
    readOnly: true

# -- Pod liveness probe
livenessProbe:
  tcpSocket:
    port: http

# -- Pod readiness probe
readinessProbe:
  tcpSocket:
    port: http

# -- Init containers
initContainers:
  - name: generate-wg-config
    image: conclusionlogic/piawgcli:v0.0.1
    args:
      - create-config
      - --pia-id=<YOUR_PIA_ID>
      - --pia-password=<YOUR_PIA_PW>
      - --pia-region-id=<PIA_REGION>
      - --output=/wg-config/my_wg.conf
    volumeMounts:
      - name: wg-config
        mountPath: /wg-config

# -- Sidecar containers
sidecarContainers: []
  # - name: sidecar
  #   image: busybox:stable-musl
  #   command:
  #     - tail
  #     - -f
  #     - /dev/null

I’ve reset the ingress: and persistence: sections to the chart’s defaults, stripped the env: section down to the bare minimum, and replaced all sensitive values with placeholders, as these will be specific to each individual installation.
I left my initContainers config as an example of how I’m generating the PIA-specific WireGuard config file my_wg.conf for the main container to use.

The conclusionlogic/piawgcli:v0.0.1 image is built directly from https://gitlab.com/ddb_db/piawgcli source code.
Feel free to build your own image if you don’t trust what I’ve uploaded, or if you prefer to build your own image or use a different tool/method for creating and mounting your own my_wg.conf file.

BTW, I've since switched to using https://gitlab.alfter.us/salfter/transmission-wireguard-pia / https://hub.docker.com/r/salfter/transmission-wireguard-pia/tags as my springboard.
It generates the PIA WireGuard config as part of its startup routine - uses lots of nasty bash scripts to do that, but works, and the container image is really tiny which I like.

[nebula-it]

I went a slightly different route and created this deployment to get transmission working through wireguard:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: transmission
spec:
  selector:
    matchLabels:
      app: transmission
  strategy:
    type: Recreate
  replicas: 1
  template:
    metadata:
      labels:
        app: transmission
    spec:
      containers:
        - name: transmission
          image: lscr.io/linuxserver/transmission:latest
          ports:
            - containerPort: 9091
          volumeMounts:
            - name: transmission
              mountPath: /config
            - name: transmission_download
              mountPath: /downloads
              subPath: transmission/
            - name: transmission_download
              mountPath: /watch
              subPath: transmission/transmission/watch

        - name: wireguard
          image: "lscr.io/linuxserver/wireguard:latest"
          securityContext:
            capabilities:
              add:
                - NET_ADMIN
          lifecycle:
            postStart:
              exec:
                command:
                  [
                    "/bin/sh",
                    "-c",
                    "cp /wgconfig/* /config/;sed -i '/net.ipv4.conf.all.src_valid_mark/d' /usr/bin/wg-quick",
                  ]
          volumeMounts:
            - name: wireguard-config
              mountPath: /wgconfig
      volumes:
        - name: wireguard-config
          secret:
            secretName: wireguard-config
        - name: transmission
          persistentVolumeClaim:
            claimName: transmission
        - name: transmission_download
          persistentVolumeClaim:
            claimName: transmission_download

and added this to wireguard to route all RFC1819 traffic through local gateway:

PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE;ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE;iptables -I OUTPUT -d $HOMENET -j ACCEPT;iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT;  iptables -A OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route del $HOMENET3 via $DROUTE;ip route del $HOMENET2 via $DROUTE; ip route del $HOMENET via $DROUTE; iptables -D OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -m addrtype ! --dst-type LOCAL -j REJECT; iptables -D OUTPUT -d $HOMENET -j ACCEPT; iptables -D OUTPUT -d $HOMENET2 -j ACCEPT; iptables -D OUTPUT -d $HOMENET3 -j ACCEPT

I have to manually generate the config though, but that'll be rare and this is really simple otherwise. Hope it helps someone 😊

[moonraker2]

Has there been any more progress on making the jump from OpenVPN to Wireguard?

I tried to test out the proposed implementation of Wireguard, but found it a bit difficult, being a docker newbie and all.

If the solution is now broken out into two separate images (wireguard and base/transmission), how do I then combine them correctly into one single docker compose file?

I'm using PIA VPN and I generated a pia-wg.conf using this soluition:
https://github.com/djtroyal/pia-wg

Given a few pointers on how to get the full solution up and running, just with using Wireguard instead of OpenVPN, I'll happily test out and report back since I'm quite eager to migrate to Wireguard.

[wally-crunk]

https://gitlab.alfter.us/salfter/transmission-wireguard-pia

This appears to be password-protected. Is it supposed to use the same password as 'gitlab.com'? The domain is different.

[toxic0berliner]

@salfter seems to have put his gitlab instance in non-public mode and https://gitlab.alfter.us/salfter/transmission-wireguard-pia is now not accessible anymore.

I hope he/she gets to read this message and we can find a way to get in touch so he can let us clone the repo at least once and put it on github for us to continue using it.

I had an unrelated issue today (disk full caused corruption of portsig.json which caused the whole shenanigan to fail...), I was able to solve it but having access to the source code would have made it much easyer...

Sorry if I pollute this thread on haugene but I too switched to the salfter one as it was the only one working inside docker inside my unpriviledged CT. I even customized the /scripts/launch-transmission.sh to allow using my custom uid. Being lazy I much prefer taking a clone of the repo on my gitlab and building the image myself than looking for yet another alternative :D

[salfter]

@salfter seems to have put his gitlab instance in non-public mode and https://gitlab.alfter.us/salfter/transmission-wireguard-pia is now not accessible anymore.

I made it private because I found some settings within that shouldn't have been made public. I'll see if I can sanitize the repo so I can make it available.

[salfter]

...and it's now available again:

https://gitlab.alfter.us/salfter/transmission-wireguard-pia

[toxic0berliner]

Unless I am mistaken it seems you missed something to make it public, I see no access to the sources.

[salfter]

That's weird...it should be visible. Hold on a sec...

It's now visible to all.

[Uzurka]

Indeed, i can see it again, thanks !
Any plan to update / maintain it ?

[salfter]

I'm thinking I might rework it to build from the upstream image directly. When I first put this together, I forked the upstream repo and made my changes to the Dockerfile that was provided: pull in some more packages and add some scripts. It should be possible to replace the Dockerfile I'm using with a smaller one that just adds my changes.

As things stand now, the occasional docker compose build --pull && docker compose up -d keeps the underlying components updated.

[Uzurka]

You're talking of the Transmission upstream image ?
If you plan to rebuild it, why not use the LSIO's one ?

[darmach]

How is it going @haugene ? Looking forward to this one! :)

[mCo0L]

this would be really cool actually.

[haugene]

Life has been too busy for a while. But I'm trying to get back up on the horse.
The good news is that I've been running the wireguard-image since I made the original post here two years ago ☝️

So let's say I'm ready to move out of the testing phase 🙈 😅
I'm trying to get back to devoting some time to this project. Let's see how well that goes 🤞

[darmach]

That's great news @haugene ! I'm currently running your openVPN image, and was looking for least-resistance wa to migrate to some wireguard :)

I'm going to wait for the final version then!

[pchristod]

That sounds great @haugene. Just came here to check because Mullvad is removing OpenVPN Support completely beginning of January 26 so I'm happy there will most likely be a Wireguard follow up of this awesome Container :)
Thanks!

[pkishino]

Welcome back :) I tried keeping up with the project and got some wonderful help from various others but the past year or so due to global relocation and work is been hard. Let me know if you want to sync up for a chat about potential next steps :)/ BRPatrick KishinoOn 14 May 2025, at 15:03, Kristian Haugene ***@***.***> wrote: Life has been too busy for a while. But I'm trying to get back up on the horse. The good news is that I've been running the wireguard-image since I made the original post here two years ago ☝️ So let's say I'm ready to move out of the testing phase 🙈 😅 I'm trying to get back to devoting some time to this project. Let's see how well that goes 🤞 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[haugene]

Aha, look at that! You're back in Europe now 😄
A sync sounds nice, I'll PM you 👍