Nice work! Exciting!!
WireGuard: next generation in-kernel modern VPN
121–130 of 157 posts
Re: WireGuard: next generation in-kernel modern VPN
#122Do you have try this in China internet?
As we know, China has a more complicated network.
UDP packets have a large loss.
If it could work better than ocserv, this vpn will be a milestone.
Re: WireGuard: next generation in-kernel modern VPN
#123Wow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
How does WireGuard deal with private keys on smartcards or other HSMs ?
Re: WireGuard: next generation in-kernel modern VPN
#124Earlier quoted context omitted.
It's very common to use existing VPN protocols for proxying - Google "VPN" and you'll find many commercial services. And the WireGuard white paper mentions passing all traffic to a single peer as a possible configuration, so I think it should be usable for it as well, modulo OS compatibility. Which is good, because existing VPN software suffers from the same configuration and security headaches whether it's used for…
I think you missed my point. Sure, every VPN solution can be turned into "proxy all internet traffic through there" with enough configuration. What I meant is that tptacek was talking about commercial/serious VPN as in corporate usage, not commercial as in "it takes money from anyone". You're talking about two completely different use cases with very different goals and potential issues.
You said that WireGuard was not "a real candidate for the case you're talking about", and I explained why it being (eventually) widely adopted for that case is both possible and desirable. I don't see much point in arguing over what tptacek meant.
Re: WireGuard: next generation in-kernel modern VPN
#125Just wanted to point out that the author is also behind the excellent password manager pass: https://www.passwordstore.org/ . Congratulations.
That's a very nice tool, but I dislike how it leaks information via the visible directory structure and filenames.
Re: WireGuard: next generation in-kernel modern VPN
#126Why 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.
Severe performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks.…
I was not concerned about it from a security perspective at all. What I'm concerned about is poor software engineering. The fact that something like a particular flavor of VPN needs to be integrated directly into the kernel smells to me like a shortcut to skip improving the kernel to enable better userland networking code. Why this VPN proto and not the next hot item of the month? How about we start throwing some load balancing code directly into the kernel? How about some TLS termination?
Re: WireGuard: next generation in-kernel modern VPN
#127Why 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…
>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.
I know and I don't much care to see this crappy tradition carried on with this new protocol. :(
Re: WireGuard: next generation in-kernel modern VPN
#128Wow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
What capabilities does this provide over IKEv2 with certificates and MOBIKE for roaming?
One disadvantage off the bat is that every operating system from OSX to Windows 7 to Linux to *BSD already has support for IKEv2 and MOBIKE caked in.
Re: WireGuard: next generation in-kernel modern VPN
#129Earlier 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/
However it's basically true. You need to be running specific hardware and/or drivers to make use of kernel bypass. You most definitely will never be able to use DPDK on the average laptop.
For a VPN that intends end-user device deployment it's kind of silly to require specific hardware.
Re: WireGuard: next generation in-kernel modern VPN
#130Earlier 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!
For those of you who're interested, the mail to LKML can be found here: https://lkml.org/lkml/2016/6/28/629