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

121–130 of 187 posts

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

#121

Post by d110af5ccf »

londons_explore wrote: post #57
unethical_ban wrote: post #45

Earlier quoted context omitted.

It is a completely reasonable requirement of a large organization to ensure an endpoint meets certain criteria before being allowed access to an internal network. I'm not arguing that Wireguard has an obligation to tackle that problem themselves. I'm arguing against your assertion that VPN access should be completely decoupled from ensuring endpoint security.

Lets be honest, any malicious endpoint can easily bypass those 'endpoint security' checks. All they're good for is checking that unpatched (but not yet exploited/evil) endpoints can't connect to the network, which is of marginal benefit compared to allowing them to connect but requiring they patch before accessing risky resources (like the internet or email).

I think there's an external issue here though. There might be regulation or some sort of liability concern regarding known unpatched clients connecting to the network. In that context simple checks make a lot of sense.

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

#122

Post by gspr »

no_time wrote: post #115
planetafro wrote: post #74

Earlier quoted context omitted.

Wouldn't they need a cert/custom CA on your box to do that?

Yes. My university was using Fortigate back in the day and it had 3 behaviours -Allow with no mitm (trusted sites) -Block with no way around it(all residental IPs, pornsites) -Allow but mitm the connection. The browser would present the classic ERR_UNKNOWN_ISSUER warning that most people would ignore. I couldn't figure out what criteria decided that a certain site needs the mitm treatment.

Ah yes, exactly the kind of intellectual freedom to explore and tinker you'd want to flourish at a university. Better block it! Wild guess: US?

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

#123

Post by AlexanderTheGr8 »

roozbeh18 wrote: post #73

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?

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

#124

Post by gspr »

lmm wrote: post #101
pkaye wrote: post #65

Earlier quoted context omitted.

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

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

#125

Post by herio »

tptacek wrote: post #106
starfallg wrote: post #105

Earlier quoted context omitted.

> (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?

What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management.

IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht...

ISAKMP/IKE is then used on top to manage the IPsec keys and parameters. This is where a lot of the complexity comes in, tons of parameters, modes, etc. etc.

So if all you want is to secure communication between two IPs and can securely exchange key material out of bands, manually keyed IPsec is not very complicated.

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

#126

Post by xvector »

gspr wrote: post #122
no_time wrote: post #115

Earlier quoted context omitted.

Yes. My university was using Fortigate back in the day and it had 3 behaviours -Allow with no mitm (trusted sites) -Block with no way around it(all residental IPs, pornsites) -Allow but mitm the connection. The browser would present the classic ERR_UNKNOWN_ISSUER warning that most people would ignore. I couldn't figure out what criteria decided that a certain site needs the mitm treatment.

Ah yes, exactly the kind of intellectual freedom to explore and tinker you'd want to flourish at a university. Better block it! Wild guess: US?

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

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

#127

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #85
jiggawatts wrote: post #84

For reference, I've never seen the built-in Windows VPN protocols exceed ~70 Mbps in any scenario. Maybe it's possible with a crossover cable between two Mellanox 100 Gbps NICs, using water-cooled and overclocked CPUs, but not over ordinary networks with ordinary servers. I have gigabit wired Internet to a site with gigabit Internet. Typical performance of SSTP or IKEv2 is 15-30 Mbps. That's 1.5% to 3% max utilisatio…

"... with a crossover cable..." Many years ago, I once brought a crossover cable from home to the office to do some data transfer from a workstation to a company-issued laptop. The IT department issuing the laptop, being lovers of all things Microsoft, claimed crossover cable was "obsolete" due to auto-sensing used by Windows. I am just another dumb end user, I do not work in IT, but I still get faster data transfer…

Seems like folks replying and voting may have assumed I was always using recently purchased hardware. That would be an incorrect assumption. Sure, there's auto-sensing in some newer hardware and Windows may support it, but that does not mean crossover cable does not work, too. They both work. Neither is obsolete, but only one works with older hardware.

Wonder why the parent comment I was replying to mentioned crossover cable in particular. If it's obsolete why mention it.

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

#128

Post by monocasa »

pjmlp wrote: post #120
jiggawatts wrote: post #84

For reference, I've never seen the built-in Windows VPN protocols exceed ~70 Mbps in any scenario. Maybe it's possible with a crossover cable between two Mellanox 100 Gbps NICs, using water-cooled and overclocked CPUs, but not over ordinary networks with ordinary servers. I have gigabit wired Internet to a site with gigabit Internet. Typical performance of SSTP or IKEv2 is 15-30 Mbps. That's 1.5% to 3% max utilisatio…

Not surprising at all, it is just not worthwhile doing from project management perspective, regardless what a bunch of people on Internet think about it.

Or Microsoft doesn't always make perfectly ideal project management decisions.

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

#129

Post by zekica »

jve wrote: post #108
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?

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.

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

#130

Post by zekica »

d110af5ccf wrote: post #118
PhantomGremlin wrote: post #117

Earlier quoted context omitted.

almost all DPI software recognize the wireguard handshake. Why should that matter? How does the DPI software get your keys? Isn't WireGuard data flow completely opaque to anyone or anything between endpoints? If the DPI software blocks WireGuard packets, that's an entirely different discussion. It gets into the area of "technical solutions" to fight "administrative policy".

> 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?
Post reply on HN