Wireguard

[ylor]

With Wireguard hitting 1.0 and becoming part of the Linux 5.6+ kernel, I'd like to request Wireguard be added in addition or in place of OpenVPN. Mostly for its decreased overhead on CPU limited hosts.

[haugene]

I like it. Just saw the release myself. I've read a couple of blogs about this along the way as it has seemed relevant to this project and you know, just linux computing in general.
I don't have a complete overview on what that would mean for this project though. I can read up, but if you have some knowledge I'm all ears.

The providers have to support it and it's a separate set of configs I guess? Or is there some interoperability here (sounds too good to be true).

[gpongelli]

Hi, I'm also using Wireguard.
As you've pointed out, the VPN provider have to support it because the config file is completely different, it's a conf file with just something like this

[Interface]
PrivateKey = ....
Address = ....
DNS = ....

[Peer]
PublicKey = ....
PresharedKey = ....
Endpoint = ....
AllowedIPs = ....
PersistentKeepalive = ....

[dsbert]

PIA supports it but has not provided any guidance on setting it up outside of their official clients. https://www.privateinternetaccess.com/forum/discussion/38293/wireguard-on-linux

[lxs]

Indeed, PIA's client has option to use the WireGuard protocol.

Not seen similar update yet for the likes of ExpressVPN client, VPNunlimited client, nor external clients.

• Blog post by Express VPN team on topic (last updated 12 April 2019):
  https://www.expressvpn.com/blog/expressvpn-wireguard-update/
• Overview from VPNunlimited team https://www.vpnunlimitedapp.com/blog/introducing-wireguard-vpn-protocol/
• Arstechnica's comments on WireGuard's recent release (March 2020):
  https://arstechnica.com/gadgets/2020/03/wireguard-vpn-makes-it-to-1-0-0-and-into-the-next-linux-kernel/
• List of formal verification of WG https://www.wireguard.com/formal-verification/ - with INRA (FR) publishing their machine-checked proof of the protocol https://hal.inria.fr/hal-02100345

[webnetwiz]

Looks like NordVPN is officially supporting WireGuard natively now: https://nordvpn.com/blog/one-very-strong-reason-to-be-excited-about-nordlynx/

[pkishino]

PrivateVPN are doing testing currently

[UltraSub]

Mullvad is also supporting and advising Wireguard:
https://mullvad.net/en/help/tag/wireguard/

[frankyw]

Torguard also supports Wireguard, and the speed difference is significant. An option to use Wireguard instead of OpenVPN would be awesome.

[ksurl]

vpnunlimited also supports wireguard with config file option

[adamtmitchell]

FYI VPN.ac also support Wireguard since March last year: https://vpn.ac/knowledgebase/120/WireGuard-Status.html

[Elliptic1503]

Windscribe also support WireGuard.

https://windscribe.com/getconfig/wireguard

[PaulR1978]

I too would like to see this docker start using wireguard. I've looked into this, and I found some scripts that will do the connection and get the tokens for wireguard to connect. I hope these scripts will come in handy, really looking forward to using wireguard in this docker!

PIA:
https://gist.github.com/triffid/da48f3c99f1ff334571ae49be80d591b
https://serverlist.piaservers.net/vpninfo/servers/new

Cheers, and thanks for the great work!

[mattstrayer]

That's fantastic work @PaulR1978. @haugene I'd be happy to lend a hand on implementation.

[varac]

There are a few wireguard docker containers which might be a good guidance how wireguard could be configured in a docker context, i.e. https://hub.docker.com/r/linuxserver/wireguard

[haugene]

Great stuff 👍 Thanks for posting, I think these links will be great during implementation!

I'm really looking forward to implementing this and would love some assistance @mattstrayer.
As for the timeline. I think it will still be postponed a few weeks, but we should get this in during the autumn.

There are two reasons I want to wait just a little. One of them is that I live in the North (Oslo) and we're probably getting the last wave of warm weather these days. So it's a bit selfish, but the rain and cold is coming and then there will be more time for coding then. Unnecessary sacrifice of points with the gf to insist on locking myself in my room in the sun.

But, secondly and more important. We are doing a rewrite of the project structure now. That work has begun on the dev branch and I have another feature branch in the works. The idea is to make the project more modularised so that everything isn't such a "lump" as it is today. The scripts have just grown with new features and now is the time to extract some of the functionality and handle it more generally. At the end of this I also think that the separation between openvpn and transmission will be clearer, so it would be easier to swap the startup from openvpn to wireguard.

