81–90 of 157 posts
Seems like an interesting project. How does it compare to zerotier: https://www.zerotier.com/
Earlier quoted context omitted.
We'll actually be producing a Rust implementation for userspace. It'd be interesting to see that work ported back to kernelspace. Cool suggestions.
That sounds good. What's its current implementation language?
Seems like an interesting project. How does it compare to zerotier: https://www.zerotier.com/
Earlier quoted context omitted.
So, everyone needs to take a deep breath here. In kernel VPN is giving me a bit of a security heart attack. As a security professional I would recommend not running this on anything but a sandbox that isn't connected to your environment. A single misstep in the code, a bad implementation of a crypto library or a bad hook could easily lead to ring 0 compromise. Not trying to discount the author's work, and I haven't r…
> In kernel VPN is giving me a bit of a security heart attack. You may be surprised, then, that most of the standard VPN tech — IPsec, GRE+PPTP, VxLAN, etc. — operate in the kernel (with some help from userland apps for things like IKE).
Earlier quoted context omitted.
I don't really have any problem re-licensing it less restrictively, I don't think. I'll have to think about it for more than 10 seconds I suppose. But I put "GPLv2" there without much thought simply because that's what Linux uses. But you make a good point about the BSDs.
As a hardcore BSD user, GPLv2 is perfectly fine with the BSDs. They all ship with GPLv2 software by default. FreeBSD doesn't like GPLv3, but OpenBSD and DragonFlyBSD don't have a problem with it. I don't know about NetBSD off the top of my head. IMO this seems like something that should be GPL and I think you needn't change it.
Earlier quoted context omitted.
> In kernel VPN is giving me a bit of a security heart attack. You may be surprised, then, that most of the standard VPN tech — IPsec, GRE+PPTP, VxLAN, etc. — operate in the kernel (with some help from userland apps for things like IKE).
sorry - aren't those all protocols and not applications?
Wow, 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.
Any chance of switching to a non-GPLv2 license? Broad adoption would be far more likely.
Seems like an interesting project. How does it compare to zerotier: https://www.zerotier.com/
I was going to ask that myself but ZeroTier provided a hint. It seems to be aiming for more than a simple, IPsec replacement. It will have more features and complexity no matter what. Also, Jason already speced out the WireGuard protocol plus intends a Rust port. Will significantly increase code-level security over ZeroTier. Both need strong, peer review at protocol and implementation levels, though. As always with t…
Yes, our goals are much broader than VPN. You can think of ZeroTier as a virtual smart switch built on a P2P network; a "smart switch for Earth." We want to totally abstract away the physical network. A lot of ZT's complexity over WireGuard is about working around the underlying network (NAT-t, dual-stack support, dealing with timeouts and path failures, relay fallback, peer location and roaming, redundancy, etc.) as well as smart switch features and robustness against DOS attacks and similar things.
Nevertheless ZT's core code really isn't that big. The core protocol implementation is 23,000 lines of C++ code. This includes many very long comments documenting the protocol, etc., so total lines of actual code is probably more like 18-20k. It's comparable to an embedded TCP stack.
WireGuard does have some things in common with ZeroTier, such as the use of cryptography to identify endpoints and eliminate the hard-coding of endpoint addresses. This is one of many ways that IMHO cryptography actually simplifies networking. I really like the WireGuard design in general and I think it has a somewhat different use case from ZeroTier, namely fast long-lived provisioned links across WANs and insecure LANs. You could use ZT for that but this being in-kernel makes it likely faster. In any case I hate IPSec (over-engineered mess, terribly hard to configure) so any alternative to that is welcome.
(Edit: there are things you can do to speed up user-mode networking like zero-copy data paths, etc., so it's not guaranteed that this would always be faster. But that's another topic.)
Earlier quoted context omitted.
Thanks for being here, I have a few questions. Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table? Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? Also is it in the scope of this project for peers to discover each other…
> 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…
> 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 this mean that it is impossible for two clients to connect to the same VPN server from behind router doing NAT? Or does each client choose a random source port for their traffic and then the combination of source port and source IP identifies the client?