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

WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

lists.zx2c4.com

Post reply on HN
Print view View original

101–110 of 187 posts

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#101

Post by lmm »

pkaye wrote: post #65
tptacek wrote: post #55

Earlier quoted context omitted.

I think you could reasonably look at WireGuard as a repudiation of previous VPN protocols, almost from root to branch. For instance, WireGuard reconsiders what the role of a VPN "protocol" actually is, and in WireGuard the protocol itself delivers a point-to-point secure tunnel and nothing else, so that the system is composable with multiple different upper-level designs (for instance, how you mesh up with multiple e…

Does it use key management like SSH or more like certificates with TLS?

No. It dumps that on you to figure out for yourself.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#102

Post by jcrawfordor »

bpye wrote: post #88
compressedgas wrote: post #87

Earlier quoted context omitted.

Have you tried connecting two computers with just a patch cable? With the auto-sensing Ethernet ports, it works as if the cable were a crossover cable.

I believe this is only true for gigabit - though almost any device today should be?

Auto-MDIX was starting to become the norm on nicer hardware when GbE started gaining adoption, and the MDI layer of GbE effectively obsoletes the concept of MDIX by specifying that pairs must always be probed. This was sort of required due to GbE requiring four pairs while Fast Ethernet required two, it is sort of expected that a GbE interface will encounter improper cables and it needs to detect that to degrade to Fast Ethernet.

So for GbE it's all but guaranteed, for Fast Ethernet it depends on how much money the device vendor was willing to spend on the interface, basically. Later laptops should be pretty reliable.

Or course none of this has anything to do with Windows, it all happens at a hardware level which can sometimes make investigating problems a bit painful.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#103

Post by dangfang »

tptacek wrote: post #55
kzrdude wrote: post #18

What is WireGuard, is it a new protocol? Or a new algorithm for implementing an existing thing? (Or something else)

I think you could reasonably look at WireGuard as a repudiation of previous VPN protocols, almost from root to branch. For instance, WireGuard reconsiders what the role of a VPN "protocol" actually is, and in WireGuard the protocol itself delivers a point-to-point secure tunnel and nothing else, so that the system is composable with multiple different upper-level designs (for instance, how you mesh up with multiple e…

That's not honest. Wireguard on Linux is really hard to install. I managed to install the "server" side after a lot of huff and puff but I've given up on the "client" side. On windows, the "client" side really is as easy as you say though. It's LOVELY

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#104

Post by tptacek »

dangfang wrote: post #103
tptacek wrote: post #55

Earlier quoted context omitted.

I think you could reasonably look at WireGuard as a repudiation of previous VPN protocols, almost from root to branch. For instance, WireGuard reconsiders what the role of a VPN "protocol" actually is, and in WireGuard the protocol itself delivers a point-to-point secure tunnel and nothing else, so that the system is composable with multiple different upper-level designs (for instance, how you mesh up with multiple e…

That's not honest. Wireguard on Linux is really hard to install. I managed to install the "server" side after a lot of huff and puff but I've given up on the "client" side. On windows, the "client" side really is as easy as you say though. It's LOVELY

You'll have to say more about the challenges you found with it, because we do a _lot_ of WireGuard here, in a bunch of different ways, and given a valid `wg0.conf` file (which is just the keys and the addresses for the tunnel), I've never hd to do much more than `wg-quick up wg0.conf` to make it work, on our servers, on my NUC, on Amazon Linux EC2 instances, and on VMs.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#105

Post by starfallg »

tptacek wrote: post #98
starfallg wrote: post #82

Earlier quoted context omitted.

Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC removed. With a bit of multipoint goodness (ala DMVPN) sprinkled in. The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN. Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algor…

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…

> (d) As a result of all of this, it is very fast.

No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC hardware offload.

OpenVPN is slow due to architectural constraints, but IPSEC doesn't suffer from that at all. IPSEC tunnels with PSK is also absurdly easy to configure, either on Linux, or a router, what it doesn't offer is native NAT traversal.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#106

Post by tptacek »

starfallg wrote: post #105
tptacek wrote: post #98

Earlier quoted context omitted.

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…

> (d) As a result of all of this, it is very fast. No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC h…

You are the first person who has ever told me that IPSEC was absurdly easy to configure. Share a configuration that illustrates the point?

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#107

Post by vxNsr »

tptacek wrote: post #104
dangfang wrote: post #103

Earlier quoted context omitted.

That's not honest. Wireguard on Linux is really hard to install. I managed to install the "server" side after a lot of huff and puff but I've given up on the "client" side. On windows, the "client" side really is as easy as you say though. It's LOVELY

You'll have to say more about the challenges you found with it, because we do a _lot_ of WireGuard here, in a bunch of different ways, and given a valid `wg0.conf` file (which is just the keys and the addresses for the tunnel), I've never hd to do much more than `wg-quick up wg0.conf` to make it work, on our servers, on my NUC, on Amazon Linux EC2 instances, and on VMs.

> and given a valid `wg0.conf`

And there it is. Idk about OP but this is what tripped me up. There are many guides online, but the native documentation assumes you have a pretty deep understanding of the network stack, authentication, and VPNs.

The online guides all kinda make assumptions about your network set up and if it’s different in anyway your attempt will fail and you won’t know why; as the error codes are kinda generic and somewhat meaningless to someone without in-depth networking experience.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#108

Post by jve »

Panino wrote: post #4

Very impressive performance: > While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizing it > Jonathan Tooker reported to me that, on his system with an Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard, ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over WiFi.…

People always compare bandwidth which is important.

Has anyone done any comparisons how latency is affected between various VPN implementations?

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#110

Post by shawnz »

perryizgr8 wrote: post #95
netr0ute wrote: post #47

Earlier quoted context omitted.

>IPSec is Internet Layer Technically not, since IPSec can also be tunneled over UDP which then turns it into an application layer protocol.

I don't think it works like that. Vxlan can tunnel ethernet frames over UDP, but that doesn't make Ethernet an application layer protocol.

These semantic issues are why "layers" are a terrible way of classifying network protocols
Post reply on HN