Once I have merged the next big feature branch I will create a feature branch for wireguard, and then I'm happy to accept and play with any PRs to see how we can build this. But I think there will be many merge conflicts if we start before that. Anyways, let's aim for having Wireguard a part of the 3.0 release of the image 😄

[amosshapira]

I couldn't wait, and last night I gave it another shot - that is - I took the plunge and tried to get "Transmission + Torrent + Wireguard" running and sort of succeeded.

Are there any bits of code/configuration you can share which can help progress this ticket? Perhaps push them to a fork and link from here?

Thanks.

[MrEaoP]

I don't mind sharing what little I have accomplished at all, I just don't know if this thread is the right place to write a little guide in. Seeing as it my approach doesn't involve "haugene/docker-transmission-openvpn" but instead three other containers.

I just don't want to "clutter" this thread with information that's not relevant to getting a "haugene/docker-transmission-wireguard".

I've never forked in my life, but maybe that is the right way to go - I'll look into it :)

[ksurl]

You could start a post in the discussion section.

[Xaelias]

I don't know how helpful I can be but if there is anything that can be done to help move forward w/ this I'm happy to try and give a hand :-)

[jes1417]

IPvanish has officially made Wireguard the default VPN connection in their Android app today.

[haugene]

Hey guys 👋

I finally got around to actually coding something here, and since I'm using PIA as my provider that is the one I've implemented (limited) support for now. I hope that some of you will test it and that we can have a discussion on how to implement more providers here.

First. What has been implemented?
This container supports a lot of environment variables, and I have ignored many of them in this first version. So I don't have port forwarding, the pre/post scripts, ufw, UID/GID, or stuff like that implemented yet. To be able to access the WebUI I did have to implement LOCAL_NETWORK, so that's in place - but it does not support multiple entries so far. Just a single CIDR address.

Something like this should hopefully work 🤞

version: '3.3'
services:
  transmission-vpn:
    container_name: openvpn
    image: haugene/transmission-openvpn:wireguard
    ports:
      - 9091:9091
    environment:
      - VPN_PROTOCOL=wireguard
      - VPN_PROVIDER=pia
      - VPN_REGION=Denmark
      - VPN_USERNAME=user
      - VPN_PASSWORD=pass
      - LOCAL_NETWORK=192.168.0.0/16
    privileged: true
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    logging:
      driver: json-file
      options:
        max-size: 10m

NB: Before you mount any volumes... As the UID/GID support is not in place yet, Transmission is run as root and any downloaded files will be owned by root as well. Stuff can happen to your transmission-home folder if you mount your existing setup directly. So think twice before doing that.

What's the next steps?
I don't think that the code I've written for PIA is automatically a good candidate for other providers. But I'm curious to see how other providers facilitate a manual WireGuard setup outside their apps.
As WireGuard requires the client to know it's VPN network IP before connecting means that there has to be some kind of exchange/communication before we actually connect. I see that it has been mentioned here that many providers let you download a wg0.conf file and that it can be mounted into the container. That would be a very simple feature to add and should probably be the universal setup-guide.

But then there are providers like PIA where you need to auth, get a token and fetch the IP from the server you're about to connect to. Then we need some scripting. Should there be any common tooling, or just implement it per provider?

As you can see from the wireguard branch I've written this new code in Python. I'm tempted to migrate this project to Python as the scripting language. It has some overhead but it's nice to write in a language that is easier to read and has more library support. WDYT?

[pkishino]

nice work,
I'll test it out when I have some time.
Overall a move to python would be nice. Coupled with a rework of various areas (network stack etc) this would be good for longterm support.

[amosshapira]

👍 for moving to Python 3.9+

I'll try to get around to test this with my provider (not PIA) on the weekend.

[garret]

May I ask:

1. How come the privileged option? Is it necessary because wireguard needs to interface with the kernel module on the host?

2. Does wireguard needs to be installed in the host device? For instance, I would like to use such container on my raspberry pi 4 and wireguard is not "officially" present in the raspberry pi os repo.

[haugene]

May I ask:

