This looks very useful for torrenting through a VPN, I currently have WireGuard outside of Docker and run my torrent client container with network_mode: host for improved network performance.
In order to have the client use the VPN but keep the rest of the system accessible outside the VPN I bind the client IP (VPN IP4 & IP6) in the client config and have WireGuard setup like this:
[Interface]
PrivateKey =
Address = IP4, IP6
DNS =
Table = 12345
PostUp = ip -4 rule add from IP4 table 12345
PostUp = ip -6 rule add from IP6 table 12345
PostUp = iptables -I OUTPUT -s IP4 ! -o %i -j DROP
PostUp = ip6tables -I OUTPUT -s IP6 ! -o %i -j DROP
PostDown = ip -4 rule del from IP4 table 12345
PostDown = ip -6 rule del from IP6 table 12345
PostDown = iptables -D OUTPUT -s IP4 ! -o %i -j DROP
PostDown = ip6tables -D OUTPUT -s IP6 ! -o %i -j DROP
[Peer]
PublicKey =
Endpoint =
AllowedIPs = 0.0.0.0/0, ::/0
True, but I assumed you might actually want to have the container network isolated. For most people I think they consider --privileged and host networking a last resort for misbehaving software.
> This software is by no means ready for production. I use it in personal projects, but it has not been tested anywhere else other than my machine (as far as I know). Use it at your own (high) risk.
Yeah. I realize it's "mean" to say this but it makes me nervous to see no discussion of why you would do this. This kind of project can too easily get cargo-culted into places where it shouldn't be used.
I think, right now, with something like mitmproxy, for example, you can't use the wireguard mode unless the other proxy is "elsewhere." With this, perhaps you could use it from the same machine?
The purpose of Gluetun is to isolate your VPN into a container that you can then bind as the network provider of other containers. However, it's a documented problem [0] that performance isn't anywhere near as good as running the VPN natively, especially for Wireguard. At the minimum this can be related on some systems to the container being unable to load the kernel-space driver and having to rely on lower performing user-space driver, but even with a pre-loaded kernel-space driver performance testing is reporting significant lower values than the host. Presumably this project is to try and resolve that issue.
It's the first time I hear about Gluetun, thank you for sharing that!
From a very quick first impression it seems like it solves a different problem than dwgd.
With Gluetun you are creating a container that has access to various VPN providers (and exposing ports where proxies listen apparently); with dwgd you are giving a container the capability to route packets toward a WireGuard tunnel (you are essentially just giving the container the "ownership" of the WireGuard interface).
In order to have the client use the VPN but keep the rest of the system accessible outside the VPN I bind the client IP (VPN IP4 & IP6) in the client config and have WireGuard setup like this: