Transmission Over VPN

2025-01-24

Streaming services have become more and more annoying to deal with over the years. Trying to find a particular movie and realizing you either need to watch ads or pay even more money to rent the movie on a platform you already pay for has become the norm. As a result, more and more people have switched back to torrenting as opposed to paying multiple subscriptions for all the various streaming services.

I personally haven’t torrented anything since I was 16 years old. Why? Because up until then, streaming services provided everything I needed. Now, all the wannabe-FAANG companies have spun up their own lesser and more expensive versions of a failing streaming platform. Content that used to be available entirely in one place is now fragmented across many greedy domains. The custody battles over our favorite TV shows and movies has turned streaming into an unaffordable nuisance.

At first I didn’t want to bother setting up a Plex Media server in my homelab. Afterall, I work in tech and make plenty of money to afford a subscription to as many media services as I’d like. As time went on however, I got bored and craved a new project. Eventually, I caved and decided I’d finally deploy Plex along with all the other microservices I’d need to torrent effectively.

Back in my early days of torrenting, I didn’t have a dedicated computer or even my own PC. I only had the shared family computer. I rememebr my dad receiving letters in the mail from our ISP notifying us that they caught us downloading movies illegaly. My dad, nostrils flaring at the sight of defiance, demanded I stop at once. The idea of cheating a defenseless company like Paramount was unspeakable. Which is why I’m writing about it instead.

Over the last 5 or 10 years, VPN providers have become pretty mainstream. I never felt that I actually required one. Now with torrenting I felt I had an appropriate reason to choose one. I won’t bother mentioning the name of my VPN provider, I’m sure they appreciate the discretion.

One quiet evening I was bored enough to confiugre all the media services I’d need on my homelab. I really wanted to check out this movie, “Edge of Tomorrow” that my friendly neighborhood drug dealer Bob Calloway kept going on about. I’m pretty sure he’d already spoiled the ending but I’m a sucker for SciFi.

Wireguard

Wireguard is a open source communication protocol that we can use to setup a VPN. There were a few ways I could setup Wireguard. My homelab is a baremetal Kubernetes cluster which means each node in the cluster is an actual server, not a VM. There were three main options I could choose to deploy Wireguard:

Deploy Wireguard as a systemd service on the node
Deploy Wireguard as a Kubernetes service
Deploy Wireguard as a Pod sidecar

I went with option 3 as right now, the only thing needing to use Wireguard is my torrenting client, Transmission. In addition, if any services needed a VPN tunnel in the future they could also easily deploy this sidecar with minimal configuration.

My deployment was simple:

Wireguard runs as a sidecar and establishes a VPN Connection
Transmission downloads and seeds torrents through the VPN tunnel

My VPN provider was kind enough to provide an easy way to generate wireguard configurations. My wireguard config looks something like this:

wg0.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


[Interface]
# Bouncing = 20
# NetShield = 1
# Moderate NAT = off
# NAT-PMP (Port Forwarding) = on
# VPN Accelerator = on
PrivateKey = SOMEPRIVATEKEY
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# US-CA#69
PublicKey = SOMEPUBKEY
AllowedIPs = 0.0.0.0/0
Endpoint = SOMEIP:SOMEPORT

I then convert this to a Kubernetes configmap by running:

1
2
3
4
5
6
7
8


# Create the configmap
kubectl create configmap wireguard-config \
    --from-file=wg0.conf \
    --dry-run=client -o yaml \
    > wireguard-configmap.yaml

# Apply it to the cluster
kubectl apply -f wiregaurd-configmap.yaml

Wireguard requires special permissions in order to tunnel traffic. I highlighted these permissions below:

transmission-deployment.yaml

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


    ...
      containers:
        - name: wireguard
          image: linuxserver/wireguard:latest
          securityContext:
            capabilities:
              add:
                - SYS_MODULE
                - NET_ADMIN  # Allows WireGuard to set up the VPN interface
            privileged: true
          volumeMounts:
            - name: wireguard-config
              mountPath: /config/wg_confs
      volumes:
        - name: wireguard-config
          configMap:
            name: wireguard-config

