Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard: next generation in-kernel modern VPN

wireguard.io

Post reply on HN
Print view View original

61–70 of 157 posts

Re: WireGuard: next generation in-kernel modern VPN

#61

Post by derefr »

clinta wrote: post #38
zx2c4 wrote: post #22

Earlier quoted context omitted.

> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does th…

The idea of Phase3 is that you have multiple node routers connected to a VPN hub. Think branch offices. When one node starts to talk to another node, the Hub initially facilitates the traffic, but it sends a NHRP(Next Hop Resolution Protocol) packet to the nodes telling them the public IPs of eachother, the nodes then negotiate their own VPN tunnel and start communicating directly without passing all traffic through…

Just as a dumb spectator: that sounds a lot like https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab..., but below the application layer. Neat!

Re: WireGuard: next generation in-kernel modern VPN

#62

Post by steveklabnik »

zx2c4 wrote: post #54
hueving wrote: post #41

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

I am extremely excited to see the Rust version of this; how do I learn about it when it ships?

Re: WireGuard: next generation in-kernel modern VPN

#63

Post by q3k »

zx2c4 wrote: post #54
hueving wrote: post #41

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

> Because it's necessary for any reasonable performance.

This is simply not true [1] [2].

[1] - http://dpdk.org/

[2] - http://info.iet.unipi.it/~luigi/netmap/

Re: WireGuard: next generation in-kernel modern VPN

#64

Post by lobster_johnson »

hueving wrote: post #41

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

Tinc [1] is a userspace VPN, and a good demonstration of how slow networking gets when done that way, compared to kernel-mode VPN routing such as IPsec and VxLAN.

[1] https://www.tinc-vpn.org

Re: WireGuard: next generation in-kernel modern VPN

#65

Post by teacup50 »

tptacek wrote: post #53
teacup50 wrote: post #50

Earlier quoted context omitted.

> As a "security professional", I kind of don't care whether this is in-kernel or not. As a "kernel professional", I'm laughing incredulously at this. A lot.

Do go on.

What do you want me to say? I'd think it ought to be self-evident that greater risks exist when operating in a single shared memory space at ring 0. If nothing else, the trampoline to privilege is already complete; very little stands between a vulnerability and an active exploit.

The end goal ought to be getting more things out-of-ring 0, not adding more things to it -- I'm never going to say that "I'm not concerned" or that "It's a non-issue" (although I will say that I'm a lot more worried about the massive amounts of crap code in WiFi drivers than I am about a VPN implementation, generally speaking).

In the OpenVPN case, numerous vulnerabilities have been limited to only DoS exploits due to the zealous use of assert(); in the kernel case, that brings down your machine, and quite often, assertions are compiled out of the release kernel due to their overhead in critical paths (whether they should be is another question).

We do have ways to tackle the kernel->userspace performance divide when it comes to packet processing, e.g: https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4

  netmap is a framework for extremely fast and efficient packet I/O for
  both userspace and kernel clients. It runs on FreeBSD and Linux, and
  includes VALE, a very fast and modular in-kernel software switch/data-
  plane, and netmap pipes, a shared memory packet transport channel. All
  these are accessed interchangeably with the same API.

  netmap, VALE and netmap pipes are at least one order of magnitude faster
  than standard OS mechanisms (sockets, bpf, tun/tap interfaces, native
  switches, pipes), reaching 14.88 million packets per second (Mpps) with
  much less than one core on a 10 Gbit NIC, about 20 Mpps per core for VALE
  ports, and over 100 Mpps for netmap pipes.

  Userspace clients can dynamically switch NICs into netmap mode and send
  and receive raw packets through memory mapped buffers.  Similarly, VALE
  switch instances and ports, and netmap pipes can be created dynamically,
  providing high speed packet I/O between processes, virtual machines, NICs
  and the host stack.

Re: WireGuard: next generation in-kernel modern VPN

#66

Post by loeg »

q3k wrote: post #63
zx2c4 wrote: post #54

Earlier quoted context omitted.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

> Because it's necessary for any reasonable performance. This is simply not true [1] [2]. [1] - http://dpdk.org/ [2] - http://info.iet.unipi.it/~luigi/netmap/

Both userspace stacks bypass several standard kernel interfaces to achieve good performance. If you want to integrate with normal kernel configuration (interface, routing, etc) and BSD sockets, then maybe you do need to be in the kernel. (Maybe it's possible to improve userkernel interfaces to reach good performance in userspace with standard kernel configuration, but we aren't there yet.)

Re: WireGuard: next generation in-kernel modern VPN

#67

Post by zx2c4 »

q3k wrote: post #63
zx2c4 wrote: post #54

Earlier quoted context omitted.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

> Because it's necessary for any reasonable performance. This is simply not true [1] [2]. [1] - http://dpdk.org/ [2] - http://info.iet.unipi.it/~luigi/netmap/

I love DPDK. Super fun. I've actually made a few projects with it. But this is for creating closed network systems, not for integrating into Linux's networking infrastructure. If somebody would like to produce a WireGuard implementation (library, I guess) for DPDK, I'd be super happy about this, and I'm sure it'd find some specialized users. But for everything else, there's the ordinary design.

Re: WireGuard: next generation in-kernel modern VPN

#68

Post by x0ra »

zx2c4 wrote: post #54
hueving wrote: post #41

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

OpenVPN is probably the worst VPN example. It carries about 15 years of technical debt... Same argument for OpenSSL.

Unless you aim at gigabit speed, there is no real reason for a kernel based solution.

Re: WireGuard: next generation in-kernel modern VPN

#69

Post by zx2c4 »

steveklabnik wrote: post #62
zx2c4 wrote: post #54

Earlier quoted context omitted.

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows fo…

I am extremely excited to see the Rust version of this; how do I learn about it when it ships?

Join the mailing list!

https://lists.zx2c4.com/mailman/listinfo/wireguard

And if you're savvy and want to get involved with development, we need all the help we can find!

Re: WireGuard: next generation in-kernel modern VPN

#70

Post by loeg »

zx2c4 wrote: post #6
Aissen wrote: post #4

Earlier quoted context omitted.

Yes, guilty as charged. Ever since I saw you presentation in Paris in last September, I was dying for wireguard to come out. I'm curious what will be your strategy with regard to working or not with upstream Linux ?

Oh cool you came to the kernel recipes talk. Much has progressed since then. I wrote an email on LKML and netdev today to David Miller, the network subsystem maintainer. It's not ready for a [PATCH] set now, but it is ready to get initial feedback from them, so that I can start to get things ready for upstreaming. So: that's on the roadmap and a primary objective!

Would you mind dual-licensing under a more permissive license (BSD or MIT) so the work can be included in the BSD family of operating systems as well as Linux?
Post reply on HN