Live data from Hacker News

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

lists.zx2c4.com

141–150 of 187 posts

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

#141
post #139
post #137

Earlier quoted context omitted.

In Jason's post, he says: >While performance is quite good right now [...] not a lot of effort has yet been spent on optimizing it, and there's still a lot more performance to eek out of it, I suspect, especially as we learn more about NT's scheduler and threading model particulars. [emphasis added] Are you suggesting that these performance improvements will be contained in 'wireguard2'? Surely there will be improvem…

No, I think not. I guess that is an area where one would miss out without updates, but on the other hand, performance is already "good enough" for most endpoints. Of course, for operating a VPN concentrator you always want more performance, but then again, you won't do that on windows I guess.

[deleted]

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

#142
post #138

Earlier quoted context omitted.

Eh, if you care about privacy you shouldn't be browsing porn without a VPN or tunnel to a trusted server, "intellectual freedom" or not

I was referring to residential IPs.

Yep, by far that was the biggest PiA because I was hosting a lot of things at home.

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

#143
post #62

In some networks, I only have outgoing tcp ports 80 and 443. Does anyone have experience with udp2raw or udptunnel?

You might want to use [1] 1) https://github.com/lrvl/tunnel-wireguard-udp2tcp

That is a first step, but what you really want to do (and what most commercial VPN solutions are doing) is tunneling the VPN via https. Preferably with a real-looking web server at one end, so that "firewall solutions" have something to look at and scan for evil keywords. Oh, and you might have to disguise the traffic pattern as something that looks like http, so frequent reconnects. And the payload has to be web-like so that a MitM-proxy sees something like http, so an one direction is a POST, the other is the respective response, and if you cannot do persistent connections because the proxy kills them you'll have to poll at least in one direction.

Yes, this is supremely ugly, but unfortunately entrenched and expected by now. I've been to customers with intrusive filtering/scanning setups like that who then recommended their favourite commercial VPN vendor to get around that filtering...

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

#144
post #124
post #101

Earlier quoted context omitted.

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

Which is great . It decouples responsibilities. WG gives you a secure, well-performing tunnel. Key management is outside its scope. There are many solutions to that problem, no point in forcing a "WG sanctioned" one on people.

And yet the crowd that pushes WireGuard is the same crowd that pushes the idea that you can't give people a toolkit of crypto stuff, you have to give them a turnkey end-to-end system - indeed the fact that there's e.g. no algorithm selection in WireGuard is touted as a selling point. But how is making the user do their own key exchange/management any different? If you break the key management you break the cryptosystem.

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

#145

WireGuard is so good, sometimes I forget I am on vpn and only realize it when downloading a large file that my speed is capped by my home speed.

I am curious. Which VPN do you use for daily activities?

Mullvad is a popular WireGuard provider and well respected by HN users. I usually get about 700-800mbps on my home gigabit connection when using WireGuard and Mullvad.

There are at least several other providers out there. Ideally you can find one where their nearby servers use the same IX as your ISP and/or peer with your ISP.

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

#146

Will it be possible to fall back to the userspace implementation to use obfuscation software like shadowsocks? Or will it be deprecated? Unfortunately the recent popularity means that almost all DPI software recognize the wireguard handshake.

Jason previously stated in mailing list (couldn't find the thread now) that obfuscation is not a goal of WireGuard.

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

#147
post #130

Earlier quoted context omitted.

> It gets into the area of "technical solutions" to fight "administrative policy". Yes, that's exactly the point. Sometimes that's the best course of action available to you. If the userspace implementation were to be deprecated that could pose difficulties.

Why would it be an issue? Can't you specify localhost as the endpoint and use the proxy to send it where it needs to go? What is the difference between the implementations?

Performance will take a hit then, which is unfortunate.

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

#148
post #129
post #108

Earlier quoted context omitted.

People always compare bandwidth which is important. Has anyone done any comparisons how latency is affected between various VPN implementations?

Wireguard adds fixed latency as it doesn't do any buffering except for the one packet it is currently working on. The only exception is initial handshake which adds 1rtt for the first packet being sent.

> adds fixed latency

I don't know much about WireGuard, but generally speaking large fixed latency during one step can lead to huge variance in end to end latency due to queuing.

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

#149
post #62

In some networks, I only have outgoing tcp ports 80 and 443. Does anyone have experience with udp2raw or udptunnel?

This is just insane. Everything except WWW is blocked, so everything must pretend to be WWW???!!! So can anyone explain the purpose of the "source port" and "destination port" fields in the TCP header? :-)

By that logic someone has to explain why WireGuard is over UDP and the purpose of the "protocol" field of IP header :-)

It's called ossification. Same reason why TLS 1.3 has to pretend it's TLS 1.2, and QUIC must be over UDP.

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

#150
post #144
post #124

Earlier quoted context omitted.

Which is great . It decouples responsibilities. WG gives you a secure, well-performing tunnel. Key management is outside its scope. There are many solutions to that problem, no point in forcing a "WG sanctioned" one on people.

And yet the crowd that pushes WireGuard is the same crowd that pushes the idea that you can't give people a toolkit of crypto stuff, you have to give them a turnkey end-to-end system - indeed the fact that there's e.g. no algorithm selection in WireGuard is touted as a selling point. But how is making the user do their own key exchange/management any different? If you break the key management you break the cryptosyst…

The end-user doesn’t need to do their own key exchange/management.

Case in point: https://tailscale.com/

Why should WireGuard bake all that stuff into the core protocol and at the same time make it overly complicated? Donenfeld knows zero about your organization and he doesn’t pretend to do so either. Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.

Post reply on HN