LWN: Comments on "WireGuard: a new VPN tunnel"

WireGuard: a new VPN tunnel

zx2c4 — Tue, 23 Aug 2016 13:03:37 +0000

1. It definitely is documented that it's UDP. This is written in several places, including the front page of the website. Please read the documentation before you make spurious claims like this. It's mentioned on: https://www.wireguard.io/ https://www.wireguard.io/protocol/ and https://www.wireguard.io/papers/wireguard.pdf

2. For priority, would you like a nob to set the DSCP value? Is this what you have in mind?

3. For obfuscation, there was a mailing list thread about this some time ago -- https://lists.zx2c4.com/pipermail/wireguard/2016-July/000... -- you can read it starting there.

WireGuard: a new VPN tunnel

Darkmere — Tue, 23 Aug 2016 12:55:52 +0000

The tracing was more about, how do I track and separate the Wireguard traffic from the outside, and how do I identify it.

For some cases, anonymity against the network is interested. Some "VPN" solutions go to great lengths (obf4) to hide the fact that the connection is a VPN. While for others, you want to identify it in order to correctly set priorities on routing level.

I work a bit with SIP related tech, and then it's quite vital to have your VPN properly prioritized to guarantee short latency. IPSEC tends to be the given default, with OpenVPN in UDP mode a contender. Getting better latencies is always interesting in realtime communications.

So, from that side, knowing that it's UDP (I'm assuming, it's not documented) and port 51820-52000 may be enough for the firewalling. ( Hey, for all that I know it could have used SCTP! )

WireGuard: a new VPN tunnel

zx2c4 — Mon, 22 Aug 2016 12:32:31 +0000

The default port is 51820. For convience, if your interface ends in 0 (such as wg0), you get that, if it ends in 1 (such as wg1) you get 51821, and so forth.

As far as tracing WireGuard from the inside and outside, you can just use tcpdump or wireshark like usual:

# tcpdump -i wg0 -vv -xx
# tcpdump -i eth0 -vv -xx

Good idea about putting this in the documentation. I'll do that.

Hope this helps,
Jason

WireGuard: a new VPN tunnel

Darkmere — Mon, 22 Aug 2016 12:20:14 +0000

I'd love to see a section on the documentation about Firewalling and transfer. As in, how do I trace wireguard from the inside / outside, what ports & protocols are necessary to allow for transmit ( per default /IANA assigned?)

WireGuard: a new VPN tunnel

zx2c4 — Mon, 08 Aug 2016 15:30:55 +0000

That's helpful advice; thanks a bunch. I've got just a few things left on my todo list with WireGuard, and then I'll get a v1 for the list.

WireGuard: a new VPN tunnel

johannbg — Mon, 08 Aug 2016 15:28:58 +0000

You never get answers if you never ask any questions the same thing applies for the kernel, you wont get any review unless you submit something for reviewing so you get the the best [PATCH] set review by actually submitting the patches ;)

I'm pretty sure most of the kernel devs are too busy to be able to familiarizes themselves with anything non patch related on that list so you know submit your work, brace yourself for the feedback, then fix what needs fixing and hopefully this ends up in 4.9. At that point in time ( when it's merged upstream ) it can be looked at whether wireguard is something to be usefully integrated with systemd-networkd.

WireGuard: a new VPN tunnel

zx2c4 — Mon, 08 Aug 2016 14:28:10 +0000

Actually I was quite disappointed not to get any feedback from the upstream devs. I was hoping they'd at least review the project and give some preliminary feedback to help me craft the best eventual [PATCH] set. Unfortunately they've been completely silent. Major bummer. I've been checking that thread every day too.

WireGuard: a new VPN tunnel

johannbg — Mon, 08 Aug 2016 10:03:23 +0000

Took it for granted that this was the submission for inclusion of the wireguard kernel module not just some FYI ( which I did not think existed on lkml ) and as an idiot been monitoring it for discussion for acceptation,rejection since this wont be integrated/deployed/used until it gets into the kernel. Well I guess I can stop that now ;)

But that indeed explains why no movement has been on the thread other than from end users...

WireGuard: a new VPN tunnel

johill — Mon, 08 Aug 2016 09:23:34 +0000

AFAICT, there was no patch posted for inclusion, so what kind of "movement" would you expect?

WireGuard: a new VPN tunnel

johannbg — Mon, 08 Aug 2016 08:51:46 +0000

Given that there is no movement on the upstream kernel thread, are those upstream kernel maintainers dead. awol or just ignoring this or have there been any discussion about this offlist?

WireGuard: a new VPN tunnel

zx2c4 — Tue, 05 Jul 2016 16:37:21 +0000

Sure. I thought the rtnl and net_device interfaces were quite nice:

https://git.zx2c4.com/linux/tree/include/net/rtnetlink.h
https://git.zx2c4.com/linux/tree/Documentation/networking...

WireGuard: a new VPN tunnel

MattJD — Tue, 05 Jul 2016 16:13:16 +0000

For someone not familiar with kernel internals, can you expand on your point about integration? Or point me to any documentation you have on the matter?

WireGuard: a new VPN tunnel

zx2c4 — Tue, 05 Jul 2016 14:46:57 +0000

Right, there's no cipher agility. But the protocol prologue still ties each session to the ciphersuite by explicitly specifying which ciphers are being used. So, if there are ever weaknesses in the chosen ciphersuite, the next version will use a different ciphersuite. But, there won't ever be agility.

There's a cross-platform userspace version of this in the works that should function well on Windows/Mac/otherLinuxes/otherUnixes. This includes Android. But WireGuard can also run as a kernel module for Android, since it's just Linux.

WireGuard: a new VPN tunnel

vadim — Tue, 05 Jul 2016 14:42:53 +0000

If I am reading it correctly, there's absolutely no negotiation of crypto details.

What if Curve25519 turns out to have a flaw in it? What if another algorithm performs a lot better on a particular architecture?

Are there any plans to integrate this into Android?

Are there any plans for a Windows client?

WireGuard: a new VPN tunnel

zx2c4 — Mon, 04 Jul 2016 21:16:19 +0000

Several reasons, but performance is certainly an important one. It's just not possible to get that kind of performance elsewhere. Being able to decrypt packets directly out of the ethernet card's buffer is invaluable. The general integration options offered by being a kernel driver are quite helpful.

WireGuard: a new VPN tunnel

MattJD — Mon, 04 Jul 2016 08:02:44 +0000

Hi Jason,

One quick question: why implement this in kernel? Is it just for the speed? Or are there other benefits?

WireGuard: a new VPN tunnel

zx2c4 — Fri, 01 Jul 2016 20:42:01 +0000

Happy to answer any questions about the project.

-Jason