WireGuard is submitted for Linux kernel inclusion • Hacker News Board

Re: WireGuard is submitted for Linux kernel inclusion

#181

Post by forapurpose » Fri, Aug 03, 2018, 5:35 AM UTC

ubercow13 wrote: post #172

zzzcpan wrote: post #73

Earlier quoted context omitted.

Unless you are ok living with pwned routers, printers, you don't want devices with javascript-enabled web browsers and other random 3rd party software, like apps, to have access to anything on local network or at least not when they have access to the internet.

Wait what? Are you saying for example at home you would not allow your PC access to anything else on your LAN?

Home equipment often is relatively poorly secured. The reality is that intra-LAN communication causes contagion to spread easily, that blocking intra-LAN communication can be very inconvenient, and that often there is no good solution.

At least restrict it as much as possible. For example, allow connections only to the printer, if that is needed, and maybe only in one direction - and lock down that printer. But consider walk-up printing via USB cable: People print much less often these days and they have to walk over to the printer to pickup the document anyway.

Re: WireGuard is submitted for Linux kernel inclusion

#182

Post by wahern » Fri, Aug 03, 2018, 7:45 AM UTC

rurban wrote: post #88

The only thing I don;t like about current WireGuard is that the single config file contains both the private key in clear, and all the public keys. IMHO the private keys should be in a separate file.

Private keys should be in secure hardware. Short of that it's all hand-waving.

That's one benefit that IPSec+IKE has over Wireguard at the moment. With IPSec authentication can occur in userspace and the private key never needs to be exposed to the kernel or to userspace. By the time you implement this for Wireguard, if ever, the Wireguard "stack" (inside the kernel and, hopefully, outside the kernel) code size will have gotten considerably larger.

It's largely theoretical at the moment because few IPSec setups actually make use of this capability. But it will become more common over time.

Re: WireGuard is submitted for Linux kernel inclusion

#183

Post by louiskottmann » Fri, Aug 03, 2018, 8:46 AM UTC

StavrosK wrote: post #31

louiskottmann wrote: post #26

Earlier quoted context omitted.

I actually gave up after trying for a while. They mention an "easy" way to do traditional VPN usage, but it never worked, and various blogs have differing opinions on how to properly do that. I wish there was better hands-on documentation for WG, but I guess it really is an addition to iptables and thus restricted to people versed in that area. Which I am not. I do intend to try again though.

Here you go, plug and play: https://www.pastery.net/gvfyub+hacbne/#gvfyub Use with `wg-quick up ` and you're done. I don't know why this isn't in the documentation, it strikes me as what 99% of users want, and the other 1% knows how to do whatever they need.

Thank you, I will try that

Re: WireGuard is submitted for Linux kernel inclusion

#184

Post by foobarbazetc » Fri, Aug 03, 2018, 11:33 AM UTC

zx2c4 wrote: post #128

foobarbazetc wrote: post #13

The biggest issue we’ve encountered with WireGuard is that it doesn’t (yet?) support GRO, which means the kernel doesn’t combine multiple sequential TCP frames inside the tunnel into one before presenting it to a program. This increases RTT by a significant amount.

Actually, I turned on inner-packet GRO a few weeks ago with this one-line change, resulting in surprisingly massive performance boosts for TCP: https://git.zx2c4.com/WireGuard/commit/?id=95951af7249912a43...

Woohoo!

Well, that’s amazing. We built a whole massively scalable CDN on top of WireGuard then hit that issue and had to shelve like 3 months of work.

Thanks for that!

Re: WireGuard is submitted for Linux kernel inclusion

#185

Post by foobarbazetc » Fri, Aug 03, 2018, 11:33 AM UTC

kanox wrote: post #35

foobarbazetc wrote: post #13

The biggest issue we’ve encountered with WireGuard is that it doesn’t (yet?) support GRO, which means the kernel doesn’t combine multiple sequential TCP frames inside the tunnel into one before presenting it to a program. This increases RTT by a significant amount.

That doesn't sound right, GRO is a performance optimization but shouldn't be required for interactive response. Sounds like what you need is TCP_NODELAY?

See above. ;)

Re: WireGuard is submitted for Linux kernel inclusion

#186

Post by Foxboron » Fri, Aug 03, 2018, 11:50 AM UTC

StavrosK wrote: post #71

Foxboron wrote: post #70

Earlier quoted context omitted.

I assume this is what you want? https://wiki.archlinux.org/index.php/WireGuard#Setup_a_VPN_s...

Yep, although the outbound iptables ALLOW is missing, which won't work with default DENY. Check my config in a sibling comment for the right one.

Added the line to the Arch Wiki entry. Thanks :)

Re: WireGuard is submitted for Linux kernel inclusion

#187

Post by lighttower » Fri, Aug 03, 2018, 9:46 PM UTC

StavrosK wrote: post #31

louiskottmann wrote: post #26

Earlier quoted context omitted.

I actually gave up after trying for a while. They mention an "easy" way to do traditional VPN usage, but it never worked, and various blogs have differing opinions on how to properly do that. I wish there was better hands-on documentation for WG, but I guess it really is an addition to iptables and thus restricted to people versed in that area. Which I am not. I do intend to try again though.

Here you go, plug and play: https://www.pastery.net/gvfyub+hacbne/#gvfyub Use with `wg-quick up ` and you're done. I don't know why this isn't in the documentation, it strikes me as what 99% of users want, and the other 1% knows how to do whatever they need.

can wireguard be run from different namespaces so that only certain applications are tunneled through the wg0 interface?

Re: WireGuard is submitted for Linux kernel inclusion

#188

Post by rstuart4133 » Sat, Aug 04, 2018, 2:55 AM UTC

zaarn wrote: post #170

therealx wrote: post #109

Earlier quoted context omitted.

OpenVPN is really not that hard to configure, and I'm pretty darn sure my config isnt broken (it's been audited at least twice.)

OpenVPN is quite difficult to configure IMO, 90% of the time I spend setting up an openvpn install is spend figuring out the routes that make everything go and have both server and client set them up properly.

Yeah, I'm with you. Saying a software package with over 300 different options and keeps default defaults that were depreciated years ago is easy to configure really is a stretch. Combine that with it being _very_ finicky about what x509 certs it accepts, requiring a directory of configuration files to set up the network and giving you raw openssl error messages, and I'd say it one of the harder things to I had to configure. IPSec is easier to setup, and by any measure IPSec isn't easy.

OpenVPN still wins over IPSec because it works over so many different transports, and there is only one implementation so IPSec's interoperability issues vanish. It maintains that advantage over WireGuard too.

Re: WireGuard is submitted for Linux kernel inclusion

#189

Post by brewrwe » Sat, Aug 11, 2018, 11:00 PM UTC

jwilk wrote: post #20

brewrwe wrote: post #12

Earlier quoted context omitted.

Based on what you stated, I assume this VPS is running on OpenVZ? If so, I doubt it will ever see newer kernel features, in part due to OpenVZ hosts relying on ancient LTS kernel branches and also due to OpenVZ "optimizations", whereby kernel features that use extra resources to enable just get disabled. Or, if your lucky they'll give you a button to re-enable them for youe container on an ad-hoc basis. Heads up, $20…

Where do you get these $20/y deals?

Here is a KVM VPS with a gig of ram for $15: https://www.lowendtalk.com/discussion/150797/virmach-raid-10...