Open qdm12 opened 4 years ago
Excited to see this under consideration. With wireguard being merged into the 5.6 kernel, it would be awesome to see kernel space support in addition to user space support via the wireguard-go.
Assuming the host's kernel is 5.6+ (or has been backported like in Ubuntu or Debain), I believe you could install wireguard in the container with apk add -U wireguard-tools
. Then when you run the container, add --cap-add sys_module
to give access to the wireguard kernel module.
It looks like there are a couple of examples (cmulk/wireguard-docker and activeeos/wireguard-docker) that attempt to even install the OOT kernel module in the host. Instead of doing that, maybe it would make the most sense to enable kernel support for hosts running 5.6+ / backported wireguard and wireguard-go for hosts running earlier kernels? π
Wireguard's official container framework is probably the most performant, but doesn't look particularly docker-friendly since it requires a lot of host-level config. I'd guess sharing the kernel module would still be more performant than wireguard-go, but I haven't done any testing. For what it's worth, it looks like wireguard-go has come a long way in the last few months.
Hi there, thanks for the good read π
So wireguard-go is probably fast enough for pretty much any personal need. It might not be suitable if you have huge loads and multiple clients. But Go is very quick at networking things, it is a system language originally.
There is also a Rust version of Wireguard the team is developing, which is again faster, as fast or faster than C, so it should be very close to the kernel space implementation although it could run in a container in user space.
We could indeed add instructions on how to use the kernel space Wireguard if you have it setup on your host, that would be a nice addition.
Cool, sounds good to me. Also I just noticed that LinuxServer.io added a Wireguard container last month here: linuxserver/docker-wireguard. In case it's helpful.
@burkasaurusrex Thanks, unfortunately it's the same problem I want to avoid:
This image is designed for Ubuntu and Debian based systems only. During container start, it will download the necessary kernel headers and build the kernel module (until kernel 5.6, which has the module built-in, goes mainstream).
For now it seems only kernel based docker images exist out there which seem pointless to me, you might as well just run it without Docker in that case. Luckily a Go version exists (and a Rust one too) which can work across platforms, cpu arch and kernels :wink:
There is also a NordVPN docker container that uses Wireguard... https://github.com/bubuntux/nordvpn they call it "NordLynx" if that helps any. Doesn't seem to do any voodoo on the host...
NordLynx - NordVpn wireguard implementation (3x-5x times faster). NOTE: Requires --cap-add=SYS_MODULE and --sysctl net.ipv4.conf.all.rp_filter=2
It installs Wireguard on your host kernel --cap-add=SYS_MODULE
, not really a big fan of giving access to the Kernel to a container (even mine π). Gluetun already has net admin capability and runs the entrypoint as root (no way around it) but I would ideally like to avoid it for security reasons. Especially since it does tunneling to vpn servers which are not the safest places either (i. e. other VPN malicious clients). But I'll plug in the Go implementation of Wireguard (Windows GUI uses it too), it should give fast enough performance and won't require to modify the kernel. I did Shadowsocks in Go last weekend (#220) to replace the C Alpine one, this weekend will be about being able to persist and update ip addresses of vpn servers (for now it's hardcoded). I can try doing Wireguard next or next next weekend π
https://www.youtube.com/watch?v=wv_phi5Z288
On Sat, Aug 22, 2020 at 3:18 PM Quentin McGaw notifications@github.com wrote:
NordLynx - NordVpn wireguard implementation (3x-5x times faster). NOTE: Requires --cap-add=SYS_MODULE and --sysctl net.ipv4.conf.all.rp_filter=2
It installs Wireguard on your host kernel --cap-add=SYS_MODULE, not really a big fan of giving access to the Kernel to a container (even mine π). Gluetun already has net admin capability and runs the entrypoint as root (no way around it) but I would ideally like to avoid it for security reasons. Especially since it does tunneling to vpn servers which are not the safest places either (i. e. other VPN malicious clients). But I'll plug in the Go implementation of Wireguard (Windows GUI uses it too), it should give fast enough performance and won't require to modify the kernel. I did Shadowsocks in Go last weekend (#220 https://github.com/qdm12/gluetun/pull/220) to replace the C Alpine one, this weekend will be about being able to persist and update ip addresses of vpn servers (for now it's hardcoded). I can try doing Wireguard next or next next weekend π
β You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/qdm12/gluetun/issues/134#issuecomment-678640218, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFHXQC66AJCVCN36BYCPXU3SB7ASPANCNFSM4MGNIPWA .
Sorry everyone for the big delay. I'm working hard on getting Wireguard ready for Mullvad and PIA.
I have some pre-pre-alpha program based on the official Go wireguard Code. It's quite nice since it tries to use the Kernel wireguard module if it's there and otherwise falls back to a Go implementation (which is also decently fast). So performance should be quite nice.
Anyway, I'll report back with image tags and instructions especially to test it for other providers than Mullvad. Cheers!
It's quite nice since it tries to use the Kernel wireguard module if it's there and otherwise falls back to a Go implementation (which is also decently fast).
That's probably the best way to do it, awesome! Looking forward to it.
Do you plan to add Wireguard for GyberGhost VPN too? I checked both OVPN and Wireguard protocols with their app and Wireguard one is 3 or more times faster, when with OVPN i reach 100 Mbit with Wireguard i reach 300 ...
Will NordLynx (the protocol used by NordVPN, which seems to be based on Wireguard) be supported? π
@VP-EN See @lavaguy1's comment it should be possible although I haven't looked at it yet.
@VP-EN @VMax2 I have added an order of support for Wireguard in the issue description above.
Thank you so much
I have a question that you can answer for your VPN provider. So far for Mullvad:
Address
is user specific onlyPublicKey
is server specific onlyPrivateKey
is user specific onlyEndpoint
is server specific onlyAllowedIPs
is the same for all (tunnel everything) and we don't care about DNS
since we use DNS over TLS in gluetunso I would like to have environment variables WIREGUARD_PRIVATE_KEY
and WIREGUARD_ADDRESS
only. The rest (publicKey and Endpoint) is server specific and I can automate it without needing user input, I hope.
How is it for PIA, Cyberghost and NordVPN? (download multiple config files and check what's common or not really). Thanks!
Anyway, I made some good progress today, almost there. I have it working for a single Mullvad server and it tunnels everything correctly. What's nice is it really doesn't cry about sysctl or kernel modules unlike wg-quick
. Although I still need to wire it up with the rest and find a way to get the server public keys automagically too π
Related to the ones testing NordVPN.. The WireGuard configs are not available in their server config download tool. You need to use their Linux version of their NordVPN app to get the WireGuard configs.
A small reddit guide here
Not sure if I have the time in the near future, as I don't have a Linux device available atm to test this method.
@VP-EN OK I think I should design something to easily extract that information. I guess some debian based image with nordlynx and wireguard installed and some shell scripting would do (e. g. qmcgaw/gluetun:nordvpn-extract
). Problem is that would most likely require you to have wireguard in your Kernel, which can be troublesome for some odd systems like NAS OSes. But I guess that's how nordlynx works (using the kernel) so no way around it. I'll let you know when I have something so you can test it out.
Related to PIA, the WireGuard configs are also not available for download. However, I did find this repo with information/scripts on how to create the WireGuard connections.
I see this script for PIA, requiring
Hostname and IP can be found at https://serverlist.piaservers.net/vpninfo/servers/v5, PIA token is user specific.
The rest is generated on the fly and obtained from their API, so I can code all this in gluetun π
So I think the only part needed would be WIREGUARD_PIA_TOKEN
as an env variable for it to work with gluetun.
So I think the only part needed would be
WIREGUARD_PIA_TOKEN
as an env variable for it to work with gluetun.
In this script the token is generated with a call to https://privateinternetaccess.com/gtoken/generateToken using the PIA_USERNAME
and PIA_PASSWORD
.
what about Windscribe WireGuard? They have a config file for WireGuard.
and it is structured like this
[Interface]
PrivateKey =
Address =
DNS = 10.255.255.4
[Peer]
PublicKey = uFOg97vQhHVCUfZy/HwmGH+dR6/9lpeWZ5tV3PysHRE=
AllowedIPs = 0.0.0.0/0
Endpoint = zrh-112-wg.whiskergalaxy.com:65142
PresharedKey =
@marciocm thanks, yeah I use that to get the PIA port forwarded, it shouldn't be too hard changing it.
@blckwhtx thanks for the help! From their API they also provide the wg_pubkey
so that's good. However, a few important questions:
100.92.150.12/32
assigned? Do you have the same for all servers or is it by server?PresharedKey
given, is it by server or common to all servers?65142
common to all servers? Or is it by server?I'm still working on integrating Wireguard with Mullvad, this obviously takes the longest since it requires more code changes than the integration of subsequent providers.
I am also re-ordering the order of VPN providers to integrate with Wireguard from easiest to hardest (see above). I might do Windscribe before PIA depending on the answers of @blckwhtx
@blckwhtx that's perfect. I'll do Windscribe after Mullvad then since it's the simplest in the list. So for Windscribe, you'll have to set:
WIREGUARD_PRESHARED_KEY
WIREGUARD_PRIVATE_KEY
WIREGUARD_ADDRESS
(100.92.150.12/32
in your case)With optional:
WIREGUARD_PORT
(defaults to 65142
I guess?)And use the existing variables to filter servers to use.
Maybe later on add a parsing feature to extract those values automagically from a Wireguard file bind mounted; although these variables should not change once set really so not it's not a big need either.
port 80, 443, 53 are mostly in use, that's why I took 65142
For whoever use Mullvad, you can (finally duh!) run it in beta. It looks quite stable to me so far, but I haven't done much testing yet.
docker run -it --rm --name gluetun --cap-add=NET_ADMIN -e VPNSP=mullvad -e VPN_TYPE=wireguard \
-e WIREGUARD_PRIVATE_KEY="yourbase64key" -e WIREGUARD_ADDRESS="1.2.3.4/32" \
qmcgaw/gluetun:wireguard
π note that that image tag :wireguard
is not permanent, and only lives whilst the Wireguard PR is in development. I'll merge it in qmcgaw/gluetun
once it supports as many providers as possible from the already supported providers.
@blckwhtx Windscribe should now work. Try with -e VPNSP=windscribe
and the same command as above, substituting your private key and address there. You can also use WIREGUARD_PRESHARED_KEY
if you have one set (also valid for Mullvad).
Now I'm trying to squash and merge Wireguard for the repo's 1000th commit (we're at 996!), a few more providers to go! I may skip ones that are troublesome for this initial PR though (maybe nordvpn for example).
@blckwhtx Windscribe should now work. Try with
-e VPNSP=windscribe
and the same command as above, substituting your private key and address there. You can also useWIREGUARD_PRESHARED_KEY
if you have one set (also valid for Mullvad).Now I'm trying to squash and merge Wireguard for the repo's 1000th commit (we're at 996!), a few more providers to go! I may skip ones that are troublesome for this initial PR though (maybe nordvpn for example).
I get an error message 2021/08/20 14:46:41 ERROR vpn: failed creating Wireguard: public key is missing
public key is missing -e WIREGUARD_PUBLIC_KEY
- VPNSP=Windscribe
- VPN_TYPE=wireguard
- WIREGUARD_PRIVATE_KEY=
- WIREGUARD_ADDRESS=
- WIREGUARD_PRESHARED_KEY=
- WIREGUARD_PUBLIC_KEY=we still need to test it
That was a bug, sorry. I fixed it now, you can try by repulling the image. Note that the public key is specific to each server and is saved in https://github.com/qdm12/gluetun/blob/wireguard/internal/constants/servers.json (built in the program and also mirrored in /gluetun/servers.json
)
Managed to get Linux machine up and running.. @qdm12 - Here's a sample of a few NordVPN (NordLynx) WireGuard configs: https://0bin.net/paste/2hyZ2DuE#WneS0jdmJimiNsHPMR8Fa5wr-xidSJ8bkCBfxZO+P6I
I hope it's useful. If you need other information, just ping me :+1:
VPN is running that's perfect other containers have internet access via vpn
but you can't access the UI via the shared ports
thanks for your work
@blckwhtx indeed, there is some routing issue I think.
For OpenVPN I get
$ ip route
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 172.17.0.1 dev eth0
10.8.0.0/16 dev tun0 proto kernel scope link src 10.8.0.18
89.36.78.18 via 172.17.0.1 dev eth0
128.0.0.0/1 via 10.8.0.1 dev tun0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
$ ip rule
0: from all lookup local
100: from 172.17.0.2 lookup 200
32766: from all lookup main
32767: from all lookup default
Where 89.36.78.50
is the VPN server IP, 10.8.0.0/16
is the tun0 addresses assigned, and 172.17.0.2
is my Docker network IP address.
For Wireguard I get
$ ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
$ ip rule
0: from all lookup local
99: not from all fwmark 0xca6c lookup 51820
100: from 172.17.0.2 lookup 200
32766: from all lookup main
32767: from all lookup default
Now I just need to play around with it... If you want to play around too to find what we need, you can with docker exec gluetun ip route
(or ip rule
). It might just be because of the ip rule
, Wireguard seems to use that fwmark
rule which comes before our rule 100
(access from outside ports)
EDIT: I think I figured it out...
It's fixed now π It was indeed an ip rule priority issue
On to the next provider!
Tested this with 7 Windscribe locations, worked great. Could you make it possible to add the private and preshared keys via a secret, like is currently possible for openvpn usernames and passwords?
Hi,
Thanks for this project ! I'm new to WireGuard. I'm assuming WIREGUARD_ADDRESS env var should be set to the Address referenced in the [Interface] section of the config file downloaded from Mullvad ?
I'm not sure as well how i can target which server/endpoint i would like to connect to ? In your docker command exemple it seems you only supply the address and private key, but not the endpoint target address (or public key, if that's necessary) ?
Thanks !
Hi @romainguinot
I'm assuming WIREGUARD_ADDRESS env var should be set to the Address referenced in the [Interface] section of the config file downloaded from Mullvad
Yes. It's also the same by user/private key combination, so you should only have to set it once.
I'm not sure as well how i can target which server/endpoint i would like to connect to ?
Use existing filter environment variables, for example with -e CITY=Stockholm,Brussels
(it will pick one of the two at random)
I'm updating the Github Wiki now with Wireguard information
@nearcatch I'll create an issue for files/secrets once #565 is merged.
@VP-EN Cool thanks! The problem is the public key, can you try re-connecting to the same server with a few hours of interval, do you get the same public key? Also if you try wg showconf wg0
do you get the interface address? That's something missing from your logs I think.
Anyway, I'll merge that first pull request #565 soon and add more providers then, since there are dependencies on other PRs. I also updated the order of support above (from easiest to hardest to implement). I also updated other TODOs to do after merging it, in the issue body above.
@qdm12 The public keys seem to vary from city to city. If only a single city is available in a country, the whole country seems to share the same public key. E.g. public key differs from Berlin / Frankfurt - but in a country with only one city, the public key is the same.
Log from 20/08/21: https://0bin.net/paste/2hyZ2DuE#WneS0jdmJimiNsHPMR8Fa5wr-xidSJ8bkCBfxZO+P6I
Log from today (22/08/21) edit: added more city logs https://0bin.net/paste/wM-LmbpM#de0lRa5ATFraDLbwyrQexbNdBM7zzoikjdkvu1CS9Kg
Edit: Obviously removed the private key from the logs. They have changed from last time I connected, but I guess that's expected behavior
Using wg showconf wg0
and/or sudo wg showconf wg0
reports:
lnx@lnxlptp:~$ sudo wg showconf wg0
Unable to access interface: No such device
Not sure what to do about that tbh :confused:
@qdm12 Thanks for your quick reply !
I was able to test it earlier and all seems to be working great, with really great speeds even when selecting another country. And i'm running it on a Synology NAS which has a 4.4 kernel, so i sort of expected the performance to not be great without the in-kernel stuff that appeared as of 5.6 iirc. I was planning to compare with OpenVPN but given these results there is no need. I will just repull the container when the wireguard support has been merged into latest.
I chose to route the necessary containers network through gluetun's container network rather than using a proxy, presumably with less overhead but i haven't compared both scenarios. At the moment i don't have a need to have other LAN devices routed through gluetun.
I also expected the performance to drop significantly when not picking the closest city, but even when picking a city from a neighbouring country the performance is more than ample enough.
I was wondering if it was able to select a wireguard server solely by providing a CITY/COUNTRY but i guess this is what the VPN_TYPE is there for, since Mullvad has different types of servers within the same location.
Thanks again for the hard work !
@VP-EN nice thanks. Don't worry too much yet, I'll get back to you when I fiddled with nordvpn more. We do need some way to easily extract values using their nordlynx application anyway. Public keys are expected to be unique by server, I doubt they would change them over time. If the private key and interface address are the same for all servers, it would be ideal such that the extraction only need to run once. Otherwise, I think there is little point adding native support in gluetun and having a way to extract the Wireguard config and plug it as a file in gluetun would be best (as it would be the same difficulty user-wise).
@romainguinot thanks for the feedback!
And i'm running it on a Synology NAS which has a 4.4 kernel, so i sort of expected the performance to not be great without the in-kernel stuff that appeared as of 5.6 iirc.
Nice! Good to know performance is great using the user space code as well. Also note wireguard uses all CPU cores so it gets faster with more cores (in case you need it).
this is what the VPN_TYPE is there for, since Mullvad has different types of servers within the same location.
Yep, although usually a single Mullvad server supports both openvpn and wireguard. It's more required so gluetun knows what to use. I decided to have it like that rather than act as a filter (meaning it would pick openvpn or wireguard at random).
Thanks @qdm12 ! I was looking at mullvad's server list and noticed the wireguard servers had a -wireguard in the hostname so that's why i was wondering if anything had to be specified for these or not, but it does pick a wireguard server without specifying a hostname so no issue there.
Do you know if there is anything to consider regarding the private key rotation or it's not considered necessary ? Assuming mullvad has an API for that, it could probably be scripted to change the container's environment variable / restart it with some reasonable frequency, or even done inside of gluetun itself, but it's maybe overkill (not familiar enough with wireguard to know if that's useful or not).
Hi @qdm12, Thank you again for the wonderful docker container. I will be very happy to test the "Read custom Wireguard configuration file" when it is available. Having a single lightweight docker container which can handle any OpenVPN and WireGuard tunnels with HTTP proxies, SOCKS and all would be really awesome. Best, OP
The Vpnunlimited wireguard config is just a conf file download so supporting the custom config would cover it
@romainguinot
Do you know if there is anything to consider regarding the private key rotation or it's not considered necessary
No idea. Does Mullvad rotate private keys, or are you trying to rotate private keys yourself? It could be an interesting feature such as i.e. have WIREGUARD_PRIVATE_KEY
accept a comma separated list of keys and restart wireguard periodically to rotate them, although probably not a priority for now. I added it to the Extra todos section up there.
@Astroamadeus
Thanks!
I will be very happy the test the "Read custom Wireguard configuration file" when it will be available.
What VPN provider are you using? Note the custom configuration will be restricted to client tunneling only, and not run as a Wireguard server. Although I have also thoughts about running another Wireguard as a server inside gluetun so you could connect LAN devices to it through Wireguard as well... but that for another day π
Wireguard support for ivpn is up on :latest
@ksurl
The Vpnunlimited wireguard config is just a conf file download so supporting the custom config would cover it
Actually whilst we're at it!...
Can you generate a few Wireguard configs for different servers and find out the following:
Interface
's Address
the same for all configurations? If yes, continue:Interface
's PrivateKey
the same for all configurations? If yes, continue:PresharedKey
given, is it the same for all configurations? If yes, continue:Endpoint
port the same for all configurations?If any is different, then it will have to be a custom configuration file as a bind mount. Otherwise we could find our way with env variables that you set once for your account (better I think).
What VPN provider are you using? Note the custom configuration will be restricted to client tunneling only, and not run as a Wireguard server. Although I have also thoughts about running another Wireguard as a server inside gluetun so you could connect LAN devices to it through Wireguard as well... but that for another day π
I am using TorGuard personally. Their configuration files for WireGuard clients look like this, in case it can help :
# TorGuard WireGuard Config
[Interface]
PrivateKey = XXXXXXXXX
ListenPort = 51820
DNS = 1.1.1.1
Address = 10.13.X.X/24
[Peer]
PublicKey = XXXXXXXXX
AllowedIPs = 0.0.0.0/0
Endpoint = 93.177.X.X:1443
PersistentKeepalive = 25
Between several configuration files:
Best, OP
@Astroamadeus thanks, we'll use a custom configuration file for it then.
If anyone is using Surfshark (maybe @frepke right?), can you try the image qmcgaw/gluetun:surfshark-wireguard
with
docker run -it --rm --name gluetun --cap-add=NET_ADMIN -e VPNSP=surfshark -e VPN_TYPE=wireguard \
-e WIREGUARD_PRIVATE_KEY="yourbase64key" -e WIREGUARD_ADDRESS="1.2.3.4/32" \
qmcgaw/gluetun:surfshark-wireguard
Also a few extra questions for Surfshark
51820
(default Wireguard) but I'm not sure.Thanks!
@Astroamadeus thanks, we'll use a custom configuration file for it then.
If anyone is using Surfshark (maybe @frepke right?), can you try the image
qmcgaw/gluetun:surfshark-wireguard
withdocker run -it --rm --name gluetun --cap-add=NET_ADMIN -e VPNSP=surfshark -e VPN_TYPE=wireguard \ -e WIREGUARD_PRIVATE_KEY="yourbase64key" -e WIREGUARD_ADDRESS="1.2.3.4/32" \ qmcgaw/gluetun:surfshark-wireguard
Also a few extra questions for Surfshark
- Do you know what endpoint port they use? I have set it to
51820
(default Wireguard) but I'm not sure.- Is your Wireguard private key common to all server configurations? (I was hoping so)
- Is your Wireguard interface address common to all server configurations? (I was hoping so as well)
Thanks!
Didn't know Surfshark has Wireguard support for a manual setup, so I don't know (jet) where to find the Wireguard config file from Surfshark. If I've got the info, I can test the image.
VPN providers support
Natively
Using provider
custom
Supported since 8645d978ba84b68a012356a0e5d40a770d487803 using
VPN_SERVICE_PROVIDER=custom
Requires API
This is not done, and requires API communication to get the Wireguard keys etc.
Wireguard not supported
Extraction needed
This requires to extract the wireguard config from their proprietary app. Let's face it, this is a lot of work for little result, and I might never get to it. But here is the list still:
following supported devices using VyprVPN version 4.0 and higher and Wireguard is not available to configure with Manual setup
Extra todos
openvpn
orwireguard
depending on VPN chosen instead ofvpn