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

171–180 of 187 posts

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

#171

Post by unethical_ban »

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).

Not all compromised machines are the same. Is the user of the machine an insider threat or not? Does the login user have admin rights to the machine or not? And what you said in the last sentence is exactly how some VPN solutions can be configured: Limited access to network resources for updates and management, and only when fully matching version/anti-malware/etc. requirements can you connect to all resources.

Anyway. Like I said, I think Wireguard is amazing - I used PiVPN (which can be installed on any .deb distro) to set up a simple gateway for my laptop and phone to be always connected for DNS and local-network access. I'm very grateful for its architecture and simplicity in that regard.

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

#172

Post by no_time »

riobard wrote: post #159
no_time wrote: post #158

Earlier quoted context omitted.

I'm aware of that. However there are obfuscation software e.g shadowsocks that wraps wireguard or any other connection.

To be honest WireGuard over Shadowsocks is neither common nor recommended, coz essentially it's TCP-over-TCP which will wreak havoc on TCP congestion control. Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common. (Disclaimer: I wrote the official Go port of Shadowsocks https://github.com/shadowsocks/go-shadowsocks2 )

Thank you for your work :D

Sometimes a bad solution is better than no solution at all.

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

#173

Post by atonse »

deskamess wrote: post #162
atonse wrote: post #14

Earlier quoted context omitted.

Tailscale solves all these problems, including SSO. Can you tell I’m a very happy customer?

Do you have any Windows systems in your network? I am looking to restrict RDP sessions to a closed Wireguard network.

We did for a couple new people and then replaced them with Macs (for irrelevant reasons).

But while they were on Windows, Tailscale worked perfectly on their machines too.

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

#174

Post by shawnz »

1vuio0pswjnm7 wrote: post #127
1vuio0pswjnm7 wrote: post #85

Earlier quoted context omitted.

"... 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 crossov…

You are confusing two different conversations. Your IT department are the ones that used the language "obsolete", because they likely knew that the laptop (which they provided) supported auto-sensing and therefore there was no need for them to provide you with a special cable to achieve a direct PC-to-PC ethernet connection.

Whereas the parent comment probably only used the language "crossover" because they were trying to be explicit about the fact that they are talking about a direct PC-to-PC ethernet connection. Not because crossover wiring is actually necessary to make that configuration work.

Furthermore, support for auto-sensing has nothing to do with the OS, or Microsoft.

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

#175

Post by benou »

tptacek wrote: post #167
benou wrote: post #160

Earlier quoted context omitted.

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux. However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on…

Post numbers on a good IPsec implementation? We have numbers for WireGuard. Of course, it's easy to do that because there's just a couple primary implementations, not 100 terrible ones like in IPsec. So, pick the best one. We don't have to derive the answer to this question from first principles. It's an empirical question.

Here is an example for VPP, ~8Gbps/core of IPsec forwarding with AES-256-GCM and IMIX traffic on Skylake @2.3GHz: https://docs.fd.io/csit/master/report/vpp_performance_tests/...

Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.

Those numbers can grow up to 50% for big packets (1500-bytes and higher).

With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.

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

#176

Post by benou »

starfallg wrote: post #170
benou wrote: post #160

Earlier quoted context omitted.

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux. However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on…

>I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too. The speed gains wouldn't be as significant. AES uses S-Box computations that do well when hardware accelerated, whereas ChaCha/Salsa20 are designed to use more typical CPU instructions for bitwise operations.

Speed gains maybe not, however on current x86 platform there is a 2x perf difference between AES-256-GCM and Chacha20-Poly1305, so even if we get "only" 2x I'd be delighted.

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

#177

Post by monocasa »

deadmutex wrote: post #148
zekica wrote: post #129

Earlier quoted context omitted.

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.

That one piece is for initialization. I'm not sure about wireguard, but I've typically seen that abstractions of ethernet stacks like VPNs will either throw away packets to be sent before initialization is complete, or will structurally simply not allow anything to be queued at that point in the first place (so like if it's a user space implementation, use type safety somehow so you can't even call send_packet() until it's done with init). In those modes the fixed latency of init doesn't cause buffer bloat issues.

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

#178

Post by 1vuio0pswjnm7 »

shawnz wrote: post #174
1vuio0pswjnm7 wrote: post #127

Earlier quoted context omitted.

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 crossov…

You are confusing two different conversations. Your IT department are the ones that used the language "obsolete", because they likely knew that the laptop (which they provided) supported auto-sensing and therefore there was no need for them to provide you with a special cable to achieve a direct PC-to-PC ethernet connection. Whereas the parent comment probably only used the language "crossover" because they were tryi…

First, I provided the cable. They were commenting on the idea of using a crossover cable, not a request for one.

Second, you are guessing what the commenter meant by crossover cable. I think he meant crossover cable. There is nothing to suggest otherwise.

Third, I never said auto-sensing had anything to do with the OS or Microsoft. I said the IT department loved Microsoft. You got confused and made a connection between the two.

This thing with Microsoft Windows is that it encourages the user to upgrade their hardware. Whereas I prefer NetBSD as a personal OS, and it does no such thing. Not every computer I own has auto-sensing nor a particularly fast NIC.

The questions I raised are 1. whether crossover cable still works (with both older and newer hardware) and 2. whether it is faster than alternatives.

Is it slower. IME, no.

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

#179

Post by tptacek »

benou wrote: post #175
tptacek wrote: post #167

Earlier quoted context omitted.

Post numbers on a good IPsec implementation? We have numbers for WireGuard. Of course, it's easy to do that because there's just a couple primary implementations, not 100 terrible ones like in IPsec. So, pick the best one. We don't have to derive the answer to this question from first principles. It's an empirical question.

Here is an example for VPP, ~8Gbps/core of IPsec forwarding with AES-256-GCM and IMIX traffic on Skylake @2.3GHz: https://docs.fd.io/csit/master/report/vpp_performance_tests/... Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake. Those numbers can grow up to 50% for big packets (1500-bytes and higher). With a high per…

This is DPDK-style user-mode direct/raw networking, isn't it?

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

#180

Post by shawnz »

1vuio0pswjnm7 wrote: post #178
shawnz wrote: post #174

Earlier quoted context omitted.

You are confusing two different conversations. Your IT department are the ones that used the language "obsolete", because they likely knew that the laptop (which they provided) supported auto-sensing and therefore there was no need for them to provide you with a special cable to achieve a direct PC-to-PC ethernet connection. Whereas the parent comment probably only used the language "crossover" because they were tryi…

First, I provided the cable. They were commenting on the idea of using a crossover cable, not a request for one. Second, you are guessing what the commenter meant by crossover cable. I think he meant crossover cable. There is nothing to suggest otherwise. Third, I never said auto-sensing had anything to do with the OS or Microsoft. I said the IT department loved Microsoft. You got confused and made a connection betwe…

I am just trying to explain why your comment is grey. To be clear, there is no speed increase from using a crossover cable instead of a straight-through cable together with auto sensing.
Post reply on HN