1. How come the privileged option? Is it necessary because wireguard needs to interface with the kernel module on the host?
2. Does wireguard needs to be installed in the host device? For instance, I would like to use such container on my raspberry pi 4 and wireguard is not "officially" present in the raspberry pi os repo.

1. It's because of the AllowedIPs = 0.0.0.0/0 line in the config. Changing that to a couple of /16 address spaces it runs fine without privileged. When running with 0.0.0.0/0 and non-privileged this command fails

[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
sysctl: setting key "net.ipv4.conf.all.src_valid_mark": Read-only file system

2. I booted a plain ubuntu 20.04 VM and ran the container, no need to install wireguard on the host. I have not tried on a host with a kernel that's older than 5.6 though. But I expect that to fail, you have to have the kernel support I assume.

[haugene]

+1 for moving to Python 3.9+

I'll try to get around to test this with my provider (not PIA) on the weekend.

As of now we're using python version 3.8. It seems to be the default in the package repo for Ubuntu 20.04 which is our base.
We want to have an LTS view on the versioning and will not upgrade unless there are huge gains by doing it. As far as I know we don't have a need for 3.9 instead of 3.8.

But I'm noting a positive attitude towards Python here, so I'll continue on that track 👍

[haugene]

Following up on the post above. I just pushed some new changes that allows for mounting a WireGuard config file for the container to use. I signed up for a month of Mullvad service and that's how they do it. You log on and download the config you want.

I had to remove the IPv6 part of the Address and AllowedIPs sections. Will look into that later.
After that edit it seems to run fine with this compose:

version: '3.3'
services:
  transmission-vpn:
    container_name: openvpn
    image: haugene/transmission-openvpn:wireguard
    volumes:
      - ./mullvad-dk6.conf:/etc/transmission-vpn/wireguard/wg0.conf:ro
    ports:
      - 9091:9091
    environment:
      - VPN_PROTOCOL=wireguard
      - LOCAL_NETWORK=192.168.0.0/16
    privileged: true
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    logging:
      driver: json-file
      options:
        max-size: 10m

Compared to the config above there are two changes. I'm not setting any of the provider specific environment variables and that will trigger the container to look for a config at /etc/transmission-vpn/wireguard/wg0.conf instead. The container will copy the config from there and into /etc/wireguard/wg0.conf where wg-quick expects to find it. The reason I opted to copy it is that we need to modify it to get the LOCAL_NETWORK working and I don't want to edit the actual file that a user has mounted. So the config file can be read-only as in my example.

Hopefully this will enable a lot more to do some testing 😄

Next steps in the development is probably to get a better code structure and find an elegant way to dynamically load provider specific code (if any) without doing if/elif/elif/elif/else for all the possible providers. I've started something, but let's see where it goes. And then I guess it's time to start looking at UID/GID as well as port-forwarding for PIA after that.

[ksurl]

having the same issue. set the subnet to the same as the host, not the docker network.

[blasphemite]

what is the IP of the docker host ? thats the url you should be using.. e.g my docker host ip is 10.1.125.8, the container ip is 172.10.1.2.. LOCAL_NETWORK is 10.1.125.1/24 I access the UI using 10.1.125.8:9091

Docker host IP is 10.20.0.21, but I can't connect to 10.20.0.21:9091 with LOCAL_NETWORK set to 10.20.0.0/24

[karlhaworth]

I added the below to my wg0.conf file to get this working under the interface section.

PostUp = ip route add 10.0.6.0/24 dev eth0 && ip route add 10.1.0.0/16 dev eth0

In my deployment env vars I have the below.

            - name: LOCAL_NETWORK
              value: 10.0.6.0/24,10.1.0.0/16

[ksurl]

Are those your lan and docker subnets?

[karlhaworth]

LAN and kubernetes subnets

[ksurl]

btw it looks like some of the transmission setting overrides work in the wireguard build:

      - TRANSMISSION_DOWNLOAD_DIR=/downloads/complete
      - TRANSMISSION_INCOMPLETE_DIR=/downloads/incomplete
      - TRANSMISSION_WATCH_DIR=/watch
      - TRANSMISSION_HOME=/config

[braymullo]

Curious to know if this has gained any more interest? Thanks again for the great work

[edgd1er]

As for using wireguard with Nordvpn, there is no easy integration in the project.
Nordvpn uses a proprietary technology base on wireguard named nordlynx.

A possible setup, would be to use a first container based on https://github.com/sfiorini/NordVPN-Wireguard script to generate wireguard configuration, then a simple env settings should be enough to use wireguard with this project (when ready ;) )

Integrating these two (non existing at the moment) containers into one, would had too many nordvpn specific files into a "generic" project. I guess the maintainers will not be fond of.

[UniverseXXX]

I’m trying to setup this Wireguard container with Mullvad on Ubuntu 22.04 and getting the following error:
ip6tables-restore v1.8.4 (legacy): ip6tables-restore: unable to initialize table 'raw'
is there something what needs to be updated within the container?
thanks

[tmknight]

Any updates on haugene supported implementation of Wireguard, particularly for NordVPN?

[edgd1er]

Any updates on haugene supported implementation of Wireguard, particularly for NordVPN?

You may wish to test a container based on haugene + wireguard + nordvpn client: https://github.com/edgd1er/nordlynx-transmission

Nordvpn has special settings, user specific, that need to be extracted from times to times from a nordvpn'client connexion. I m not sure haugene will be eager to add such specific provider package. Once these informations are obtained there is no need of the nordvpn package.

[DuncanTheFox]

For NordVPN/NordLynx could this simple script be implemented?

#!/bin/bash
my_interface=$(sudo wg show | grep interface | cut -d" " -f2)
my_privkey=$(sudo wg show $my_interface private-key)
my_ip=$(ip -f inet addr show $my_interface  | awk '/inet/ {print $2}')

read host ip city country serv_pubkey < <( echo $(curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=1" | jq -r '.[]|.hostname, .station, (.locations|.[]|.country|.city.name), (.locations|.[]|.country|.name), (.technologies|.[].metadata|.[].value)'))

sid=$(echo $host | cut -d. -f1)
fn="nvpn_"$sid".conf"
echo Server: $host \($ip\) has pubkey $serv_pubkey

echo writing config to $fn
echo "#config for nordvpn server $sid"  > $fn
echo "[Interface]"                      >> $fn
echo "Address = $my_ip"                 >> $fn
echo "PrivateKey = $my_privkey"         >> $fn
echo ""                                 >> $fn
echo "[Peer]"                           >> $fn
echo "PublicKey = $serv_pubkey"         >> $fn
echo "AllowedIPs = 0.0.0.0/0"           >> $fn
echo "Endpoint = $host:51820"           >> $fn

echo ""
echo "Content of $fn:"
cat $fn

qrencode -t ansiutf8 < $fn

# uncomment this line to automatically copy the .conf to the wg directory, then you can use it directly with "wg-quick up nvpn_xy1234"
sudo mv $fn wireguard && sudo chmod 600 /etc/wireguard/$fn

The qrencode could of course be omitted.

Result:

#config for nordvpn server nl878
[Interface]
Address = 10.253.0.1/32
PrivateKey = OHRagb6ERveDeDeenneeEEI8ePpcZAccItOaYFM2Kv4OEs=

[Peer]
PublicKey = 5p4EEbdRU5uaDi90eu4KZPTFifEECg4Qp6t1CCFLLL=
AllowedIPs = 0.0.0.0/0
Endpoint = nl878.nordvpn.com:51820

The Keys have been obfuscated.

No reason anymore to let NordVPN users create their own - always the same - and therefore "insecure" and slow Wireguard configs. Imho.

[braymullo]

Hey, getting this error:

tarting container with revision: 25f3444cc13bd1cde6b9c932ec32a4eb93b63084 Running custom startup script for PIA Will try to connect to region Denmark Traceback (most recent call last): File "/opt/transmission-vpn/main.py", line 12, in <module> pia.setup() File "/opt/transmission-vpn/providers/pia/main.py", line 16, in setup pia_region = find_region(pia_servers, preferred_region) File "/opt/transmission-vpn/providers/pia/utils.py", line 58, in find_region raise KeyError(f"Could not find region {region_name} in region list") KeyError: 'Could not find region Denmark in region list'

Checking to see if it's something I've done or because this fireguard branch is just not working :)

[haugene]

For anyone still interested in the implementation here, I've made another attempt at it. Opened a new discussion here: #2608

I suggest we close this one and move the conversation as there's a new image to test and this is a bit outdated now