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

111–120 of 187 posts

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

#111

Post by vladvasiliu »

vxNsr wrote: post #107
tptacek wrote: post #104

Earlier quoted context omitted.

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

But the `wg0.conf` thingy has to be set up on Windows too, right? So It's not clear why it would be easier on Windows than on Linux.

As far as I'm concerned, the most difficult thing I've encountered with Wireguard wasn't related to WG itself but to the fact that I'd set it up on three different systems, each with its own configuration style for bringing up the network.

Ubuntu server - netplan

Arch server - systemd-networkd (directly)

Arch "desktop" - NetworkManager

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

#112

Post by shawnz »

zinekeller wrote: post #6

While the driver can be licensed under GPLv2 (all kernel drivers needs to be signed by Microsoft*, and VirtIO is a precedent¤ that you can do it), I'm not sure if the header should be licensed under GPLv2, mainly because it would stifle Wireguard adoption. * In ordinary conditions. Test-sign mode does exist. ¤ ... for example, these Red Hat versions: https://www.catalog.update.microsoft.com/Search.aspx?q=Red%2...

VirtIO changed license from GPL to BSD so that it could be signed by Microsoft. See here: https://github.com/virtio-win/kvm-guest-drivers-windows/comm...

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

#113

Post by aborsy »

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

The networking part especially may require some work.

There can be many environments and situations, and sometimes a component would block packets to be forwarded from one network or user to another.

You need to know a bit about networking to debug it.

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

#114

Post by no_time »

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.

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

#115

Post by no_time »

planetafro wrote: post #74
midasuni wrote: post #58

Earlier quoted context omitted.

I had an sstp tunnel refuse to establish a few weeks ago. WireGuard was fine. Turns out the provider was MITMing tcp/443 traffic

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.

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

#117

Post by PhantomGremlin »

no_time wrote: post #114

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.

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

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

#118

Post by d110af5ccf »

PhantomGremlin wrote: post #117
no_time wrote: post #114

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.

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.

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

#119

Post by PhantomGremlin »

aborsy wrote: 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? :-)

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

#120

Post by pjmlp »

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