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.
WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
141–150 of 187 posts
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#142Earlier 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.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#143In 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
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
#144Earlier 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.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#145WireGuard 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?
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
#146Will 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.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#147Earlier 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?
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#148Earlier 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.
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
#149In 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? :-)
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
#150Earlier 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…
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.