The entire deployment looks something like this (I’ll include a Github gist at the very bottom of this post):

transmission-deployment.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


apiVersion: apps/v1
kind: Deployment
metadata:
  name: transmission
  labels:
    app.kubernetes.io/name: transmission
    app.kubernetes.io/instance: transmission
spec:
  strategy:
    type: Recreate
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: transmission
      app.kubernetes.io/instance: transmission
  template:
    metadata:
      labels:
        app.kubernetes.io/name: transmission
        app.kubernetes.io/instance: transmission
        app: transmission
    spec:
      initContainers:
        - name: config-transmission
          image: docker.io/ubuntu:groovy
          command: ["/init-transmission/init-transmission.sh"]
          volumeMounts:
            - mountPath: /init-transmission
              name: init-files-transmission
            - name: mediaserver-volume
              mountPath: "/transmission-config"
              subPath: "config/transmission"
          securityContext:
            runAsUser: 1000
            runAsGroup: 1000
      containers:
        - name: wireguard
          image: linuxserver/wireguard:latest
          securityContext:
            capabilities:
              add:
                - SYS_MODULE
                - NET_ADMIN  # Allows WireGuard to set up the VPN interface
            privileged: true
          volumeMounts:
            - name: wireguard-config
              mountPath: /config/wg_confs
        - name: transmission
          image: "docker.io/linuxserver/transmission:latest"
          env:
           - name: PGID
             value: "1000"
           - name: PUID
             value: "1000"
          imagePullPolicy: Always
          readinessProbe:
            httpGet:
              path: "/transmission/"
              port: 9091
            initialDelaySeconds: 5
            periodSeconds: 10
            timeoutSeconds: 20
          ports:
            - name: trans-port
              containerPort: 9091
              protocol: TCP
          volumeMounts:
            - name: mediaserver-volume
              mountPath: "/config"
              subPath: "config/transmission"
            - name: mediaserver-volume
              mountPath: "/downloads"
              subPath: "downloads"
      volumes:
        - name: wireguard-config
          configMap:
            name: wireguard-config
        - name: mediaserver-volume
          persistentVolumeClaim:
            claimName: mediaserver-pvc
        - name: init-files-transmission
          configMap:
            defaultMode: 493
            name: init-transmission-cm

To verify this works as expected we can apply the deployment file and test our VPN connection by running curl http://ip.me

1
2
3


kubectl apply -f transmission-deployment.yaml
# After deployment is ready we exec into the pod
kubectl exec -ti transmission-5bbdf688c-g9nkq -c transmission -- curl http://ip.me

Everything seemed to work as expected…or so I thought. Torrenting traffic was going through the VPN tunnel. However, after a few hours I noticed that none of my torrents were seeding properly. Transmission also reported that the port I was using was closed. After more digging I realized that although my Wireguard configuration allowed port-forwarding, that didn’t mean it did the leg work to setup port-forwarding for me. In order to seed my torrents properly, I’d need to setup something called NAT-PMP.

Port-forwarding with NAT PMP

NAT Port Mapping Protocol (NAT PMP), is a network protocol that allows us to establish port-forwarding configurations. You can read the full paper here if that’s the kind of person you are: https://datatracker.ietf.org/doc/html/rfc6886

Having realized that I needed my transmission image to include additional binaries I feared that I would need to setup a private docker repository in order to deploy my own modified version of transmission. While this is something I plan on doing in the future, for the purpose of this project I was less enthused.

I figured there must have been plenty of people with a similar dilemma and after searching Github I came across this issue: https://github.com/linuxserver/docker-transmission/issues/248

It turns out that the linuxserver org has a universal package install repo: https://github.com/linuxserver/docker-mods/tree/universal-package-install

This allows someone to modify the image with additional packages, binaries, etc. at runtime. Someone had already gone ahead and setup a docker mod to support NAT-PMP and all you had to do was add an environmental variable to your deployment. Things are never this easy!

alt

My transmission deployment was modified to include the new environment variable:

48
49
50
51
52
53
54
55
56


- name: transmission
  image: "docker.io/linuxserver/transmission:latest"
  env:
   - name: PGID
     value: "1000"
   - name: PUID
     value: "1000"
   - name: DOCKER_MODS 
     value: "jordanpotter/docker-mods:transmission-nat-pmp"

Before blindly running arbitrary code, let’s at least see what this docker mod is actually doing.

https://github.com/jordanpotter/transmission-nat-pmp/blob/main/main.go#L44-L66

main.go

43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


    ...
	for {
		portMappingTime := time.Now()

		portMapping, err := natpmpClient.AddPortMapping("tcp", 0, int(previousExternalPort), int(time.Hour.Seconds()))
		if err != nil {
			log.Fatalf("failed to add port mapping: %v", err)
		}

		if portMapping.MappedExternalPort != previousExternalPort {
			log.Printf("external port changed to: %d", portMapping.MappedExternalPort)

			previousExternalPort = portMapping.MappedExternalPort

			transmissionPeerPort := int64(portMapping.MappedExternalPort)
			err = transmissionClient.SessionArgumentsSet(context.Background(), transmissionrpc.SessionArguments{
				PeerPort: &transmissionPeerPort,
			})
			if err != nil {
				log.Fatalf("failed to set transmission peer port: %v", err)
			}

			log.Printf("updated transmission peer port to: %d", transmissionPeerPort)
		}
    ...

At a glance, this code is doing two things:

Establishe a port through NAT PMP
Update Transmission to use that port through a Transmission RPC package

Ports through NAT-PMP have a timeout. Having Transmission automatically reconfigured everytime a new port is established is a huge quality-of-life feature for us.

Verification

I redeployed Tranmissions with the newly added environment variable and checked to see that our VPN was still properly setup.

1
2
3
4


kubectl replace -f transmission-deployment.yaml
kubectl exec -ti transmission-5d8647c887-c588l -c transmission -- bash
root@transmission-5d8647c887-c588l:/# curl ip.me
85.292.85.12 # Not a real IP

I then checked the logs to see that the docker mod was running correctly and that a port was now being forwarded.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


kubectl logs transmission-5d8647c887-c588l -c transmission

[mod-init] Running Docker Modification Logic
[mod-init] Adding jordanpotter/docker-mods:transmission-nat-pmp to container
[mod-init] Downloading jordanpotter/docker-mods:transmission-nat-pmp from registry-1.docker.io
[mod-init] Installing jordanpotter/docker-mods:transmission-nat-pmp
[mod-init] jordanpotter/docker-mods:transmission-nat-pmp applied to container
[migrations] started
[migrations] no migrations found
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: 4.0.6-r2-ls280
Build-date: 2025-01-29T15:23:33+00:00
───────────────────────────────────────
    
[custom-init] No custom files found, skipping...
2025/02/01 04:53:38 external port changed to: 48298
2025/02/01 04:53:38 updated transmission peer port to: 48298
Connection to localhost (127.0.0.1) 9091 port [tcp/*] succeeded!
[ls.io-init] done.

I then curl'd canyouseeme.org to see if this port was visible from the outside world:

1
2


root@transmission-5d8647c887-c588l:/# curl -s -XPOST --data "port=48298" https://www.canyouseeme.org/ | grep -E "Success|Error"
    <p style="padding-left:15px"><font color="green"><b>Success:</b></font>&nbsp;I can see your service on <b>85.292.85.12</b> on port (<b>48298</b>)<br>Your ISP is not blocking port 48298</p>

The Transmission service also reported that the port was open.

alt

All checks looked promising, and after a few hours I could see that some torrents were seeding now.

Security

While convenient, this solution has several security considerations. Wireguard is running as a privileged sidecar with special permissions. We are installing a docker mod that has the ability to install arbitrary code onto a pod with elevated access to the host system. The potential for a malicious attack involving privilege escalation is pretty high. Long-term a better, albiet less convenient, solution should be used instead.

In a future post I plan to revisit setting up NAT-PMP and explore possible ways an attacker could exploit a pod with these privileges.