71–80 of 157 posts
Is there a way to connect from macOS to the VPN?
As mentioned in the roadmap and the cross-platform page, we're working on a cross-platform userspace client, so Mac and Windows users can use it too. It's in the works!
Can someone explain why being in-kernel is considered a feature?
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…
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.
Is it possible to use TCP-only?
WireGuard is UDP only. For TCP or SSL tunneling, look at a million other things that already do this.
What are the advantages of doing UDP instead of IP?
It seems like, all else being equal, doing IP has the advantage of working with UDP and TCP out of the box.
Earlier quoted context omitted.
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"…
OpenVPN uses TLS. The whole point of WireGuard is to shake off that complex baggage.
Earlier quoted context omitted.
> 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.
[1] - http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_inter...
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.
Earlier quoted context omitted.
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"…
I addressed CPL0 vs CPL3 elsewhere on the thread. All things are not equal here. OpenVPN uses TLS. The whole point of WireGuard is to shake off that complex baggage.
Granted, but this should generally be behind a shared secret HMAC, according to best practices, limiting the scope to those with the key in hand.
> The whole point of WireGuard is to shake off that complex baggage.
That's great, but also has nothing to do with running in-kernel. I'm not ready to give either product a clear pass on their risk profiles.