I recently set this up, but with Podman since I was experimenting with CentOS. It turned out to be quite simple to use network namespaces. I created a new namespace for wireguard and moved wg0 into the namespace, then had the container use that namespace:
ip netns add vpn
ip link add wg0 type wireguard
ip link set wg0 netns vpn
# configure wireguard as usual, prefix commands with ip netns exec vpn
podman run --network=ns:/var/run/netns/vpn ...
When I tried this was not yet possible with rootless containers, but in newer Podman versions you can tell slirp4netns to use a specific network interface with --network=slirp4netns:outbound_addr=INTERFACE.
> take a look at an OpenVPN config file and you will appreciate this shortness
OpenVPN config files can be pretty small once you remove all the comments (my server is 22 lines)
That being said, I like WireGuard. I've switched over a lot of stuff to it. It does have some issues though:
* Road warrior configurations aren't easy. If you use a DNS name as an endpoint, and that DNS entry changes, you have to refresh it. They have a contrib script in the repo that you can put in cron and do this for you, but it's still not built in.
* You might need keep-alives in certain configurations
* You can't bind Wireguard to an IP address. It listens on all adapters. The devs argue it doesn't matter since WG won't respond via UDP unless it gets a valid key, but this does put WG into a weird state where it might send on an IP it's not receiving on.
There are others I'm probably forgetting. I do like it though. It's faster, the setup is clear. If you have one setting wrong in OpenVPN the connection could fail and you not get useful stuff in the logs.
> If you use a DNS name as an endpoint, and that DNS entry changes, you have to refresh it.
This is really frustrating for me. If you put a DNS name as a peer endpoint, wg-quick will resolve the name and then _replace the name with the ip address_. My IP address changes frequently and I have a script to update the A record when it does, but wireguard didn't have built in support for just keeping the domain name around when I last looked.
I haven't been arsed to do it yet, but I'm often concurrently connected to separate wireguard subnets with their own dns so the sane thing to do would be to run a local dnsmasq and map it there instead.
What's the alternative? Allow the Wireguard user to specify an FQDN in the config file and require Wireguard to perform a DNS query on every outgoing packet to check if the data in the RR has changed?
>> take a look at an OpenVPN config file
> OpenVPN config files can be pretty small
That particular jab was pretty strange.
The very first example in the OpenVPN documentation is of a server config:
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
That's three lines. The client needs a "remote" entry as well. How much more terse can it get?
There are many applications with complex configuration formats, but OpenVPN is not it. It has both a simple format and good defaults. It should be an example to others!
Not sure what you're trying to read between the lines, but it's not there intentionally. There was no sarcasm intended.
OpenVPN has a terse and logical configuration language. For all the complaints that open source projects do bad UX, someone put a bit of thought into this one, and it shows.
Note that when using docker-compose you don't need any manual docker network calls with my solution as well. The systemd-network and docker-compose files suffice.
I appreciate the write up, but you can't just put "simple" in a title to and expect it to be simple for everyone. It's simple for what audience? I know there are plenty of developers (especially Mac/Windows users) who would read this and be put off. Simple for me would be running one command like "docker-compose up" and be up and running.
It's simple compared to other solutions I found when writing the article, in my opinion (while I wasn't the one who put "simple" in the title here, my original title is different).
Anyway, take a look at the "Instructions in Short" section (I just added a button at the article beginning to jump to that section). You only have to fill in a few blanks (probably just copying from a wg-quick file you already have), add a few lines to your docker-compose file and then run docker compose up.
I think that's somwhat simple enough for a non-trivial task. I might write a script to do that automatically in the future (somebody in the article's discussion asked for that, by the way).
