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

[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 ? ^^